Using Azure Automation: Part 2


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.

Image of script

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.

Image of menu

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:

Image of message

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!

Image of menu

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.

Image of script

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?

No? Oops!

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):

import-module 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

$VMlist=Get-AzureVM

 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.

Image of script

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.

Image of menu

Within this page, you can simply go to the bottom and choose Add Setting to add an asset to the list.

Image of menu

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.

Image of menu

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):

Image of text boxes

We now enter in our credentials, the UserID, and the password, which…

Oh my! You can't see it now can you?

Image of text boxes

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 scripter@microsoft.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 

Comments (0)

Skip to main content