1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Microsoft Azure Automation: Concepts and Practical Usage

Demo: Create an Automation Account and Runbook

play-arrow
Start course
Overview
DifficultyIntermediate
Duration59m
Students1078
Ratings
4.8/5
star star star star star-half

Description

During this demonstration, we will take a look at provisioning an Azure Automation Account, and then creating a PowerShell script-based Runbook inside the Automation Account! Before you can create an Automation Account, you need to create a Resource Group, because all resources in Azure must belong to a Resource Group! Resource Groups are essentially just containers for management of groups of cloud resources, under the Azure Resource Manager (ARM) interface.

Transcript

Hello. In this demonstration, we're going to create an Azure Automation account, and then we're going to create our first Azure Automation runbook. Let's go ahead and get started.

The first thing we need to do is create a resource group. Because all resources inside of Azure must belong to a resource group, this is the logical first step. Let's go ahead and create a resource group called "Cloud Academy Automation", and we'll create it in the North Central US region. We'll leave Pin to Dashboard checked so that we can easily reference the resource group on our dashboard. Once we create the resource group, let's go ahead and create an Automation account. We'll click the Add button on the resource group, and then under the Everything blade that opens up we'll search for Automation. We'll click on the Automation account, and then click on the Create button. We'll give the Automation account a name, such as "Cloud Academy Automation". We'll also choose the resource group, because it didn't get passed forward when we clicked the Add button earlier. We also have to choose a region to deploy the Automation account into. So let's choose the East US 2 region. Finally, we'll uncheck Pin to Dashboard and click Create.

Let's go back to our dashboard now, and then we'll open up the resource group again to refresh the view. As you can see, we have the Cloud Academy Automation Automation account inside the resource group. So let's go ahead and open that up and explore it a little bit.

Under the Azure Automation Account blade, you'll see Runbooks. That allows you to access any runbooks that exist inside the account, as well as create your own or import ones from the gallery. As you can see at the top here, we have a Browse Gallery button that allows us to explore the Microsoft TechNet Script Center for Automation runbooks. You can also click Add a Runbook to create your own custom runbook.

Under the Jobs section here, you'll open up a new blade and see all of the runbook jobs that have been executed inside the Azure Automation account. You can filter the jobs for a specific runbook name, as well as the job status or a specific time period. Under Hybrid Runbook Worker Groups, you'll see any Hybrid Runbook Workers that you've configured. Hybrid Runbook Workers are on-premises runbook workers that you manage. Under the Asset Store, we have the option to create schedules, modules, certificates, connections, variables, and credentials.

Schedules allow you to link a runbook to a schedule, and the runbook will automatically execute on that schedule. You can import custom PowerShell modules into your Azure Automation account that enable you to leverage those modules from inside your runbooks. Certificates allow you to import certificates that your Automation runbooks can leverage, along with connections, variables, and PowerShell credentials.

We're going to go ahead and create a PowerShell credential here that allows us to access our Microsoft Azure subscription. So we'll go ahead and give that credential a name, and give it a description. We'll also give the credential a username, which is my Azure Active Directory username and its password, and then finally I'll click on the Create button. So now we have a credential inside of our asset store called Azure Admin and we can reference that from inside our runbooks, which you'll see momentarily.

The other thing we're going to do is create a variable to store the name of the subscription that we're currently working in. So I'll click on Add a Variable and I'll just call the variable "SubName," and I'll give it a description that says, "This variable contains our Azure subscription name." Then, the value here will be "Visual Studio Ultimate with MSDN," and I'll just go ahead and click on Create. Great. So now I've created a PSCredential called "Azure Admin" in my asset store, and I've also created a variable called "SubName" in my asset store.

So now, let's go ahead and build our own custom Azure Automation runbook. So I'll go back to the Runbooks blade and then I'll click on Add a Runbook, and then choose Quick Create and we need to give it a name. So let's go ahead and build a runbook that simply retrieves a list of resource groups inside of our subscription. So we'll call this "Get Azure RM Resource Group Custom" just to avoid any naming conflicts with the Get-AzureRMResourceGroup command.

Now, you can choose to run a PowerShell script, a PowerShell Workflow, or create a graphical runbook. But in this case, we'll just go ahead and use a standard PowerShell script. We'll also give the runbook a description. Great. So now I'll click the Create button to create the new runbook. After the new runbook has been created, I'll automatically be taken to the Edit PowerShell Runbook experience.

But first, let's scroll back over to the Runbook blade and take a deeper look at it. As you can see, we've created a new empty runbook and the Start button is grayed out because we haven't actually published any runbook code yet. We also have options to view and edit, look at the settings, schedule the runbook if we have schedules already inside of our asset store. We also have the option to create webhooks, which enable us to call the runbook from an external service. Then, we have some basic information about the runbook under Essentials, such as the resource group and the Azure Automation account that it belongs to, the Azure region that the runbook belongs to, the Azure subscription that the runbook belongs to, the status of the runbook. The runbook type, which again can be PowerShell runbook, PowerShell Workflow, or a graphical, the last modified date and time, as well as the last individual who modified it. In this case, the last individual who modified this runbook was me, and so it lists my Azure Active Directory account name there.

