Automated startup and shutdown of Azure VMs

This document describes in headlines how to setup automated start and shutdown of Azure VMs. To go through the steps, you are required to have access to the management portal at https://portal.azure.com and administration rights.

By shutting down the servers when not used there is a noticeable amount to be saved.

Prerequisites

Automation Account

To run the automation scripts, you need an Automation Account. Notice, that the account must be created under the same subscription as the servers that should be managed by the account.

The fastest way to locate the accounts is to search for the Automation Accounts service:

account1

To create a new account, click the Add button:

account2

Give the account a name, specify a resource group (or create a new) and a location:

account3

When created (it takes a moment), select the new account:

account4

Shut down servers

Runbooks

All activity is kept in runbooks. The account comes with 4 default runbooks which we for this scope leaves as is.

shutdown1

We are going to create our runbooks based on a template that gives us the functionality we need out of the box. To do this click Browse gallery:

shutdown2

The list of available templates is long. The first one we are going to use is the “Stop Azure V2 VMs”.

shutdown3

When we click on it we can see a graphical presentation of the flow. This is not relevant to go through in this document. Click the Import button to use the template:

shutdown4

Give the new runbook a name and a description:

shutdown5

After the runbook has been created, click Edit:

shutdown6

From here we can change the runbook including default values for the runbook. We can also test the runbook with different values.

In this case we are not going to change anything so we publish it right away by clicking the Publish button:

shutdown7

Scheduled runs

Next step is to schedule the runbook to run every afternoon. To do this click the Schedule button:

schedule1

To do this we need to things: A schedule and the parameters to run the runbook with. First the schedule:

schedule2

In this scenario we want the VMs to be stopped every day at 18:00:

schedule3

To run the runbook we need to specify the resource group name and the name of the VM.

schedule4

This information is found on the information page of the VM in the Azure portal.

Add it to the parameters:

schedule5

Now the scheduler will shut down the server matching the parameters every day at 18:00.

If you leave the VM name blank all servers in the resource group will be affected.

Starting VMs

To create a runbook to start the VMs go to the gallery and select the Start Azure v2 VMs template:

startup1

Give it a name and description:

startup2

Click edit to access the runbook just created:

startup3

Publish the runbook. Again we do not want to change anything:

startup4

Create a schedule to start the VM every working day at 7:00:00. In this case we don’t start them up in the weekends; but if somebody starts a VM it is automatically shut down by the previously created runbook.

startup5

You just saved a lot of money on the VM…

 

Create scheduled runs for every VM you can shut down at night.

 

Advertisements

Change installation folder for the AOS server

Working for a company that handles development of multiple modules/add-ons to AX we end up having a lot of AOS-services on one server. We do that to separate development and release environments and keeping modules isolated from each other.

The problem that we sometimes end up with is that the C-drive reaches max and we need to install some of the AOS services on a different drive.

Going through the normal setup routine does not offer any options of specifying the installation folder. So we need to do two modifications before it works.

First step is to open the regedit.exe and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dynamics\6.0\Setup\Components\InstallDir and change the value to where you would like the AOS to be installed.

Second step is to make sure that the Server Setup files is present in the new directory. To do this simply copy the folder C:\Program Files\Microsoft Dynamics AX\60\SetupSupport to the new drive so you have a D:\Program Files\Microsoft Dynamics AX\60\SetupSupport or wherever you want the AOS servers installed.

Run the AX setup and your AOS is now installed on your new drive.

Roaming AUC files – new feature in R3

The quest for increasing performance in AX appears never-ending. With AX 2012 R3 Microsoft has added a new tool allowing us to make the AUC files global/shared.

Basic AUC file info:

AUC files are cache files made by the AX client to improve load time. Forms we have already loaded once could be loaded again from the cache without having to make a trip to the AOS for the bits and bytes. All stored in c:\users\<username>\AppData\local and then by nature user specific.

So the main challenge so far has been that user A opens the sales order form the first time, waits, caches the element and can open the form faster the second time and the same story for user B, C and all the others.

In AX 2012 R3 a new feature have been added to the client configuration with the title “Use roaming user profile to store client-side cache”. That basically says it all. We can now specify a global directory for the cache files allowing users to share the cache so when user A has opened the form user B can utilise the cache.

Still no fun for user A, but user B is in luck …