Main menu

Using Azure Automation to Start und Stop Virtual Machines on a Schedule

A couple of months ago, I wrote a blog post about starting and stopping virtual machines in Azure using Windows Task Scheduler inside a dedicated VM. With the advent of Azure Automation this can actually be done way easier and also free-of-charge. In this post I will describe how to use Azure Automation to start and stop virtual machines on a schedule.

Set Up Automation

First thing you will need to do is to register for the preview of Automation. Usually you will get approved via email immediately, i.e. there is no queuing and waiting like for some other popular and resource-constrained Azure services (e.g. RemoteApp).

Once activated, navigate to the Automation section of the Azure management portal and create a new automation account, called sample-aut. At the time of writing the preview was only available in the East US datacenter, so you don’t have a choice.

Enter the automation account and navigate to the Assets section. Here you can see that an Azure module is assigned to the account by default, which contains the Azure PowerShell cmdlets. The default version is currently not the latest PowerShell release for Azure (0.8.2), as the portal shows a date of 3/19/2014 in the Last Update column.

If the version isn’t current, you should update the module to the latest version in order to avoid issues later on (Anders Eide wrote a good post about that). So, if you are not yet on the latest version on your local machine, update it from the Azure Download Center.

Then, go ahead and save the Azure subfolder in C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\ServiceManagement into an archive called Azure.zip.

On the Assets page in the portal, import the zip file via the Import Module button. This will upload the file and register the cmdlets in the automation account. After a couple of minutes you should get a success message, and the Last Update column should display the current date & time.

Create Assets

Before we can create our runbooks to control VM startup & shutdown we have to add a credential and define a couple of settings for the automation account. A credential is required in order to authenticate to the subscription that is hosting the target VMs.

For our scenario we will create a certificate credential and use a management certificate. If you do not already have a management certificate in your target subscription you can create a new one as described here. The .cer file has to be uploaded in the Management Certificates section of the Settings page in the portal.

Click Add Settings under Assets in the Automation account and select Add Credential.

Choose Certificate as Credential Type and pick a name (I used sample-cert). Next, select the .pfx file of your management certificate from your disk, enter the password and finish the wizard.

Now, we need to define a couple of variables that we will use in the PowerShell scripts later on. This way we don’t have to hard-code any values in the startup/shutdown-scripts. The following table shows the variables we are going to create:

Name

Value

CertificateName

your cert name, e.g. sample-cert (see above)

SubscriptionID

ID of the target subscription (under Settings in the portal)

SubscriptionName

Name of the target subscription (under Settings in the portal)

In order to define the variables, for each of them click on Add Settings under Assets in the Automation account and select Add Variable.

In the wizard, specify name and value for the variable as shown below. Make sure to select variable type String.

The Assets page should now look like this:

Create Runbooks

Now we can finally create our first runbook, which is actually nothing else than a PowerShell script encapsulated in a Workflow object.

From the New link in the management portal, select App Services – Automation – Runbook – Quick Create, fill in the dialog as shown below (I used Start-SampleVM as the runbook name) and create the runbook.

In the Author section of the new runbook you can enter the code that the runbook is supposed to execute. Paste the following statements into the editor window:

The script basically just selects the proper subscription, authenticates using our custom certificate and executes the Start-AzureVM cmdlet on a VM that can be specified through the parameters $VMName and $ServiceName. Note that we are using the variables we have defined previously.

Now, create a second runbook called Stop-SampleVM. It looks almost identical, just replace the Start-AzureVM statement in the script with the following one:

Stop-AzureVM -Name $VMName -ServiceName $ServiceName -Force

Note that I have added the –Force parameter. In case the VM you are planning to stop is the last one in the cloud service the statement will fail without this switch.

You can test the runbooks via the Test button in the Author page. Doing so will open the following dialog:

Enter the name of the VM you want to start (pick one that is currently stopped) and also the name of the corresponding service that’s hosting that VM. In the example shown above the runbook is going to start a VM myvm that is deployed to the cloud service myservice.cloudapp.net. When you kick off the test the request gets submitted and the portal will give you some status updates about the job:

After a couple of minutes you should get a success message, which means that startup of your VM has begun. You should now check in the Virtual Machine section of the management portal if the VM is coming up.

You should now also test the Stop-SampleVM runbook to make sure it is working properly.

Now that you have successfully tested the runbooks you need to publish them. You can do that via the Publish button on the Author page. After publishing the script will show up read-only on the Published tab.

Define Schedules

As a last step, we need to define a schedule for our runbooks to let them run at certain times. Head over to the Schedule tab of the Start-SampleVM runbook and click on Link to a New Schedule.

In the second step of the wizard you can define when the runbook should be executed, e.g. daily at a certain time with or without an expiry date.

In the final step you will have to enter values for the name of the VM and the service (as above). After having defined the schedule it will show up in the Schedule section of the runbook

as well as in the Assets section of the Automation account:

After the job has executed at the scheduled time, you will see an entry in the Jobs section of the runbook:

Clicking on this entry will show more details about execution of the job:

If you want to control multiple VMs in a single go, you could either extend the scripts shown above (i.e. stop more than one VM per runbook, e.g. all VMs within a single cloud service) or create separate runbooks for the VMs. Schedules can be shared between runbooks, i.e. you could create separate runbooks for different VMs and let them run on the same schedule. Note, that in this case parameters (i.e. VM name and service name) are stored with the runbook instances and not with the schedule.

If you want to stop the automated startup/shutdown of your VMs you can disable the corresponding schedule in it’s settings in the Assets section.

If you want to get additional details about execution of your runbooks, you can switch on logging in the Configure section:

If you switch on all logging parameters, you will get an output on the History tab of a job that looks like this:

So, with the approach described above you can easily create runbooks for starting and stopping your virtual machines on a schedule. And that’s even without any cost, as long as you don’t exceed the limits of the free pricing tier.

Great article, thanx! What surprised me is that the schedule have very limited setup – one time/hourly/daily only – no day selection etc. So if you need more “advanced” scheduling scenarios you have to code this in the script. Additionally once created schedule can’t be changed anymore … etc.
Good feature, but still in preview version …

You actually posted the link to this exact page, and it doesn’t help.
I’m also confused by these two statements:
>> The .cer file has to be uploaded in the Management Certificates section of the Settings page in the portal.
>> Next, select the .pfx file of your management certificate from your disk, enter the password and finish the wizard.

I didn’t figure out what we need exactly – a .cer or a .pfx file? The Management Certificates does not allow .pfx.
Can anyone clarify this?

I figured it out. After creating a .CER file, you should import it and create a .PFX file to this certificate.
.CER is imported to Settings -> Management Certificates.
.PFX – to Automation -> Assets correspondingly.

Can you expand on this in any way? The cert part is the only part I don’t understand AT ALL given the way it was explained here. This article just links to a very generic MSDN blog about certs in general and I still have no idea what we are trying to accomplish or where exactly this make cert command is executed? Clearly I can’t do it on my local machine and doing it on the VM in question didn’t work. Where do we make this cert exactly? I apologize for my lack of understanding on certs but I have 0% understanding of them and this article seems to suppose that you already know about them and as such give give a little nudge in the right direction with no real explanation of where and what we are supposed to do regarding the cert.

An alternative for those who prefer a non-scripting solution is a service called VMPower (https://vmpower.io/). There is a calendar feature that makes automating shutdown, startup and resize of VMs pretty intuitive to do in <15 minutes. With the GUI, it's very accessible for non-technical team members to manage too.

Also for the folks juggling cloud subscriptions across multiple cloud providers (Azure, AWS, & GCE) , you can manage all of your VMs in one unified dashboard.