Code Library

If you don’t want to import a runbook, you can create a runbook in the Azure Management Portal. You have two options: Create a runbook by using Quick Create or create a runbook from the Gallery.


Create a runbook using Quick Create
To create a runbook using Quick Create, do the following:

1. Sign in to the Azure Management Portal at manage.windowsazure.com.

2. Click Automation, and then click New.

3. On the New page, App Services and Automation are already selected. Click Runbook, and then select Quick Create.

4. In Quick Create, provide the following information:
- Runbook Name This name can be whatever you want. However, in keeping with the Windows PowerShell format of verb-object, as a best practice it makes sense to name the runbooks accordingly.
- Description If you have many runbooks in your Automation account, the names might become confusing after a while. It’s a good idea to enter an informative sentence in the Description field to give you an additional hint about the purpose of the runbook.
- Description If you have many runbooks in your Automation account, the names might become confusing after a while. It’s a good idea to enter an informative sentence in the Description field to give you an additional hint about the purpose of the runbook.
-Automation Account Create a new Automation account or select from your existing Automation accounts.
- Subscription Select the subscription for which you want to create the runbook.
- Region The region field autopopulates with the region that corresponds to the subscription selected.

5. Click the Create check mark to create the empty runbook.

When you create a runbook using Quick Create, you get an empty runbook with a workflow template. To accomplish the task, enter or paste Windows PowerShell commands between the curly brackets.


Create a runbook from the Gallery
To create a runbook from the Gallery, do the following:
1. Sign in to the Azure Management Portal at manage.windowsazure.com.

2. Click Automation, and then click New.

3. On the New page, App Services and Automation are already selected. Click Runbook, and then click From Gallery to display the Select A Runbook page.

4. On the Select A Runbook page, you can filter to select runbooks authored by Microsoft or the Community and by PowerShell Workflows or PowerShell Scripts. After the filter selections are made, select a category to see the predefined runbooks you can choose for that category.

5. Select the runbook that interests you, and then click the arrow in the lower right of the page. On the Review Runbook Definition page, you can read the information provided about the runbook and then decide if it meets your needs.

6. If the runbook isn’t what you want, click the left arrow to go back to select a different runbook. If you do like the runbook, click the right arrow to go to the Enter Runbook Details page. There, you can modify the default name of the runbook. You also select the appropriate Automation account (or create a new account) and the subscription. The region field autopopulates with the region that corresponds to the subscription selected. Click the check mark to create the runbook in your Automation account.

When it’s in a draft state, a runbook cannot be linked to a schedule asset. It also cannot be invoked by another runbook. Calling runbooks in a nested pattern is a powerful paradigm that you can use to combine existing functionality of runbooks to make up a solution. Any time you import or create a runbook, it is in in a draft state until you explicitly promote it to a published state. You can test the runbook while authoring in draft mode, and then promote it to the published state when it’s ready to be used in production. After it’s in a published state, the runbook is eligible to be invoked by a schedule asset and called by other runbooks.

The in edit state creates an additional draft version of a runbook that can only be run in test mode. The published version also still exists; thus, if you call this runbook from another runbook, even if it’s in the in edit state, the previous published version will be run. Also, if you have an already published version of a runbook and then publish a draft, any runbook that is currently in the execution state will continue to use the original version of the runbook under which the job was started. This applies even if the job is in a suspended state. The published version of the runbook will always be called outside of the test experience. The published runbook will run from the schedule, from any other runbooks that call it, or from the command line if you use Start-AzureAutomationRunbook.

In some cases, an issue that could cause a problem is that, after you run a new version of a published runbook (say, V2), any already executing previous versions of that runbook will continue to run with the old version (say, V1). All new instances of that runbook will use the newly published V2 version. Therefore, if a new job is started after the new draft runbook has been published, this new version will be run. It will not affect any of the older versions of the jobs that are running.

Be aware of this issue as you deploy runbook updates to make sure you are running the latest version. In some cases, that difference could be very important. Having multiple versions of the runbook concurrently running might or might not be what you want. With respect to multiple versions, there is no source control per se for versioning different versions of your runbooks. In the History tab of a runbook, however, you can get access to the source code for each of the previous runs of a job.

Source of Information : Azure Automation