In this article, you will discover the different types of runbooks.

Types of Runbooks

Graphical Runbooks

Graphical runbooks allow you to create runbooks for Azure Automation without the complexities of the underlying Windows PowerShell or PowerShell Workflow code. You create your workflow by adding activities from the library, linking them together, and then configuring the components.

Graphical and graphical PowerShell Workflow runbooks are created and edited with the graphical editor in the Azure portal. You can export them to a file and then import them into another automation account, but you can’t create or edit them with another tool. Graphical runbooks generate PowerShell code, but you can’t directly view or modify the code.

Graphical runbooks can’t be converted to one of the text formats, nor can a text runbook be converted to a graphical format. Graphical runbooks can be converted to graphical PowerShell Workflow runbooks during import, and vice versa.

Powershell Runbooks

You can use the textual editor in Azure Automation to edit PowerShell runbooks and PowerShell Workflow runbooks. The code editor has IntelliSense and colour-coding, with additional special features to assist you in accessing resources common to runbooks.

You can insert code for activities, assets and child runbooks into a runbook. Rather than typing in the code yourself, you can select from a list of available resources and have the appropriate code inserted into the runbook.

Each runbook in Azure Automation has two versions called Draft and Published. You edit the Draft version of the runbook and then publish it so that it can be executed. The published version can’t be edited.

Webhooks

There are two basic ways to start a runbook. The first is by putting the runbook on a schedule. The second is by using a webhook.

A webhook allows you to start a particular runbook in Azure Automation through a single HTTPS request. This allows external services such as Visual Studio Team Services, GitHub or custom applications to start runbooks without implementing a full solution by using the Azure Automation API.

Configuring a webhook is simple enough:

1. Name: You can provide any name you want for a webhook because this information is not exposed to the client. It’s only used for you to identify the runbook in Azure Automation.
2. URL: The URL of the webhook is the unique address that a client calls with an HTTP POST to start the runbook linked to the webhook. It is automatically generated when you create the webhook. You cannot specify a custom URL. The URL contains a security token that allows the runbook to be invoked by a third-party system with no further authentication. For this reason, it should be treated as a password for security purposes.
3. Enabled: A webhook is enabled by default when it is created.
4. Expires: Like a certificate, each webhook has an expiration date at which time it can no longer be used. This expiration date cannot be changed after the webhook is created, and the webhook also can’t be enabled again after the expiration date is reached.

A webhook can define values for runbook parameters that are used when the runbook is started by that webhook. The webhook must include values for any mandatory parameters of the runbook and may include values for optional parameters.

Source Control Integration

Azure Automation supports source control integration so that you can associate runbooks in your Automation account to a GitHub source control repository. Source control allows you to easily collaborate with your team, track changes, and roll back to earlier versions of your runbooks. For example, source control allows you to sync different branches in source control to your development, test, or production Automation accounts. This makes it easy to promote code that has been tested in your development environment to your production Automation account.

Source control allows you to push code from Azure Automation to source control or pull your runbooks from source control to Azure Automation.

After creating a repository in GitHub, you only need to select Set Up Source Control from the Automation Account blade in the Azure portal. When the blade opens, you can configure your GitHub account details. The parameters will be displayed on the Set Up Source Control blade:

Runbook Gallery

Azure Automation runbooks are provided to help eliminate the time it takes to build custom solutions. These can be used with or without modification. Runbooks can be imported from the Runbook Gallery.

In the Azure portal, you can import directly from the Runbook Gallery by opening your Automation account, selecting the Runbooks tile, then selecting the Browse gallery button, locating the gallery item that you want and selecting it, and clicking the Import button.

PowerShell Gallery

Along with the Runbook Gallery, the PowerShell Gallery provides module solutions that you can use without modification or as a starting point. PowerShell modules contain cmdlets that you can use in your runbooks and existing modules that you can install in Azure Automation. You can launch the PowerShell Gallery from the portal and install modules and cmdlets directly into Azure Automation, or you can download them and install them manually.

In your Automation account, select the Assets tile and then select the Modules tile to see a list of modules. By clicking on the Browse gallery button, you can search for models or cmdlets by using the fields. To see more information, select the module, and then click the Import button. If you are missing dependencies, the OK button will not be active. After you have the required dependencies installed, click the OK button to begin the import:

Operations Management Suite (OMS) Log Analytics

To get insight into your Azure Automation jobs to troubleshoot issues, Automation can send runbook job status and job streams to a Microsoft Operations Management Suite (OMS) Log Analytics workspace. Logs and streams are visible in the Azure portal or with Windows PowerShell for individual jobs so that you can perform investigations.

You must set up a Log Analytics workspace to send your Automation logs to Log Analytics. After the workspace is established, you use the ResourceId for your Azure Automation account to configure integration with Log Analytics in PowerShell.

After you have Automation set up to send job logs to Log Analytics, you can send an email when a runbook job fails or suspends, find all jobs that have completed with errors, view job streams for a job, and view historical status. With greater operational visibility into your Automation jobs, you can address incidents more quickly.

Join the discussion

In your opinion, what makes a good runbook?

Use the Discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to move on to the next step.