Skip main navigation

New offer! Get 30% off one whole year of Unlimited learning. Subscribe for just £249.99 £174.99. New subscribers only T&Cs apply

Find out more

Runbook Assets

Welcome back to this video on assets in Automation account. Before trying to explain what assets are, I want you to take a look at this script and see if you can find the obvious problem with it. Note [INAUDIBLE] I’ve have even highlighted where the problem is. This is an innocent IT administrator putting in some effort to create an automation script that will perform some kind of automation operation on Azure. In this case, what the script does is it tries to make a connection to Azure. And it’s got a hardcoded value of the subscription ID and the password.
The problem with this approach is next time you try and do this on another script, you have to change the login or the subscription. What’s even worse is if the subscription ID changes or the user’s no more relevant and you need to change it across all the scripts, you really end up going on a witch hunt identifying where that password or that username was used. So assets allow you to just solve exactly this problem. Assets are living at the Azure Automation level, which means they’re globally available across the Azure Automation account. And assets are a way of abstracting these unique things from within the runbooks– for example, things like variables, things like certificates, things like credentials, things like connection string.
All of these are things that we tend to use a lot in script, but they don’t really need to reside in the scripts. What if there was a way to extract, abstract them out into a central place so that you could use them across script, at the same time, manage them in one central location? That’s exactly what assets are for. So without further ado, we will look at the implementation of assets within the Azure portal, just quickly run through some of the asset options that are available, and then work our way through creating the first runbook where we leverage one of the assets. OK. Let me flip across to the Azure portal.
I’m going to pick the Azure Automation account that I provisioned in the last demo. And as I come in here, you see this tile looking at you saying 21 assets. If I click on the assets, I see there are six assets that are available. And some you can just make sense of by the name itself. For example, Schedules are telling me I can set up a schedule. A schedule is really a point in time, a trigger for the execution of my runbook. But now, what’s really great is you don’t have to write and hack your PowerShell scripts by introducing While loops that never end so that your timers can trickle the script to execute at that given point in time.
Instead, you could just set up a schedule. And it will call that runbook on a recurring or on a unique basis as you’ve schedule for it. So I’m going to add a schedule here– say, for example, for weekend checks for PST. And it’s a recurring thing that happens– well, guess what? Every week. And the recurring option is Saturday and Sunday. And it might just be a PowerShell script that I have a runbook which goes around and checks for certain things across the estate to make sure servers that are not being used are shut down. But I’m just defining a schedule for that.
Now, the other thing is while I have set up a schedule for weekend checks, a weekend’s not common across the globe. I could have a weekend checks for UAE– and by the way, they have their weekend on Friday and Saturday. So let me just set up a recurring schedule again, change that to week, select the recurring option. And I can say Friday and Saturday. Now, if I was to schedule for both of these, then the chances are that both of these would get triggered on Saturday because they both share the same schedule. So that is something you would need to handle within your runbook itself. Azure Automation gives you a way of setting up schedules.
But the implementation of how you handle the schedules resides or needs to be managed within the scope of your runbook. So coming out, let’s look at modules. Now, what you would see here is when you create PowerShell scripts, you usually take dependencies on modules that are already available. Now, if you’re interacting with Azure, chances are you’re going to use the AzureRM module. Rather than you managing the modules within the script yourself, Azure Automation gives you a way of putting the modules at a central level within the account and then using it across all your scripts.
Which means if you wanted to update the module in one place and have it reflected across all your scripts– well, it’s very easy to do. The other thing you will notice here is that you don’t see all the Azure-related modules in here. And you may question, well, I’m going to be using the keyboard, but I don’t see the AzureRM keyboard module here. But what you have is the option of either uploading your own custom modules, the ones that you’ve created or have evolved, or browsing the open-source gallery that is available. So in the open-source gallery, you can search for both the Microsoft Azure modules.
But if you wanted to search for the open-source module, such as XWEB, which allows you to do web administration, then that’s right available. And you see this is a pretty famous module. There’s more than 73,000 downloads– the power of open source. Otherwise, you would have to kind of manage the web administration yourself. So coming here, you have other options like certificates. The certificates that got provisioned as part of the Azure Automation account provisioning process show up here.
So if I wanted to add new certificates to interact with other infrastructure that was outside in a separate data centre or in a vendor data centre, then I can, of course, add that certificate here rather than having to manage that within my script. Then there are the other obvious ones like connection. There is credentials. Say, for example, if I wanted to create a script that tweeted something every time it got triggered, well, clearly, I can put in my Twitter account credentials here. Let me give you another example.
If you wanted to publish the execution updates of your runbook to a Slack channel or to a Teams channel, then you can put in the credentials that need to be used as part of calling that runbook to do the publication right within here, and then parallely use that across all your PowerShell runbooks. So let’s look at the Variables section. In the previous demo, as we provisioned the connection with our GitHub repository, you see it secretly stored the OAuth token that it uses to integrate with GitHub as part of the variables. This is just dogfooding its own implementation. The benefit here is that variables can be different types. As you can see, you have the option for string.
You have Boolean, DateTime, Integer, and Non-Specified. Non-Specified simply means it’s a null that you will instantiate as part of your own PowerShell implementation. So I’m going to put a very simple variable in here. Let’s call it username. And I will use that as part of my runbook that I will create in this demo. So let me just give it a default value called Tarun Arora. Let’s not encrypt it. Let’s click Create. And that means the variable’s now created. And we’ve just briefly looked at all the assets that are available.
While we’re going to cover runbook in great detail– but just to show you how variables can be used or assets can be used within runbooks, I’m just going to create a runbook. I won’t spend too much time explaining the types or the options here because we will cover that in a separate video. But let’s just create a runbook. We’ll call it iactraining.01-demo-runbook.
And the type, I’m going to just select this PowerShell. This is for demo only. Click Create. Behind the scenes, it’s just creating a new PowerShell-based runbook for me. And I get into this beautiful screen where I have an editor for PowerShell right within the scope of Azure. Now, you see I’ve got the option of publishing these changes into the GitHub repo that I connected. This is great. Because as I’m working on a script, if I wanted to collaborate on the script with my peers who are using the Git repo, then it gives me a two-way channel to do that. What it also gives me the test pane.
So as I write the script here, I have the option of testing the script right within the Azure portal. So I’m going to create a very simple script here, which does no more than print hello, world. But what I’m also going to do is I’m going to retrieve the variable that I set up, as I was showing you as I created the variable two seconds ago. And I don’t need to work out how I need to do it or what is the syntax for it because I can simply browse to the Assets sections, the Variable section, and go into the username and say Get Variable. Done, right? Now, of course, I could assign it to a variable.
So let’s call it Username. And then I also have the option of updating this variable right from within this runbook. And I could do that by saying Set Variable. And you see here it gives you the option of passing the value. So what that means is if you are performing an operation within one runbook and an output obtained from that needs to be used by another runbook, then you can use the variables to consume that variable input, store it, and then consume it as part of the execution of another runbook. The other benefit that you get from within here is that you could nest runbooks within runbooks. So for example, I could come in here.
And as part of the execution of this runbook, if I wanted to trigger another runbook, then I could add that also right from within here. So we looked at assets. We looked at creating a vanilla runbook which consumes the assets– in this case, a variable. We looked at how easy it is to retrieve variable values, how easy it is to update variable values, and where it’s really beneficial collaborating on outputs from one script inputting into another. Variables can become the channel to do that.

