Using Azure Automation to run VMs during office hours only – using graphical runbooks

Over a year ago, I wrote a similarly titled post on how to use Azure Automation to run VMs during office hours only.

Since then, much has changed with Azure Automation and the previous management portal has been replaced. This post goes through how to achieve scheduling of VM running times using the current portal and the latest advancements.

Azure Automation allows you to automate many common aspects of using the Azure platform, integrating with other features such as web sites, cloud services and virtual machines.

To use this feature, you will need to create an automation account, create Runbooks which contain PowerShell Workflows with the functionality you want to implement (e.g. starting and stopping a virtual machine or cloud service), and link those Runbooks to Schedules so that they get automatically run at pre-defined times.

Azure Automation enhancements

There have been lots of updates to Azure Automation in the last year. Some of the notable enhancements are:

• Graphical authoring of runbooks allows you to use a visual drag-and-drop tool in the Azure Portal to build and configure a runbook
• The Automation tooling was made available in the new portal
• Integration of the runbook gallery in the portal
• Support for PowerShell DSC and Azure Resource Manager APIs was added
• Lots of improvements to the Automation user experience
• Automation available in more regions
• Support for Webhooks added

Step-by-step guide to only running VMs during office hours

The aim of this step by step guide is to use the graphical runbooks feature to schedule starting and stopping of a virtual machine. This will be achieved using pre-existing graphical runbooks available in the gallery, built by the Automation product team. The virtual machine is of the "resource manager" variety, rather than "classic", but there are specific runbooks that are tailored to each type so use whichever is appropriate to your situation.

If you don't already have an Automation account, create a new Automation account in the Azure Portal, by navigating to New > Management > Automation and completing the required details.

Once you've created an account you'll see it listed in the Automation Accounts blade.

Clicking on the Automation Account shows all of its details, allowing you to view and create the various resources, and see monitoring information for jobs.

In order to execute PowerShell scripts, whether they are regular scripts, Workflows, DSC or graphical runbooks, you need some form of credential. There is now a specific Automation resource for defining Credential assets. In the older post on this subject, certificates were used for authentication, but Azure Active Directory could also have been used to create a user with access to the subscription.

In this guide we will use an Azure RM AD service principal. With this you can assign fine grained role based access to the resources in your Azure directory. For example the service principal could be assigned the "VM Contributor" role for a specific resource group only. Or it could be assigned full access to an entire subscription. There are many built-in roles and you can define custom roles as well.

To learn how to create the service principal, follow the steps from a previous post.

Once you have a service principal, you can assign it to a particular resource with a particular role. For example navigate to the Subscriptions blade, and click on the Subscription you want it to have access to. Near the top right of this blade, there is a set of icons. Click on the "Access" icon (looks like two people and is highlighted red in the image). This allows you to assign user access.

From there select a role and add the service principal user. You can use the search box on the Add Users blade to find your service principal.

Now that the service principal has been given access to the subscription, an Automation Credential can be created. From the Automation account blade, navigate to Assets then Credentials and click the "Add a credential" button. Enter your service principal details.

Time to create the Runbooks! From the Automation blade in the portal navigate to Runbooks then click the "Browse Gallery" button. We'll be using pre-existing graphical runbooks available in the gallery, built by the Automation product team. If you search for the text "azure arm vms" you'll see the two Runbooks we'll be using for this guide.

Clicking on the "Stop Azure ARM VMs" brings up a view that shows the graphical runbook in all it's glory.

Clicking the "Import" button will bring this graphical runbook into your Automation account and allow you to alter, test and publish it.

Clicking the "Test pane" button will allow you to fill in the parameters the runbook requires and start the runbook and see the output. The parameters this runbook needs are:

• Resource Group name
• Azure Subscription Id Asset name
• Azure Credential Asset name
• VM name

The Credential Asset was made in a previous step. You'll need to create a new Variable Asset for the subscription id.

If you successfully enter the parameters and test the runbook, you should see output that says it is Completed and that the VM has been stopped.

Once you've successfully tested the runbook, you can hit the "Publish" button.

Now that we have a published runbook to stop a virtual machine, we need to link it to a  schedule, so the runbook starts automatically when we want it to.

From the Runbook blade, click the "Schedule" button, then "Add a Schedule". First you need to set up a schedule to link to the this runbook. You can use an existing schedule or create a new one. When creating a new schedule you need to enter a name and when it should run e.g. daily at 20:00.

The parameters that will be given to the runbook on this scheduled run then need to be populated as well.

Once the schedule has been created, you'll see that schedule on the runbook blade.

We could now repeat all the steps to create a new runbook, but use the "Start Azure ARM VMs" graphical runbook from the gallery. In this way we can schedule the VM to start and stop according to our needs.

Wrapping up

In my previous post on this topic, I detailed how endjin used this approach to achieve a 62% cost saving on our ALM infrastructure.

This can be a real money saver. Set this up for all your VMs if possible – if they only run 8 hours a day, you save two thirds of the cost!