Summary: Honorary Scripting Guy, Sean Kearney discusses how to get started and test a basic runbook with Azure Automation.
Honorary Scripting Guy, Sean Kearney, is here. Today I'm going to show you the basics you're going to need to make a useful runbook (or Windows PowerShell workflow, if that makes it easier to remember) in Microsoft Azure. This is the second post in a five-part series. Be sure to read Using Azure Automation: Part 1 first.
I've started a very basic script block to get a list of virtual machines in Azure and stop them all. Nothing fancy.
If I want to, I can click the Test button to see how well I did or did not fare with my simple typing. This will attempt to parse my script and make it do something.
I wait happily thinking to myself, "Ah ha! I am so smart! Got the work done the first time! Didn't have anybody proof it and…"
Apparently, I am not so smart because this message returns:
The test system in Azure Automation caught something I messed up. Clicking the Details button reveals why I should have checked my glucose this morning!
Well, that was nice! Microsoft Azure caught where I goofed before I went to production (remember this runbook/ is all in draft mode right now). I scan my script and add the missing piece to correct (at least) my lapse in logic and my common sense.
Sure enough. I forgot to put a semicolon in my Foreach loop!
But anybody who knows Azure knows this workflow is doomed to fail regardless. "Why?" you ask? Did anybody see me authenticate to Azure?
Which gets us to the part where Azure Automation starts to rock. It's not just about running a hosted Windows PowerShell workflow. It's about doing it in a secure manner, including storing credentials!
Let's look at a basic script that has passwords in clear text doing pretty much the same thing (which is shutting down some virtual machines in Azure):
$pass=ConvertTo-SecureString 'Sup3rR@dk001' -AsPlainText -Force
$cred=New-object -TypeName system.management.automation.pscredential -ArgumentList 'AdminAccount@contoso.onmicrosoft.com',$pass
Add-AzureAccount -credential $cred
foreach ($VM in $VMList)
$Result=Stop-AzureVM -name $VM.Name -servicename $VM.ServiceName -Force
We could probably use this script as it stands if we replaced in the Azure Automation runbook.
But wouldn't it be nice (oh so very nice) if we could store this securely?
Cue drum roll, lights, and shiny objects! Enter the POWER of Azure Automation assets! Assets are where you can place objects that can be centrally accessed by Windows PowerShell workflows within your Azure Automation account.
You can store simple stuff such as a URL for the company website or secure things—things you should not leave on a sticky note, things you shouldn't post on a whiteboard when a news reporter interviews you…
Yes! Passwords, of course!
To access the assets, go back to your Azure Automation account and select the Assets option.
Within this page, you can simply go to the bottom and choose Add Setting to add an asset to the list.
There are four types of assets you can add: a simple variable, a schedule, an Azure connection, or the one we're most interested in, a credential.
You'll get an option to provide one of two credential types: a standard Windows PowerShell credential or a certificate. We're going to populate a Windows PowerShell credential.
We give it a descriptive name and a very descriptive description (yes, I'm allowed to have fun here):
We now enter in our credentials, the UserID, and the password, which…
Oh my! You can't see it now can you?
I click the check mark and my asset is created!
Swing by tomorrow and I'll show you the next part, which is how to get that runbook to access those assets.
I invite you to follow The Scripting Guys on Twitter and Facebook. If you have any questions, send an email to The Scripting Guys at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then remember eat your cmdlets every day with a taste of creativity.
Sean Kearney, Windows PowerShell MVP and Honorary Scripting Guy