The definitive guide on Azure Automation Account to help you and your team get the most out of Azure AD.
From basic user tips to more advanced features, as with most of Microsoft’s tools, there are always features you hadn’t realised were there that can save you time, make you more productive, or are just fun and cool. We hope we have covered a good few of them for you here.
Let’s get started!
- The Azure Automation account helps you to coordinate regular deployment and life cycle management activities using Windows PowerShell Workflow functionality-based runbooks using a highly scalable workflow execution environment.
- You can significantly minimize the occurrence of errors when carrying out repeated tasks and process automation by automating runbooks.
- The design and design of runbooks along with their implementation and troubleshooting are discussed in this article. In order to help your scripts be more productive and succinct, Microsoft has provided some sample runbooks after which you can pattern your runbooks, copy and alter, or use as-is. The uses of some of those sample runbooks will also be discussed.
As well as understanding basic Azure provisioning and deployment, you should be somewhat familiar with the concepts behind Windows PowerShell programming. If you have written and run some Windows PowerShell code, it helps, especially when it applies to the Azure PowerShell Management API. We’re going to look at some Windows PowerShell workflow scripts for Azure Automation and break down what they’re doing. It might be a real challenge for you if this is your first time using Windows PowerShell.
This post includes seven chapters, each of which focuses on an aspect of Azure Automation, as follows:
- Introduction to Azure Automation: Provides a description of Azure Automation and the circumstances for which it is ideally adapted, looking at what it entails. This demonstrates how to allow Azure Automation and how to build an Azure Automation account, which is the root entity at the highest level for any of the automation artifacts under that account.
- Control of runbooks: discusses how to handle runbooks, which are logical containers that arrange Windows PowerShell workflows and contain them. Also, learn about the authentication concept and the role of Azure Active Directory or management certificates.
- Assets: Defines the organizations in an Azure Automation account that runbooks can leverage internationally through all runbooks. Learn about the assets of variables, certificates, connections, and schedules.
- Runbook deployment: Discusses having a runbook published after it has been written and tested. It also offers few tips for troubleshooting.
- Azure Script Hub, archive, and community: Read more about the features of Windows PowerShell Workflow, the execution process, and how runbooks contribute to Azure Automation. Provides an outline of the reusable script tools that you can import and use entirely or in part in your runbooks.
- Best practices: To simplify and maximize the use of Azure Automation, look at the key guidelines.
- Scenarios: Explore a few common Azure Automation scenarios in detail that you can hopefully link to your daily work.
Conventions and features
To create specific Azure resources, follow the steps listing each action you must take to complete the exercise.
- As of this writing, features related to Azure Automation are available in the Azure Portal.
- Boxed elements with labels such as “Note” or “See Also” provide additional information.
- A plus sign (+) between two key names means that you must press those keys at the same time.
- For example, “Press Alt+Tab” means that you hold down the Alt key while you press Tab.
- A right angle bracket between two or more menu items (e.g., File Browse > Virtual Machines)
- means that you should select the first menu or menu item, then the next, and so on.
- Microsoft Azure Automation assets are global resources used by runbooks to assist in common tasks and value-specific operations. Assets can be imported into modules. Types of assets include connections, credentials, schedules, variables, and integration modules.
- Global connections and credentials help authenticate between the Windows PowerShell workflows and Azure when the Azure Automation scripts are run against a specific Azure subscription. For instance, Microsoft published the Connect-Azure runbook, which can be used globally within an Azure Automation account to encapsulate the connection and login functionality needed to connect to Azure.
- Schedule assets can be linked to runbooks, allowing them to run at a specific date and time. Variable assets are used to provide runtime values for runbooks to work on specific subscriptions, as well as to control the logic within the Windows PowerShell code.
- Azure Automation is incorporated into Azure Active Directory (Azure AD), which allows simpler management of identity and access for users and groups to the Azure Automation accounts and runbooks.
- Authentication can now be done with an account within Azure AD instead of having to manage and use management certificates.
- Using Azure AD greatly simplifies the process of authentication over using management certificates. The account in Azure AD can also be reused and leveraged in other Azure services that support the use of Azure AD.
- To run Windows PowerShell Workflow scripts from Azure Automation, you first have to authenticate during the connection using Windows PowerShell credentials or a certificate.
- You must connect in an authenticated manner to Azure to be able to run any commands against resources within a subscription. Authentication must be set up between Azure Automation and the Azure resources in an Azure subscription that you intend to manipulate via script. You can upload a management certificate to handle this authentication within an Azure subscription.
- Azure uses X.509 v3 certificates for authentication in many places. These certificates can be self-signed (usually done for development or testing) or signed by a trusted signature authority (usually done for production).
- Typically, you upload a .cer file as a management certificate. Certificates used by Azure can contain a private or public key. A .cer management certificate file does not contain the private key embedded within it, as does a .pfx service certificate (a .pfx file is used to secure client calls to cloud services).
- Certificates have a thumbprint that provides a means to identify them in an unambiguous way to Azure. For a .cer file, the client connecting the service needs to be trusted and have the private key.
- You can share certificates across Azure subscriptions with different subscription owners. This helps you to limit the actual number of certificates you have to create in an enterprise subscription. The limit is 100 certificates per subscription.
- A management certificate is not an automation asset per se, although it is global to the subscription in its scope. You upload the management certificate just like any other management certificate in Azure, such as certificates used for Azure Recovery Services, via the Management Certificates tab under Settings.
- However, for Azure Automation, the management certificate is also uploaded as an Azure Automation Credential asset if you choose to authenticate using the Certificate Credential asset. This is a key point: To work correctly for Azure Automation, a management certificate has to exist both in the Settings for the subscription and be created as a Certificate automation asset. Why the certificate needs to exist concurrently in two different forms at once at first might seem very confusing.
- The Certificate Creation Tool (Makecert.exe) that ships with the Windows SDK provide information about how to create a self-signed management certificate. You can also create one using Internet Information Services (IIS). Alternatively, you can obtain a signed certificate from a verified certificate authority. However, authenticating with a certificate is no longer recommended for Azure Automation.
- After you have the management certificate file (.cer) that contains the public key, you must upload it to Azure. Sign into the Azure Management Portal, click Settings, and then click Management Certificates. Click Upload, and then in the Upload A Management Certificate dialog box, browse to the location of your .cer file and select it. As shown below, select the subscription to which you want to apply the certificate file, and then click the checkmark to upload it to the Azure Management Portal.
After the upload completes, the certificate is displayed in the list of management certificates. The thumbprint is the public key component of the certificate. It’s used with the private key component and verified against any of the loaded certificates for the subscription when Azure Automation is making requests to Azure.
After you have loaded a management certificate into Azure, you’re ready to create a certificate.
Azure Active Directory and automation
Authenticating using management certificates is the original and primary way to secure your calls from your Azure Automation scripts into the Azure environment, but there are a lot of steps to create and upload the certificates to Azure. Managing them can also require a lot of organizational effort.
To enable Azure Automation for a new user, do the following:
- Create the user in Azure AD. For more information about creating a user in Azure AD, see Create or edit users.
- Add the user as co-administrator to your Azure subscription. Log in to the Azure Management Portal at manage.windowsazure.com, click Settings, click Administrators, and then click Add.
- Log in to the Azure Management Portal as the Azure Automation user you created and change the password when prompted.
This procedure isn’t necessary if you want to use an existing Azure user account. After the user is created, you will want to create an Azure Automation credential asset with the login credentials of that user. As a best practice, it often makes sense to create a user account just to use for running your Azure Automation scripts. You can access the Azure Automation credential asset from within your Azure Automation runbook. The runbook code gets the credentials from Azure Automation, using the Azure Automation credential asset, and then uses the credentials to authenticate when it connects to Azure.
In the following example, Justin Blake is the credential asset used to authenticate with Azure AD. The Windows PowerShell workflow code makes a call to the Get-AutomationPSCredential cmdlet to authenticate the script:
# Grab the credential to use to authenticate to Azure.
# TODO: Fill in the –Name parameter with the name of the Automation PSCredential asset
# that has access to your Azure subscription
$Cred – Get-AutomationPSCredential –Name “justinblake.onmicrosoft.com”
# Connect to Azure
Add-AzureAccount –Credential $Cred
# Select the Azure subscription you want to work against
# TODO: Fill in the –SubscriptionName parameter with the name of your Azure subscription
Select-AzureSubscription –SubscriptionName “Windows Azure MSDN – Visual Studio Ultimate”
# Get all Azure VMs in the subscription and output each VM’s name
Get AzureVM | select InstanceName
Although using management certificates to authenticate Azure Automation runbooks is still supported, as a best practice, use Azure AD for all your Azure Automation authentication mechanisms whenever possible.
Azure Automation assets
Assets are useful for keeping your configuration values consistent across all runbooks. Using assets simplifies runbook maintenance by storing and maintaining configuration values in a central location. You will most likely want to use assets across multiple runbooks, so allowing updates in one place ensures the changes are reflected everywhere they are used.
- The scope of assets is global within an Azure Automation account and shared across all runbooks in that account.
- For example, If we have a variable in Asset 1, a credential in Asset 2, and a schedule in Asset 3, with runbooks A and B in the same Azure Automation account AA, either runbook can use Assets 1, 2, and 3. When accessed in code, both runbooks get the same value for all the assets in their respective scripts.
- If the value is changed in runbook A, the change will be reflected in runbook B the next time it is accessed. However, runbooks in another Automation account (say BB) but in the same subscription will not have scope for any of the assets in Automation account AA.
You can view all the assets you have for a particular Azure Automation account. Log in to the Azure Management Portal, click Automation, select the Azure Automation account, and then click Assets. The below screenshot shows each of the different types of assets: certificate, connection, credential, module, schedule, and variable.
Within Azure Automation, variable assets play an important part in the Windows PowerShell Workflow scripts in the runbooks. A variable is nothing more than a name that represents a value. We can use variables to reflect changing or current values rather than entering hard-coded data directly into the script code. When the script is run, the variables are replaced with real values. This makes variables quite flexible in that they can hold and reflect data that could be different each time the runbook is run.
A variable is an asset you define that has global scope (as do all types of assets) across all runbooks in that Azure Automation account. There are four types of variables – string, integer, Boolean, DateTime and a special class named Not Defined that is a null value. For all types but Not Defined, you can define an initial value.
To create a variable asset, do the following:
- Log in to the Azure Management Portal, click Automation, select the Azure Automation account, click Assets, and then click Add Settings.
- In the Add Settings dialog box, options are available to add a connection, credential, variable, or schedule. Click Add Variable to open the Define Variable dialog box.
- Click Variable Type and, then select String. In the Name text box, enter a name for the variable. Enter a description (this is optional). Click the right arrow to go to the Define Variable Value dialog box.
- In the Value text box, enter the initial value for the string. This is optional, as you can leave the variable uninitialized at the start if you choose and later assign it a value at runtime or through script code.
- After you enter the value, you can choose to encrypt the variable. Select No if you want to see the value of the variable in the Azure Management Portal. Select Yes if you do not want to see the value of the variable in the portal.
- When a value is encrypted, it’s displayed with circle symbols in the portal instead of its actual characters. However, it does not encrypt the data in storage. Only the appearance in the UI is encrypted. Click the checkmark to create the variable.
Using a variable asset
To use variable assets in a runbook, you must assign (Set) them a value in code or access (Get) their current value to do something with that value. For example, use the Set-AutomationVariable activity to set the value of a variable asset. Correspondingly use the Get-AutomationVariable activity to get the value of a variable asset. Both of these activities are part of the core Azure module, as are most of the Azure PowerShell activities used in this book.
Note For example purposes, this book uses a runbook named Demobook.
- To set a variable value, log in to the Azure Management Portal, click Automation, click the Automation Account, click Runbooks, and then click the runbook of interest. Click the Author tab to edit that runbook.
- Move the cursor to the location where you want to make the insertion in the Demobook runbook, and then click Insert > Setting.
- In the Insert Setting dialog box, select a setting action (Get or Set), and then select a setting name.
- This example is about setting a variable value, so select Get Variable. You can use an existing variable and set a value for it, or if the variable does not exist, create one. Choose a setting name for an existing variable. Setting Details shows the current value for that variable.
- Click the checkmark to insert the Get-AutomationVariable activity into the runbook code at the location of the cursor. By default, if you don’t move the cursor, the activity is inserted in the first column in the first row. If you insert a setting at that location, it will remove the name of your runbook.
To insert the Set-AutomationVariable activity, use the same process except choose that activity from the Setting Action column in the Insert Setting dialog box.
You can use the Get-AutomationVariable and Set-AutomationVariable activities together to understand the concept of global scope for assets. The following process uses the mysamplestring variable asset and the Demobook runbook shown previously. In addition, a second runbook example named Demobook2 shows the global scope across runbooks of a variable asset.
- Create a temporary variable $testValue, and then assign it the value of mysamplestring. Make a call to write-output to display the original value of $testvalue. Click Test to run and show this output.
- Create a new runbook called Demobook2.
- Assign a new value to mysamplestring of the new value for mysamplestring. Click Insert >Setting. In the Insert Setting dialog box, under Setting Action, select Set Variable. In Setting Name select the setting name, and then click the checkmark. This action results in the following being written to the Demobook runbook at the current cursor location:
Set-AutomationVariable -Name ‘mysamplestring’ -Value
- Replace the with $newmysamplestring. This sets the value of mysamplestring to the value contained in $newmysamplestring. Call Get-AutomationVariable to obtain the value of mysamplestring into the $testvalue variable, which has just changed. Call write-output to display the value of $testvalue. Click Test to run the code and see the output of both the original global value of mysamplestring of mysamplestring and the updated global value of new value for mysamplestring.
- This example demonstrates that all runbooks in an Azure Automation account share the same global value for mysamplestring.
- If one runbook changes its value, the change is reflected across all runbooks in that automation account. Also note that if you have a variable asset in another of your automation accounts by the same name mysamplestring, in this case, it will be a completely different value and in a different storage location than the mysamplestring variable in your other runbook.
- This principle applies not just to variable assets, but to other assets you can insert into code, including connections, certificates, and Windows PowerShell credentials. Schedule assets are a bit different from the other types of assets in that you don’t call them in scripts. However, their capability is still global to all runbooks in an Azure Automation account.
Integration module assets
Integration modules are published Windows PowerShell libraries that can be imported into Azure Automation as a module asset and used when authoring runbooks. They can be up to 30 MB in size and must be in zipped format. By default, when you create an Automation Account, the Azure PowerShell module is imported. This module asset supplies all the Azure PowerShell cmdlets (also referred to as activities) that you can use in your runbooks. You can see the Azure module by itself initially when an Azure Automation account is created. Additionally, you can import additional Windows PowerShell Workflow modules as assets.
Importing an integration module asset
To import a module asset, do the following:
- Download the module asset as a .zip file and then save it locally.
- In the Azure Management Portal, click Automation, select the Azure Automation account, and then click Assets.
- Click Import Module to browse and select the module to be imported, and then click the checkmark to begin the import process. The display shows it is unzipping the activities in that module. After the module has completed the import process, it is displayed at the Azure Automation Account level under Assets as a Module asset type.
The most common issue encountered during importing a module is that the zipped module package must contain a single folder within the .zip file that has the same name as the .zip file. Within this folder there needs to be at least one file with the same name as the folder and using the extension .psd1, .psm1, or .dll. Also, the Integration Module package is a compressed file with the same name as the module and a .zip extension. It contains a single folder also with the name of the module. The Windows PowerShell module and any supporting files, including a manifest file (.psd1) if the module has one, must be contained in this folder.
Integration modules versus runbooks
A common misunderstanding in Azure Automation is the concept of a module versus a runbook, as well as the terms import and insert.
An Azure Automation runbook is an execution unit that contains Windows PowerShell Workflow scripts. Scripts are a program, a group, or many Windows PowerShell commands in one file. Runbooks contain scripts. A runbook that is less than 1 MB in size and not currently part of an Azure Automation account can be imported in PS1 format into that Azure Automation account. When a runbook is invoked, it is sent to a virtual runtime environment to run, which occurs transparently behind the scenes. Runbooks are invoked by a schedule, called by other runbooks (when the runbook has been published) when they are inserted during authoring, or run manually by themselves.
A module is a group of activities (cmdlets) that you can insert into a runbook after the module has been imported. You can import a module into an Azure Automation account via controls in the Assets area of the Azure Management Portal runbook UI. All runbooks in an account can then call any activities of that runbook. (Remember, an activity is a cmdlet.) The module must be in zipped format, up to a 30 MB limit. By default, Azure activities are imported as assets for use in all your runbooks. In the Azure Management Portal, when you look at Assets under any new Azure Automation account, the runbook that contains the Azure activities is named Azure.
When in Author mode for a runbook, you can choose Insert and then select Activity to display the dialog box. In the Insert Activity dialog box, you can choose the integration module and then select an activity to see its description.
The list of parameters for the Add-AzureDisk activity. The DiskName and MediaLocation parameters are required when you make the call to Add-AzureDisk. The Label and OS parameters are not required.
When you click the checkmark to close this dialog box, a template for Add-AzureDisk is added to the cursor location for the runbook. In the following code example, note the line continuation character ` at the end of each line as it is inserted. Azure uses this method to insert each activity into a script. If you prefer, you can remove these characters and put the command all on one line.
Due to the lack of brackets [ ] around them, the first two parameters, DiskName and MediaLocation, are required when using this activity. The other two parameters in [ ] square brackets, Label and OS, are optional. You would replace the entities with actual string values or temporary variables. For instance, the call within your runbook at runtime might look something like the following example:
Add-AzureDisk -DiskName “MyDiskName” -MediaLocation “http://mystorageaccount.blob.core.azure.com/vhds/winserver-system.vhd” -Label “BootDisk” -OS “Windows”
The credential asset is used to gain secure access to external systems, networks, databases, services, and so on. You can run it as a security principal that gives an identity to the call into that external system. This asset is used most commonly in IaaS deployment situations such as authenticating when accessing a SharePoint or a SQL Server IaaS VM. Credential properties are stored in Azure Automation assets and are referenced inside of script workflows using either the Get-AutomationCertificate or the Get-AutomationPSCredential activity.
When using credential assets, you can authenticate using either a certificate credential or a Windows PowerShell credential. Certificate credentials are based on a management certificate. It’s a best practice to use Azure AD for the certificate. The connection asset uses the management certificate to authenticate to that subscription. A Windows PowerShell credential uses the script when it connects to the VM and needs to provide a username and a password. Typically this identity is used to log into an Azure VM.
Creating a credential asset
To create a credential asset, do the following:
- In the Azure Management Portal, click Automation, select the Azure Automation account, and then click Assets. Click Add Setting.
- In the Add Setting dialog box, click Add Credential.
- In the Add Credential dialog box, select the Credential Type of the setting you want to add. In the following screenshot, the Certificate credential type is selected. The other credential type option is Windows PowerShell Credential, where the user will need to provide the user id and password credentials.
- In addition, provide a name and brief description in the Name and Description text boxes. After you have provided the information, click the right arrow.
- On the Upload, A Certificate File page, browse for a certificate file, which can be a .cer or .pfx file.
- After you load the certificate and create the credential, you can go to the Assets tab, find your new credential, open it, and see the certificate details, as shown below. Note the value of the thumbprint.
- If you go into the management certificate section of the Azure Management Portal and find the certificate you just loaded up for this credential, you will see that same thumbprint value. When Azure Automation tries to authenticate, it will use this credential to access the thumbprint and pass it to Azure. Azure will attempt to match the thumbprint of the credential to that of the corresponding certificate to authenticate the call.
Connections are assets that contain information to connect to external networks or systems. For these external connections, a method must present all the data necessary for connecting to external systems. This could mean ports, protocols, usernames, and passwords. Potential complications are that different systems require different types of data to be passed from the runbooks. Assets allow a runbook to connect in a consistent manner using a subscription ID and certificates that are already in that account. To connect to Azure, connection assets use credential assets as the part of the connection that contains authentication information, along with the subscription ID.
Creating a connection asset
To create a connection asset, do the following:
- Open Notepad so that it’s available to store some temporary data used to create the connection asset.
- In the Azure Management Portal, click Automation, select the Azure Automation account, and then click Dashboard. In the Quick Glance section, scroll to find the subscription ID. Copy its value to Notepad.
- In the Azure Management Portal, click Settings, click Management Certificates and find the name of the automation certificate in the Name column. Copy the name to Notepad.
- Click Automation, click the Azure Automation account, click Assets, and then click Add Setting. Select Add Connection and then in the Configure Connection dialog box, select the type of connection you want to add. The only connection type that is available at this time is Azure.
- Click the right arrow to configure the connection properties. Here you need to add the name of the Azure Automation certificate and the subscription ID that you previously copied into Notepad. Click the checkmark to complete the creation.
- When you’re done with this process, open the connection you just created to view the connection details. On the Connection Details page, you find the name of the connection, the day and time it was last updated, its type, a description, the subscription ID, and the Automation certificate name.
Using the Connect-Azure runbook
Microsoft has created a collection of sample runbooks and published them for free public download and use in the MSDN Library at Sample runbooks for Azure Automation. The Connect-Azure runbook is one of the most commonly used runbooks. This runbook is used to connect to an Azure subscription. You will probably want to import it into most of your runbooks that connect to Azure to do operations. A script that is running while hosted in an Azure-managed VM process must connect to your Azure subscription to access the resources you are trying to manipulate with the script.
You can import the Connect-Azure runbook into your Azure Automation account, and then publish it so other runbooks can call it. After it’s imported, the Connect-Azure runbook can be a key part of your connectivity, leveraging assets for Azure Automation. This is because it uses the Azure connection and credential assets, which you need for any Azure Automation connection. It inserts the Azure Management certificate from the local machine store to set up a connection to the Azure subscription.
Before you use this runbook, you must make sure that you have an Automation certificate asset in Azure that holds the management certificate. You must also have a connection asset containing the name of the certificate and the subscription ID.
Before we talk in more detail about this runbook, recall that we mentioned earlier the ability to authenticate now with Azure AD and not have to use management certificates. At the end of this section, I discuss a bit about how to do that. However, the concepts shown in the Connect-Azure runbook are still applicable and are great examples of how to use the credential and connection assets together to authenticate the runbook to Azure. It also is a very good example of how to call an imported runbook from another runbook.
Azure Automation Account Pricing
- With Azure Automation you can save time, reduce errors and increase efficiency while lowering your operational costs. Automate all your frequent, time-consuming and error-prone IT management tasks, in the cloud or on-premises, freeing up your own time to focus on work that adds business value. Automation works with all the Azure services you know and love, as well as on-premises systems and those in other clouds. You can also use Automation to connect and manage any online service with an API.
- Azure Automation provides capabilities to do process automation, update management, desired state configuration, track changes and collect inventory.
- Process automation is priced per job execution minute while configuration management is priced per managed node.
- Process automation includes runbook jobs and watchers. Billing for jobs is based on the number of job run time minutes used in the month and for watchers is based on the number of hours used in a month. Charges for process automation are incurred whenever a job or watcher runs. You will be billed only for minutes/hours that exceed the free included units.
|FREE UNITS INCLUDED (PER MONTH)**||PRICE|
|Job run time||500 minutes||$0.002/minute|
Configuration management includes the configuration pull service and change tracking capabilities. Billing is based on the number of nodes that are registered with the service and the log data stored in the Azure Log Analytics service.
Charges for configuration management start when a node is registered with the service and stop when the node is unregistered from the service. A node is any machine whose configuration is managed by configuration management. This could be an Azure virtual machine (VM), on-premises VM, physical host or a VM in another public cloud. Billing for nodes is pro-rated hourly.
|FREE UNITS INCLUDED (PER MONTH)**||PRICE|
|Non-Azure node||5 nodes||$6/node|
Update management includes visibility and deployment of updates in your environment. There are no charges for the service, you only pay for log data stored in the Azure Log Analytics service.
|FREE UNITS INCLUDED (PER MONTH)**||PRICE|
Support & SLA
- Free billing and subscription management support.
- Flexible support plans starting at $29/month. Shop for a plan.
- Guaranteed 99.9% of planned jobs start within 30 minutes. Read the SLA.