Under Details, we have the option to open up runbook jobs just for this particular runbook. We also have the option to see any linked schedules that this runbook has, as well as any webhooks that we've already created. Let's go ahead and edit the runbook now and actually fill out the code. But let's take a look at the interface first. We have the option to save the runbook if we've made any changes. We can publish the runbook after we've tested it to the production slot. We can check in code into GitHub if we have source control integration set up. Then, we have the test pane which allows us to test our runbook code before we actually publish it to the production slot and overwrite any production code that's currently scheduled to run.

On the left-hand side here, you'll see Cmdlets which allows us to browse all of the PowerShell modules that are available inside of our asset store. By default, we have the Azure Service Management PowerShell module, all of the Azure Resource Manager PowerShell modules, or at least the core ones, and then we also have the core PowerShell modules which provide things like Get Child Item, converting to and from JSON, and many other kind of utility functions.

Under Runbooks, we can see a list of other runbooks that are defined inside of the same Azure Automation account. We can call those runbooks very easily directly from this runbook by simply right-clicking one of those runbooks and clicking Add to Canvas. In this case, we can't add this runbook, because that would create a loop in itself.

Under our asset store, we can very easily import variables and credentials, and connections and certificates by simply right-clicking on one of those items and choosing Add to Canvas. In the case of variables, we can actually get and set variables, so we actually get the option to either Get Variable or Set Variable.

So let's go ahead and build out our very simple PowerShell code to authenticate to Azure, and then retrieve a list of resource groups. To do that, we're going to call the Add-AzureRMAccount command. So we can either type that directly into the editor, or we can go to the AzureRM. Profile module, right-click the Add Azure RM Account command, and click Add to Canvas.

Now, if you're familiar with parameter sets, you can also expand the command and see a list of all the parameter sets that are offered by each command. In this case, we're going to simply use the parameter set that has the credential parameter, and we're going to pass in the PSCredential that we put into the asset store. So we're going to put parenthesis around this, and then we're going to go over to our assets and retrieve the Azure Admin asset. So I'll go ahead and put those parentheses around that Get Automation PSCredential command, which will retrieve the Azure Admin credential, and then pass it into the credential parameter when we invoke the Add Azure RM Account command. Great.

So now that we've authenticated to Azure, we need to make sure that we are operating in the proper subscription context. To do that there is a command called Set-Azure RMContext that also exists inside the AzureRM.Profile module. So I'll go ahead and choose Set-AzureRMContext, right-click on it, and click Add to Canvas. Now, by default it gave me a parameter set that I don't want. So I'm just going to delete that parameter and specify the subscription name. Now, the subscription name we stored inside of the asset store as well, under a variable called "SubName". So we'll close Cmdlets, and then we'll go over to our asset store and say "Get Variable to Canvas". So now, the editor experience inside the Azure Portal has automatically inserted the Get Automation Variable command and retrieved our SubName variable for us, which contains the Visual Studio Ultimate with MSDN text. So now, we're operating in the proper context.

The final thing that we need to do is list out all of our resource groups that are inside the subscription. So we'll go back to AzureRM. Resources, and the AzureRM. Resources module contains a command called "Get Azure RM Resource Group". So we'll go ahead and add that to our canvas, and because we're not going to retrieve a specific resource group, we'll simply delete all the parameters. We'll wrap the command in parenthesis and simply type the property name that we want to retrieve. In this case, we'll get back a series of objects, or an array of objects, from the Get-AzureRMResourceGroup Command, and then we'll basically tell PowerShell that we want the resource group name property from each of those objects. So let's go ahead and save this runbook draft, and then we'll open the test pane to actually test our code.

With the test pane open, I'll click the Start button to invoke the code. As you can see, the runbook is successfully executing. However, we've gotten some additional output here at the top of the runbook that we don't necessarily want from the Add-AzureRMAccount command, as well as Set-AzureRMContext commands.

So let's go back over to our runbook, and to prevent that output from being emitted by these commands, we'll simply assign the output from those commands to the Null variable, which will essentially prevent them from emitting output. We'll go ahead and save that runbook, and then we'll publish it and we can now schedule that runbook to execute on a periodic schedule.

Congratulations. You've created your first runbook.

About the Author

Trevor Sullivan is a Microsoft MVP for Windows PowerShell, and enjoys working with cloud and automation technologies. As a strong, vocal veteran of the Microsoft-centric IT field since 2004, Trevor has developed open source projects, provided significant amounts of product feedback, authored a large variety of training resources, and presented at IT functions including worldwide user groups and conferences.