Create an OMS Automation runbook that stops all Azure Resource Manager VMs

Summary: Learn how to create a Windows PowerShell workflow and add it to Microsoft Operations Management Suite automation to stop all Azure Resource Manager virtual machines.

Good morning everyone, Ed Wilson here, and today I want to talk about how to use a Microsoft Operations Management Suite (OMS) automation runbook to stop all Azure Resource Manager virtual machines. The virtual machines all live in the same resource group, and I am using the AzureRunAs connection and credential to do the automation.

Note: Resource Manager VMs uses the Resource Manager deployment model instead of the classic deployment model. For more about deployment models, try Azure Deployment Models.

Load the Windows PowerShell ISE add-on for Azure Automation

The first thing I want to do is to use the Windows PowerShell ISE add-on that lets me use the Windows PowerShell integrated scripting environment (ISE) to do my Windows PowerShell work. This works a lot better than trying to write Windows PowerShell code directly in the Automation portal. In addition, I can test my code, look at other runbooks, and even browse the gallery to find code that I might want to use. I talked about the way cool Azure Automation add-in in a recent OMS Team blog posting.

Important: Keep in mind that the workflow name and the runbook name must be the same.

I do not load the ISE add-on via my Windows PowerShell ISE profile because it takes a couple of seconds to load, and that seems too long. Instead, I use Import-Module and tab completion to load the module on demand. Here is the code I use to do that:

ipmo AzureAutomationAuthoringToolkit

Now I need to sign in. In the Azure Automation ISE add-on tab, next to my account, I click the Sign In button to open a dialog box so that I can fill in my credentials. This is shown here:

Screenshot of the dialog box to sign in to Azure Automation.

After I am signed in, my subscription automation account and other information is automatically filled in, and I’m ready to go. So, I go to the Runbook tab, and select Create New. This is shown in the figure here:

Screenshot of the Runbook tab and the Create New button that creates a new runbook.

I am then prompted for a name for the new runbook and asked if I want to create a script or a workflow. Obviously, the third type of runbook (graphical) is not an option via the Windows PowerShell ISE. The dialog box is shown here:

Screenshot of the Create Runbook dialog box.

So, I name it StopAllV2VMs and select Workflow, which automatically adds the workflow keyword, name, and scriptblock to my Windows PowerShell ISE editor. The process also saves the newly created PS1 file in my automationworkspace in my user profile directory.

At this point, I can begin to write code, or I can open another runbook and see if I want to copy some or all of its code. If I find something, I need to download it to my computer before I can open it.

On the other hand, I might want to write the code myself. I decide to base StopAllV2VMs on the code that I wrote yesterday. After all, there’s not much difference between stopping and starting a virtual machine regardless of where it happens to live. So, I select StartAllV2Vms, download it, and open it. This is shown in the figure here:

Screenshot of code to start VMs in the Windows PowerShell ISE.

After I download and open my StartAllV2Vms workflow, I copy and paste it to the StopAllV2VMs workflow. This is shown here:

Screenshot of code from StartAllV2Vms workflow that’s pasted in the StopAllV2VMs workflow.

So, all I need to do is to change Start-AzureRMVM to Stop-AzureRMVM. Now, I save my workflow and upload a draft. After the draft it uploaded, I can test it. I select the Test Draft in Azure button to open the test environment. I select the Start New Job button, which begins to activate the job. This is shown here:

Screenshot of the test environment after the Start New Job button is selected.

Now, I watch and make sure that the job finishes correctly. It does not. I see a couple of “command canceled” errors, so I stop the job. It is filled with red. This is shown here:

Screenshot of errors in the test environment for the StopAllV2VMs workflow.

Oh, I know what happened! The cmdlet probably prompts. So, I revise my script, publish the draft, and test it again. This time, I add the -Force parameter. My code now is shown here:

workflow StopAllV2Vms

{

$Conn = Get-AutomationConnection -Name AzureRunAsConnection

`` Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID `

-ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

 

$VMsv2 = Get-AzureRmVM

foreach ($vm in $vmsv2)

{Stop-AzureRmVM -Name $vm.name -ResourceGroupName 'server' -Force}

}

This time, no errors arise, and when I go to the StopAllV2VMs workflow, I can see that the VMs are starting to shut down. Cool, it works. This is shown here:

Screenshot of virtual machines and their statuses.

Sweet, so now if I like my new runbook, I select the Publish Draft button, and, Woohoo, I’m done.

If you would like to get a free Microsoft Operations Management Suite (#MSOMS) subscription so that you can test the new alerting features. You can also get a free subscription for Microsoft Azure.

That is all I have for you today. Join me tomorrow when I’ll talk about more cool stuff.

I invite you to follow me on Twitter and the Microsoft OMS Facebook site. If you want to learn more about Windows PowerShell, visit the Hey, Scripting Guy Blog. If you have any questions, send email to me at scripter@microsoft.com. I wish you a wonderful day, and I’ll see you tomorrow.

Ed Wilson
Microsoft Operations Management Team