In the previous step, you learned about runbooks and what runbooks can automate. Let’s explore the Azure Automation assets that are available to you for use in your runbooks.

Azure Automation assets are resources (settings) that are globally available to be used in or associated with a runbook. There are currently six asset categories: Schedules, Modules, Certificates, Connections, Credentials and Variables:

As a best practice, you should always try to create global assets so that they can be used across your runbooks. This will save time and reduce the number of manual edits within individual runbooks.


There may be instances that you want scripts to self-trigger at certain times of the day. The Automation schedule functionality gives you the ability to set up schedules for execution. It supports both single-trigger and multi-trigger schedules. A runbook can be linked to multiple schedules, and a schedule can have multiple runbooks linked to it.

Here is a schedule that runs every night at midnight. To retrieve the schedule, use the Azure PowerShell command Get-AzureRmAutomationSchedule:


A PowerShell module is a set of related Windows PowerShell functionalities grouped as a convenient unit. PowerShell modules can be imported as needed, and are often installed with a particular feature.

For example, if you add the Active Directory role to your server, the Active Directory PowerShell module with all the associated cmdlets will also be installed.

An Azure module asset isn’t very different from a PowerShell module. It’s simply a PowerShell module that optionally contains one additional file: A metadata file specifying an Azure Automation connection type to be used with the module.

For example, email modules typically include a connection type. Azure module assets can be imported to make their cmdlets available for use within runbooks and DSC configurations.

Certain module assets are shipped as global module assets in the Automation service. These global modules are available to you when you create an Automation account. Notice in the graphic Azure.Storage, AzureRM.Automation, and AzureRM.Compute. You can add additional modules by browsing the gallery:


Certificates assets can be stored securely in Azure Automation so that they can be accessed by runbooks or DSC configurations by using the Get-AutomationCertificate activity. This allows you to create runbooks and DSC configurations that use certificates for authentication, or adds them to Azure or third-party resources:


Connection assets define the information required to connect to a service or application. The different types of connections that you can create are defined by the modules imported into Azure Automation:

After you select the connection type, a template that defines the properties needed by the connection will display. For example, the Azure module that comes preinstalled in Azure Automation contains a connection with fields for subscription ID and certificate, which is the information needed to manage your Azure resources programmatically. For example, the SMTPServerConnection type shows properties associated with email server connections:

The properties for a connection are stored securely in Azure Automation and can be accessed in the runbook with the Get-AutomationConnection activity.


An Automation credential asset holds a PSCredential object that contains security credentials. For example, credentials could be your Microsoft Azure login username and password. Runbooks and DSC configurations can use the Get-AzureAutomationCredential cmdlet to authenticate applications and services:


Variable assets are persistent values that are available to all runbooks and DSC configurations in your Automation account. Variables can be String, Boolean, DateTime, Integer or Not Specified.

Variable assets can be encrypted along with credentials, certificates, and connections assets. These assets are encrypted and stored in Azure Automation by using a unique key that is generated for each Automation account.

To retrieve an unencrypted variable, use the Get-AzureAutomationVariable command. To retrieve any encryption assets, use a Get-AutomationVariable activity in a runbook or DSC configuration:

Automation variables are useful for:

  • Sharing a value among multiple runbooks or DSC configurations.
  • Sharing a value among multiple jobs from the same runbook or DSC configuration.
  • Managing a value from the portal or from the Windows PowerShell command-line that’s used by runbooks or DSC configurations, such as a set of common configuration items like a specific list of virtual machine (VM) names, a specific resource group, or an Active Directory domain name.
This article is from the free online

Microsoft Future Ready: DevOps Development, Implementation and Azure Automation

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now