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.
Job Summary and History
A job summary and history is generated each time a runbook is launched and can be accessed using the Azure management portal.
- Log in to the Azure management portal using a tenant administrator account.
- In the management portal window, scroll down the blue panel on the left and click AUTOMATION.
- On the automation screen on the right, click the automation account that hosts the runbook.
- On the automation account screen, switch to the RUNBOOKS tab.
- In the list of runbooks, click the runbook you want to debug.
- Now switch to the JOBS tab. You can filter the jobs list if necessary, but otherwise it displays the last nine jobs.
- Click one of the jobs in the list, and you’ll be presented with a summary, giving information, such as whether the job completed, any input and output parameters, and the job ID.
- Change to the HISTORY tab. This is where you’ll see any error messages that might indicate a problem.
- Click VIEW DETAILS at the bottom of the management console, and you’ll see more detailed information about the selected error.
- Clicking VIEW SOURCE shows you the runbook source code.
Investigating an Automation Issue
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@example.com -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.