Last Update: Nov 19, 2024 | Published: May 19, 2015
In this Ask the Admin, I’ll walk you through how I solved a problem that was preventing an Azure Automation runbook from starting. Azure Automation allows tasks to be scheduled directly in the cloud, using the same runbook-based automation infrastructure as System Center 2012 R2 Orchestrator and Windows Azure Pack. For more information on Azure Automation, see How to Use Microsoft Azure Automation on the Petri IT Knowledgebase.
Recently I’d been taking a look at the costs of running a test lab in Azure and noticed that some virtual machines were left running for several days. I usually remember to manually shut down VMs once I’m finished with them, but there are occasions when I forget. But I felt safe in the knowledge that an automation runbook that I’d set up last year would automatically shut down any VMs still running at the end of the day. However it became clear that either the runbook wasn’t executing or starting, but also then failing to shut down the VMs.
A job summary and history is generated each time a runbook is launched and can be accessed using the Azure management portal.
Now that we have a source of information that shows details of what’s happening each time a runbook is executed, we can try and troubleshoot any issues. The runbook I’m having a problem with shuts down all running VMs at the end of the day. It’s a very simple piece of code, which I downloaded from Microsoft’s Runbook Gallery that’s accessible when you create new runbooks using the management portal.
As you can see in the screenshot above, there are three errors for the job. The first refers to the account in Azure Active Directory (AAD) that the runbook uses to get access to the virtual machines. It’s set up as a global asset, and I suspect the password expired because the account was created using the GUI, where there is no option to set the account’s password to never expire. The next two errors refer to a problem with the Azure subscription specified in the runbook, but I know for sure that the Pay-As-You-Go subscription exists, because I use it every day, and that the Select-AzureSubscription cmdlet is specified correctly in the runbook.
As a result, all I needed to do to resolve this problem was to change the password for the automation account in AAD and set the password to never expire, which I did with the help of PowerShell and the Set-MsolUser cmdlet using the –PasswordNeverExpires parameter. Once this problem was resolved, the runbook shut down running VMs, and the HISTORY tab for new jobs didn’t show any error messages for future jobs.
Set-MsolUser -UserPrincipalName [email protected] -PasswordNeverExpires $true
For more information on this process, see Use PowerShell to Create and Assign Licenses to Office 365 Users on the Petri IT Knowledgebase.