Azure Automation allows you to automate the creation, deployment, monitoring, and maintenance of resources in your Azure environment using a highly scalable and reliable workflow execution engine. Orchestrate time-consuming and frequently repeated tasks across Azure and third-party systems to decrease time to value for your cloud operations. For full details on Azure Automation service, see Automation service.

This blog will cover the following topics with more emphasis on why we created Azure Automation assets and what are the benefits on top of PowerShell. For details on how to create and use Automation assets in detail, please see https://technet.microsoft.com/en-us/library/dn457809.aspx (note: this page talks about Service Management Automation and Azure Automation assets. The sections/cmdlets that currently only apply to Service Management Automation are called out on the page)

• What are Automation Assets?

• Why we created Automation Assets

• Benefits on top of PowerShell

• How to use them in Runbooks

What are Automation Assets

The Assets page in Automation displays the various resources (also called “settings”) that are globally available to be used in or associated with a runbook, plus commands to import an integration module, add a new asset, or delete an asset. Assets include variables, schedules, credentials, and connections.

High-level definition of the Automation Assets:
•    Variables:
Variables are values that are available to all runbooks.  They can be created, modified, and retrieved from the Azure Portal, Windows PowerShell (coming soon), or from within a runbook.  They can be used in runbooks to define frequently-used settings, such as directory paths to common files, server names, or other strings. Variable settings store string, boolean, integer, or datetime information that can then be used in a runbook. They can also contain complex objects (stored as property bags), although you must use PowerShell to do this as it cannot be done through the Automation UI.

•    Connections:
Connections define the information required to connect to a service or application from a runbook.  The different types of connections you can create are defined by the integration modules imported into Automation, and typically include such information as the username and password and the host or service URI to connect to. For example, the Azure module which 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. The properties for a connection are stored securely in the Automation, and can be accessed in the runbook with the Get-AutomationConnection activity.  This information can then be passed as one or more parameters to the integration modules activities, to make required connections.

•    Credentials
Credentials are either a username and password combination that can be used with Windows PowerShell commands or a certificate that is uploaded to Azure Automation. The properties for a credential are stored securely in Automation, and can be accessed in the runbook with either the Get-AutomationPSCredential or Get-AutomationCertificate activity.

•    Schedules
Azure Automation Schedules are used to schedule runbooks to run automatically.  This could be either a single date and time for the runbook to run once, or it could be a recurring schedule to start the runbook multiple times.

•    Integration Modules
Azure Automation runbooks rely on PowerShell cmdlets (referred to as “activities” in Automation) to access different systems, services, and devices. An integration module is a package that contains a Windows PowerShell Module and can be imported into Azure Automation.  Imported modules are distributed to all Azure Automation worker servers so that they are available to runbooks.

For more information on integration modules, please refer to following articles:
•    Authoring Integration modules blog post (this blog speaks to Integration modules in Azure Automation, but they are basically the same Service Management Automation)
•    “Building an integration module” section in this TechNet document

Why we created Automation Assets
You can create assets by clicking on Assets tab and then selecting ‘Adding Setting’ option

 

Select the type of Asset you want to create

The following section talks about the challenges without Automation Assets and the value they bring.

Variables:

Challenge: It is common for multiple runbooks to use the same data. Rather than hard coding this data into each runbook, it is better to have some way to store the data in one location, and reference it from within each runbook. That way, when the data changes, updates only need to be made in one place. Without variables, users have to think about using files, databases or other external ways to exchange/share data between runbook jobs. The challenges with that is they have to establish their storage mechanisms, communication protocols and this may be complicated and cumbersome, as well as have race conditions.

Azure Automation solution: Variables are created to

· Share a value between multiple runbooks.

· Share a value between multiple jobs from the same runbook.

· Manage a value from the Azure Portal or from the Windows PowerShell command line that is used by runbooks.

 

Connections:

Challenge: Azure Automation provides an ability to integrate with external systems. In order to connect with external systems, users have to find the way to provide all the data necessary (for e.g., Username, password, port #, protocols etc.) for connecting to external systems. Some of the challenges are

· Different systems require different type of data. For e.g., URLs, Port numbers, protocols

· Passing that connection data into the Runbook.

o Users can pass the connection data as Runbook parameter and problem is that is they have to enter every time when the runbook is executed. Other challenge is that they have to provide this data which is not grouped together(pass separate parameters)

o Other option is to provide variable or set of variables for each piece of connection data. This mitigates the first problem of entering the data every time, but still has problems of grouping the data together

· This data being separate and not grouped together, any change in the connection data structure have to be replicated in all the places (parameters, variable, multiple runbooks, etc)

Azure Automation solution: Azure Automation created Connection type asset to

· Group the connection data necessary to connect to an external system into a single object so that it can be accessed by runbooks easily

· Provide a template describing how a connection for a certain system should look like so that users can use this template when defining the connection to this system

· Changes to the connection data can be made in a single place without having to replicate the change in multiple locations (variable assets, runbooks, etc)

 

Credentials:

Challenge: Runbook needs to connect to external systems and thus need credentials. Without ‘Credentials’ type, users have to find ways to pass credentials to runbooks and also have to keep them secure. This is not a trivial problem to solve.

Azure Automation solution: Azure Automation provides a unified and secure way to store and reference credentials in runbooks.

Schedules:

Challenge: Many times runbooks need to be run on a repeated schedule. Without a ‘Schedule’ type asset, users have to run runbooks manually at the correct time or invent their own mechanism.

Azure Automation Solution: Azure Automation provides ability to run your runbooks at a single time in the future or on recurring schedule.

 

Benefits on top of PowerShell Workflow

In order to provide high availability of workflow execution, Azure Automaton executes PowerShell code in different PowerShell sessions, in different processes, and even on different machines. In this context, replacing Automation Assets with regular mechanisms available in pure PowerShell workflow is very challenging. The usage of assets gives:

• Centralized management of constant values

• Sharing of assets (Variables, Connections, and Credentials) between jobs. In PowerShell you can do this but have to invent your own mechanism.

• Secured management of credentials and connections

• Out of box scheduling capability

 

How to use assets in runbooks, with examples

In the below examples, you will find how to access Automation assets in runbooks.

Variables:

The activities in the following table are used to access variables in a runbook.

Activities	Description
Get-AutomationVariable	Retrieves the value of an existing variable.
Set-AutomationVariable	Creates a new variable or sets the value for an existing variable.

Example

$server = Get-AutomationVariable –Name ‘ServerName’

Set-AutomationVariable –Name ‘ServerName’ –Value $server

Credentials:

The activities in the following table are used to access credentials in a runbook.

Activities	Description
Get-AutomationCertificate:	Gets a certificate to use in a runbook.
Get-AutomationPSCredential:	Gets a username/password to use in a runbook, as a PSCredential

Example:

$credential = Get-AutomationPSCredential –Name ‘MyCredential’

$certificate = Get-AutomationCertificate –Name ‘MyCertificate’

Connections:

The activities in the following table are used to access credentials in a runbook.

Activities	Description
Get-AutomationConnection	Gets a connection to use in a runbook

Example:

$connection = Get-AutomationConnection –Name ‘MyConnection’

Do-Something –Connection $connection

Summary

Hopefully by now you have a better understanding of all the wonderful things you can accomplish using Azure Automation assets, how you’d create one, and what are the challenges they solve and benefits over pure PowerShell. The Automation team is super excited to see the runbooks you write to take advantage of the functionality of Automation assets.

Not an Azure Automation user yet? Sign up for the preview and then check out the Getting Started guide.

Until next time, happy automating!