Since using the new Azure “V2” VMs I had a complaint: I can’t (easily) set up a schedule for my VMs like I was able to with Classic VMs and the Classic Management dashboard.
I recently set up a Minecraft server for my sons and was turning it on when they got home from school and off again at bed time. How? I set a Cortana reminder and manually loaded the Azure dashboard and hit Start/Stop on the instance each time.
“There has to be a better way,” I thought. And of course, there is.
Azure Runbooks via Automation account
Creating the Automation Account
Turns out, there’s more to Azure than just the Automation scripts that you can pull down to see how to create your Azure resources via the Azure APIs and script creation of your environment, there’s also a way to Automate your Azure objects. And it’s actually not too bad to use! Enter Automation Accounts and Runbooks.
To get started, go to your Azure portal, click the + and search for Automation. Choose Automation, then Automation (publisher: Microsoft, category: Developer tools) and create a new one. From what I can tell there aren’t any restrictions on where you must place your AA to access objects in any of your Azure subscriptions. Although keeping it in the same Resource Group can help to keep things clean and well-defined.
Do make sure to select the “Create Azure Run As account” option as your task will need the privileges to Start and Stop VMs in your subscription. It’s also worth noting you can have only one Automation Account per resource group.
Once you’ve created the Automation Account & it’s been deployed, it’s time to configure it to do what we want: Start & Stop a server on a Schedule.
Setting up the Runbooks
When your Automation account is first created, they throw 4 Runbooks in it to get you started. Since I’m going to be taking you through this, you can delete these. To do this, click each Runbook, then click the ‘More’ selection at the top of the blade, then choose Delete.
Now to create the Runbook we want.
At the top of the Runbooks blade, choose ‘Browse gallery’ then search for ‘Start’ and choose the ‘Start Azure V2 VMs’ option. If you created a “Classic” VM, you’ll choose the ‘Start Azure Classic VMs’ one. That Runbook may or may not be the same as the V2 one, so I make no promises as to the validity of the ensuing steps should you be doing this against the Runbook for Classic VMs.
Once you’ve selected the ‘Start Azure V2 VMs’ Runbook, name it something that makes sense for your use case, then click Import to bring it in to your Automation account. You can also preview the steps involved in the Runbook right there before you start using it. This is nice to make sure it’ll do what you want as you explore this scenario for other purposes.
Once imported, it’s time to tune the Runbook for our use case. You’ll notice that, right away, you can’t “Start” the Runbook. Runbooks have three steps to getting them up and going. First you Edit, then you Save, then you Publish. Then you get to run it.
So let’s start by clicking ‘Edit’ at the top of the new Runbook’s blade. This brings up the graphical editor for Runbooks as this particular Runbook is a graphical one. There are also Powershell Script and Powershell workflow Runbook types.
This particular Runbook has a few different ways it can go. It can Start all VMs in a Resource Group, all VMs in a Subscription, or one specific VM. The decision tree for which path it takes is illustrated by the branching of arrows below the “Connect to Azure” step in the flow. If you click any one of the dotted lines, you can inspect the logic that determines if it gets followed.
To summarize, if you specify a Resource Group and a VM name, the “Get single VM” task will be run. If you specify just a Resource Group, all VMs in that group will get started (“Get all VMs in RG”). And finally if you specify neither of those then all VMs in a Subscription will be started (“Get all VMs in Sub”).
There are, however, a couple of errors we need to fix in this Runbook’s default state. I found these through testing; your Runbook will work correctly without these fixes, but it will always output that it failed. So I recommend you do the following steps:
- Click the left dotted process line under ‘Start VM’ and change its Condition expression to
$ActivityOutput['Start VM'].IsSuccessStatusCode -eq 'True'
- Click the right dotted process line under ‘Start VM’ and change its Condition expression to
$ActivityOutput['Start VM'].IsSuccessStatusCode -ne 'True'
After making these changes, hit ‘Test pane’ at the top of the blade. For my use case, I want to make sure this Runbook gets kicked off with the Resource Group and VM name of my target (in my case, Minecraft) server. Fill out the RESOURCEGROUPNAME and VMNAME parameters to execute the Runbook at your target server, and watch the console output.
You should see 1 of 2 things. Either your VM was already running and you’ll get output to that effect or it will say your target VM was successfully started and you can go and verify that by taking a look at its status in the VMs area of the Azure Portal.
Rinse, Repeat
Repeat the above steps for the ‘Stop Azure V2 VMs’ Runbook template.
No, really, go ahead. I’ll wait.
Configuring the schedule
The next step is to configure a schedule for the Runbook to execute. For me, I turn on the Minecraft server when the kids get home from school during the week (~3:30p), on in the mornings on weekends (~8a), and off when they go to bed each night (~8p). So let’s look at how that gets set up.
- On the Runbook’s blade, click the ‘Schedules’ tile (not the ‘Schedules’ option at the top).
- Choose ‘Add a schedule’ from the top of the Schedules blade.
- ‘Link a schedule’
- ‘Create a new schedule’
- Set it up for the time you want it to execute. For my Weekday setup, it looks like:
- Name: Weekday start
- Starts: Tomorrow, 3:30p, Pacific Time
- Recurring
- 1x Week
- Recurrence options: M-F
- Never Expires
- Click ‘Create’
- Choose ‘Configure parameters…’ at the top of the ‘Schedule Run…’ blade
Remember, in order for our Runbook to target a single VM (which is what I wanted), we have to give it the RESOURCEGROUPNAME and VMNAME. Each defined Schedule allows us to fill out the parameters defined for the Runbook. Fill these out accordingly, click ‘OK’ then ‘OK’ again and your schedule is added to the Runbook. - Repeat for any additional schedules you want to have for your Start Runbook (for me I added 1 more for Saturdays and Sundays in much the same manner, but starting at 8a on those days)
Note: If you screw up a schedule, you have to delete it via the ‘Schedule’ button at the top of the Runbook blade then recreate it via the steps above.
Runbook with one Schedule defined and another in-edit
And you’re done! Your VM will Start and Stop as defined by the schedules you set up in your Runbooks.
But let’s take this another step. You just KNOW that there’s going to be some time when your kids aren’t going to be at school, might stay up late, etc and you’re going to have to turn on the VM outside its scheduled time. What if there were an easier way instead of loading up the portal, logging in, finding the VM resource, clicking ‘Start’ and waiting?
Microsoft’s a productivity company, folks. So of course it turns out, there is. ;)
On-demand access with Microsoft Flow
Enter Microsoft Flow – it’s IFTTT for Office 365 but the best part is you don’t have to have an o365 account to use it. And, to boot, it has some cool features like creating “buttons.” Perhaps you can see where I’m going.
What got me thinking about this possibility was this little button in my Runbook:
Webhook? Don’t mind if ido.
Let’s click it and see what we get:
Webhook creation
The Webhook creation is pretty straightforward. Notice that it sets the expiration date out by one year. If you think you need/want longer, change that here. In addition, take special note of the big fat warning. Copy that Webhook URL to someplace else now.
Similar to the creation of Schedules, you also configure the parameters passed to the Runbook when the Webhook is invoked here. For me that was, again, the Resource Group and Name of my Minecraft server VM.
When you’re done, let’s head over to the Flow dashboard.
Creating a Flow Button for the Runbook Webhook
I honestly couldn’t believe how dead-simple this was.
- Click ‘My Flows’ at the top of the Flow home page.
- Choose ‘Create from blank’
- In ‘Search for more triggers’, type ‘button’ and choose ‘Button – Manually trigger a flow’
- Click ‘+ New step’ & choose ‘Add an action’
- Search for ‘http’ and pick ‘HTTP’
- Method: POST
- Uri: the Webhook Uri you copied when creating the Webhook on the Runbook
- Set a name for the flow at the top of the page – this is what shows in the Flow app’s “Buttons” area
- Click ‘Create Flow’
- Repeat for your other Runbook(s)
Microsoft Flow definition for a Button to execute an Azure Runbook Webhook
Now, open Flow on your device (iOS, Android) and log in to the account you used when creating the Button Flows above.
In the app, choose the ‘Buttons’ area and behold the wonder:
And that’s it! Your VM now runs on a schedule but also has on-demand capability right in your pocket!