Code Library: Azure Automation

Showing posts with label Azure Automation. Show all posts

Publishing a runbook Before you promote a runbook to a published state, test it to ensure it’s ready to use. Realize that a test run of a runbook still runs all the code and does what it needs to do in reality. Put another way, the test run is real! There isn’t an Undo switch to hit after the runbook test completes. You can use test assets or parameters that contain test environment information and point to the test environments. When the runbook is ready to be published, you can switch them into a runtime environment.

Promote a runbook from draft status into a publish status after it’s tested and you’re sure it works correctly. If later you want to go back and modify it, you can toggle it back into Draft mode, edit it, and then publish it again from the Author pane in the Azure Management Portal. While you are editing a runbook, the published version will be the version called by schedules or cmdlets. This allows you to edit while the published version runs.

A runbook needs to be published to be started. You can’t start a runbook in Draft mode. Also, if you want to link it to a schedule or call it from another runbook, it must be published. All draft runbooks can run only in Test mode. For the sake of testing, a draft runbook does not need to be published to call other runbooks in Test mode. Once published, it can be called from other runbooks.
To publish a saved runbook, in the Azure Management Portal, select it from the list of runbooks and then click Publish. As shown in Figure 4-1, along with Publish, you can also manage the runbook by importing a module or adding a setting; insert an activity, runbook, or setting; save the runbook; discard the draft and only keep the published version; and test the runbook. A runbook that is still in Draft mode can only be run by clicking Test. If you have not saved the runbook before you run it in Test mode, the Azure Management Portal prompts you to save the runbook.

Source of Information : Azure Automation

Azure Automation assets Assets are to Azure Automation as running water is to a modern home. Sure, you can exist without piped running water by going to the stream or lake near your home (if you have one), manually filling buckets of water, and lugging them home over and over again. But the spillage and time lost in this process makes it not nearly as effective as turning on the faucet to access clear and safe water out of the tap. After you have water, you use it for household tasks such as washing dishes after dinner, running the clothes washer after football practice, bathing the children in the tub, and making lemonade drink mix for snack time.

Assets serve a very similar purpose in Azure Automation as the modern day public water system. Assets are reusable shared global resources that support global and common connections, credentials, variables, and schedules. These can be shared across runbooks in the same Azure Automation account, or between multiple jobs from the same runbook. They can also manage a value from the Azure Management Portal or the Windows PowerShell command line that can be shared across runbooks. Assets promote centralized management of constant values. In the Automation area of the Azure Management Portal, assets are also referred to as settings. You can create variables that can be input by the administrator of the scripts at runtime or set via code. Assets allow a simple standard mechanism for sharing of global entities between jobs, such as variables, schedules, credentials, and connections. By using assets to encapsulate connections and credentials, the login security information is much safer than being hard-coded in workflow code. Schedule assets provide a global scheduling capability.

A good example of using assets is the Connection asset. It allows you to group the connection data necessary to connect an external system into a single object so that it can be easily accessed by runbooks. It provides a template describing how a connection for a certain system should look. This allows users to use this template when defining the connection to this system. Any changes to the connection data can be made in a single place without having to replicate the change in multiple locations (variable assets, runbooks, and so on).

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.

Source of Information : Azure Automation

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.

There is now a new and recommended option that provides a more integrated and simpler authentication mechanism for Azure Automation runbooks. Using Azure AD, you can use credential-based authentication for your Azure Automation runbooks. Azure Automation allows a robust and rich, integrated, identity-based authentication mechanism, supporting key industry-wide identity access mechanisms such as single sign-on (SSO) and Multifactor Authentication (MFA). Azure Automation easily integrates and synchronizes with your on-premises enterprise Active Directory installation. Azure Automation also uses role-based access control (RBAC) mechanisms available in the Azure Preview Portal. Additionally, you can leverage RBAC in your Azure Automation runbook authentication strategy. This permits you to simplify and improve control regarding who in your organization is allowed to perform specific operations or access specific resources.

Azure Automation is becoming increasingly integrated into the various Azure services as an all-inclusive identity solution. With Azure Automation, your organizational groups and user accounts are used to simplify secure access to different parts of Azure. When you log into your Azure subscription or use the Azure REST Management application programming interface (API), you authenticate using Azure Automation. Azure Automation, along with services such as Microsoft Office 365, Microsoft Azure SQL Database, Microsoft Azure Mobile Services, and Microsoft Azure Cloud Services, trust Azure Automation with identity access management.

To enable Azure Automation for a new user, do the following:

1. Create the user in Azure AD. For more information about creating a user in Azure AD.

2. 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.

3. Log in to the Azure Management Portal as the Azure Automation user you created in step 1 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.

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.

Source of Information : Azure Automation

Management certificates 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 a 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 provides 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.

Source of Information : Azure Automation

Microsoft Azure Automation assets 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.

Source of Information : Azure Automation

Resume or suspend a runbook Resuming or suspending a runbook is closely related to checkpoints. You can manually suspend a workflow, which is typically done if some manual processing needs to be accomplished prior to running another set of activities. You can do this using the Azure Management Portal. A runbook can also be suspended by calling the activity Suspend-AzureAutomationJob, or it can call the Suspend-Workflow activity. This activity will set a checkpoint to cause the workflow to immediately suspend. At the next checkpoint, the job will be subsequently suspended. A possible scenario for this might be where you want to insert a Suspend-Workflow activity if there is a manual step that needs to be taken before a runbook can complete.

Suspension can also occur due to certain conditions. If a runbook unexpectedly crashes, the worker role on which it is running it can be suspended and will resume again from its last checkpoint. As mentioned previously, if an Azure Automation job runs for more than 30 minutes, it will be automatically suspended until given a chance to run again, resuming at the last checkpoint. A job can also unexpectedly raise an exception that causes it to be placed into a suspended state.

Once suspended, jobs can be resumed by calling the Resume-AzureAutomation activity from a Windows PowerShell script. In the Azure Management Portal, you can also manually resume a job. If a worker thread running the runbook crashes, it will find and restart any jobs that need to be completed soon. The resumption on a worker thread will most likely happen on a different worker thread than it was running previously, so don’t make any assumptions about storing any local state on that worker thread.

Source of Information : Azure Automation

Runbook checkpoints The scripts used in Azure Automation are built on the Windows PowerShell Workflow model, which provides a powerful feature for checkpoints within the runbooks. By adding a checkpoint to a runbook, you increase its reliability to function despite transient errors, unexpected exceptions, service delays and outages, network downtime, and other issues that are commonly found in a distributed system such as Microsoft Azure for long-running and widely distributed resources. Using checkpoints allows you to confidently automate processes that span multiple networks and systems.

A checkpoint provides a persistence mechanism you can implement at various strategic points in the execution of the Windows PowerShell Workflow. If a problem occurs and the processing of the workflow is interrupted, it can be resumed again near the point of interruption. A checkpoint also ensures that an action will not occur more than once and have a negative duplicate effect. This is the concept of a workflow being idempotent; you can run the workflow more than once, but the result will be the same as if you only ran it once.

Checkpoints are used to persist the state of a running runbook to the Azure Automation database. Think of a checkpoint as a point-in-time picture that includes any presently generated output, any other implicit, serialized state information, and any existing values of any variables when the checkpoint view was taken. A checkpoint exists in the database until another checkpoint is taken, in which case the first checkpoint is overwritten, or until the runbook completes.

Overhead is associated with the placement of a checkpoint within a runbook. Each time a checkpoint is invoked, a serialization of data persists to storage. If you have a large Windows PowerShell workflow and add a number of checkpoints to it, workflow performance can suffer noticeably. So, although you could place a checkpoint before and after each line in a script file, be smart about your use of checkpoints so performance isn’t negatively affected.

Although there are no firm rules on where to put checkpoints, you should plan and strategize their placement within a workflow. If the time it takes to rerun a section of an interrupted workflow is greater than the time it takes to persist the checkpoint, that’s probably not a wise use of a checkpoint. Rather, it makes more sense to place a checkpoint after a good chunk of work is done by the workflow itself. This could be defined as making a call to a resource that might or might not be available or ready, calling a routine that takes a very long time to complete its work, or an operation that coordinates multiple distributed resources that are geographically distributed or are highly contended for by a number of processes.

Where you place checkpoints is specific to the workflow and its duties and performance constraints. You don’t want to persist a checkpoint when it’s not really necessary. Look at activities that might be prone to failure. You also want to avoid having to take the time and resources to do expensive work. Therefore, set checkpoints in the runbook at critical points, and ensure that any runbook restarts do not redo any work that has already completed. Also, you want to encompass any idempotent activities to make sure they don’t run more than once when the workflow resumes.

For example, your runbook might create an instance of a Microsoft Azure HDInsight Hadoop cluster with perhaps a hundred or so VMs to handle a big data issue with your script. You could set a checkpoint both before and after the commands to create the cluster. If the runbook fails during cluster creation, when the runbook is restarted, it will repeat the cluster creation work. If the creation succeeds but the runbook later fails, the HDInsight cluster will not be created again when the runbook is resumed.

Azure Automation limits the amount of time a runbook can execute to 30 minutes. Azure will unload a runbook that takes longer than that, assuming that something has gone wrong or the runbook is monopolizing the system. The runbook will eventually be reloaded, and you will want to resume it from where it left off. To ensure that the runbook will eventually complete, you should add checkpoints at intervals under the 30-minute limit.

By using the Checkpoint-Workflow activity within a Windows PowerShell workflow, you tell the system to immediately persist a checkpoint. If an error occurs and the workflow is suspended, the workflow will resume from the point of the latest checkpoint when the job is resumed. Checkpoint-Workflow is a simple call that does not take any parameters and can be placed before or after any workflow command. However, you can’t use the Checkpoint-Workflow activity within an inline block of code.

Source of Information : Azure Automation

Author a runbook To author a runbook, you can develop new Windows PowerShell runbooks on your own and enter your own Windows PowerShell commands. You can call common global runbooks that you have in your asset library. You can then access those runbooks as linked libraries. For instance, you could have a runbook that manages all your credentials and connections that you call from each runbook at the start. A best practice when authoring runbooks is to write granular and single tasks so you can then reuse and insert them later (after they are published) in other runbooks.

All the authoring can be done in the browser in the Azure Management Portal. Log in to the Azure Management Portal, click Automation, and on the Automation page, click the Azure Automation account of interest. On the Automation account’s page, click Runbooks, and then click the name of the runbook. On the runbook’s page, click Author. At the bottom of the screen, click Edit to allow you to enter or modify its content right there in the Azure Management Portal. This puts the runbook automatically into draft mode for the version you are editing. Note that the previous published version still exists as a separate entity while the editing is taking place.

On the Author tab within Edit mode, you can take the following actions.

- Manage From here, you can select the following options:
- Import Module After a module is imported, you can call activities (cmdlets) from that module in your runbook.
- Add Setting This allows you to create any type of asset, or add a type of asset or setting to the runbook code. You insert a setting (or asset) with set or get operations on the assets. These assets have global scope to the entire account for all runbooks in that Automation account.

- Insert From here, you can select the following options:
- Activity In this context, an activity is a cmdlet. An integration module is a package that contains a Windows PowerShell module; you can import it into Azure Automation. You choose the integration module, and then select the activity, for example, Add-AzureAccount. After selecting the activity, click the arrow to go to the activity’s Parameters page where you can make selections from the Parameter Set drop-down list box for required and optional parameters. Select the check mark to close the Insert Activity dialog box and return to the runbook where the template for the activity has been inserted.
- Runbook Select this option to insert an entire runbook from the list of published runbooks in your Azure account. Call the newly inserted runbook just like you would an Azure cmdlet, passing in parameters and getting values back.
- Setting Choose a setting action in which you can get or set a variable, get a connection, get a certificate, and get a Windows PowerShell credential.

- You can create an asset that is a global entity. If the asset is created by one runbook, it can be called by another asset in the same Azure Automation account.
- Save After you have finished entering or inserting the script into your runbook, click Save. If you decide you don’t want to keep the modifications, you can leave the page via the browser controls, or by clicking on another runbook or another tab.
- Discard Draft This option only applies if the Authoring column of the runbook shows a status of In Edit. As mentioned previously, you can have both a published and a draft version of a runbook. If you want to get rid of the draft version of the runbook, click Discard Draft.
- Test Select this option to run the draft workbook, which will modify any Azure resources as if the runbook was running in published mode.
- Publish Select this option after you’re satisfied that your runbook works as it should. Publish promotes the runbook to a published status. When placed into published status, a runbook is in read-only mode and cannot be edited unless it’s transitioned back to draft status.

A common point of confusion about authoring of runbooks concerns simultaneous editing by more than one user from different instances of the portal, for example, a co-administrator scenario. In the Azure Management Portal, you can have more than one administrator, so at times two or more administrators could author a runbook at the same time. However, be aware that Azure does not lock a runbook for editing by a single user. In the Azure Management Portal, a runbook that is being edited is shown as In Edit status. No information is provided about how many people might be editing the runbook.

As a general guideline, if a runbook is in in edit status, no one but the initial person editing the runbook should edit it until it leaves this state. It’s best to wait until the runbook is moved out of in edit status and the draft status has moved into a published state before you try to make changes to it. You can also contact your co-administrator who is editing the runbook and get a copy of the runbook. Then, you can add your changes to their latest edited version.

Source of Information : Azure Automation

Create a runbook 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

Import a runbook Importing a runbook is a very powerful way to quickly add functionality to your script library. When you import a runbook you typically are working with runbook code that has already been written, tested, and made ready to go. You might need to assign your specific values to the variables when you run it, or modify the code slightly after import to meet your specific needs. You can import from a file share on your internal company site where you store your company Windows PowerShell scripts. You can also import runbooks from community sites or the Microsoft Script Center. Many common scripts are available from the Script Center that you can import and use as is or modify for your deployment.

There are many ways to import runbook functionality. Note that when you import a plain Windows PowerShell script, it will be converted to a workflow.

- Internal site You can import from a file share on the internal company site where you store your company PowerShell scripts.

- Script Center You can import from community sites or the Microsoft Script Center. To import a runbook, you can go to the TechNet Script Center and filter by technologies you might want to consider. Many common scripts are available that you can import directly or copy and modify a bit for your deployment.

- Runbook Gallery—Portal You can import a runbook from the Azure Management Portal Runbook Gallery that contains similar functionality to what you can download from the Script Center for Azure. The best recommendation is to use the Azure Portal Runbook Gallery first, and then go to the online Runbook Gallery if you can’t find what you need

- Runbook Gallery—Online You can also download and import from the online Runbook Gallery, which continues to expand with many scenarios and sample utility runbooks.

Import a runbook from the Script Center
An imported runbook comes in with a draft status, and you have to explicitly decide when to publish it. After you publish it, other runbooks within your subscription can invoke it.

To import a runbook from the Microsoft Script Center, do the following:

1. Go to the Repository of the Script Center.

2. In Categories, select Windows Azure. (As of this writing, the label isn’t updated to Microsoft Azure.)

3. Under Operating System, make the selection appropriate to your environment.

4. For Scripting Language, select the PowerShell check box.

5. For Contributors, select the check box for the contribution source you want to use. Generally, scripts originate from either Microsoft or the community.

6. From the results, select a script of interest to you and then download and save it as a file to a location of your choice.

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

8. Click Automation, and then click the automation account for which you want to import the runbook.

9. On that automation account’s page, click Runbooks and then click Import.

10. On the Import Runbook page, browse to select the runbook file (for example, the file you downloaded in step 6), and then click the check mark to import the runbook. You can import any Windows PowerShell script file with a .ps1 extension. This could be a file you have written previously or a file you download from the Microsoft Script Center. Clicking Import allows you to browse for any PS1 file that is 1 MB size maximum.

11. Find the imported runbook on the Runbooks page of the Azure Automation account. The value in the Authoring column is New. Click the name of the runbook to go to the Learn About This Runbook page.

Import or export a runbook via the Azure Management Portal
To import a runbook, go to the Azure Automation icon on the left side of the portal, which shows any Azure Automation accounts you have for that subscription. Clicking one of those subscriptions will take you to the main account screen. Simply click Runbooks to display all the runbooks contained in that Azure Automation account. At the bottom of the screen are two related buttons, Import and Export.

You can import any Windows PowerShell script file with a .ps1 extension. This could be a script file you have written previously or one you download from the Script Center. Click Import to browse for any PS1 file that is 1 MB size maximum. When you import a PS1 script file, it will be converted to a workflow during the import operation.

Correspondingly, you can export a runbook by clicking Export. You will be prompted to make sure you want to export it, and you can to save it to any location you want.

Source of Information : Azure Automation

What is a runbook? Let’s start by giving a definition of an Azure Automation runbook. If you’re familiar with the enterprise software development life cycle (SDLC), the definition of a runbook encompasses a set of processes and procedures that you execute repetitively to support various enterprise tasks. These tasks can include deployment and lifecycle management of resources, deployment, patching, upgrades, backups, error log management, database volume management, user management, and security management.

A runbook allows you to build processes that can be repeated using a Windows PowerShell Workflow script. This technology and methodology (and the script) is now being moved into Azure Automation runbooks, which map to automation of operational tasks. A runbook is one of the core components for Azure Automation that can be used to automate and orchestrate business processes. It is a container for a Windows PowerShell workflow script.

The Windows PowerShell Workflow code used in runbooks typically leverages Azure Automation Assets, which are common and reusable operations and items that can be shared globally across all runbooks. These items include schedules for which the runbooks can run, variables, connections to databases and resources, and authentication entities like certificates and credentials.

Runbooks support in the Azure Management Portal
The Azure Management Portal is your one-stop shop for creating, importing, and managing runbooks. When creating a runbook, you can start it as a draft or you might have a library of runbooks inside your organization that you import from a common location. You can also import runbooks from the Microsoft Script Center. Creating a runbook refers to your creation of an empty runbook, for example, in the Azure Management Portal. Authoring a runbook refers to the editing and building of the code inside the runbook.

In addition to establishing the runbook via the Azure Management Portal, you can also do all of your runbook management there (including debugging). For example, you can insert Windows PowerShell Workflow scripts into the runbook, and edit and test the scripts. Then, you can debug the script, make sure it works, and see the results, all in the same portal. After you test the script, you can publish the runbooks, invoke them, and manage or view the execution of the job in an integrated manner in the Azure Management Portal.

Source of Information : Azure Automation

Creating an Azure Automation account Now that you have an Azure subscription with Azure Automation enabled, the first item of business is creating an Azure Automation account. An Azure Automation account is different from your Microsoft account or Azure subscription. Your Azure subscription contains all your Azure resources, such as Cloud Services, Service Bus, HDInsight, Mobile Services, and so on. An Azure Automation account holds all Azure Automation resources for that account. An Azure Automation resource (such as a runbook or assets) within one account cannot be implicitly shared across other Azure Automation accounts. However, you can view one or more Azure Automation accounts as a logical unit of isolation within an Azure subscription.

You can use an Automation account to organize the automation runbooks specific to a person or a group. Think of an Automation account as a top-level file folder in which you store your runbooks in specific regions. You can have multiple automation accounts per subscription with a maximum of 30 Azure Automation accounts per subscription in different regions, if needed.

For example, an IT operations person might create an Azure Automation account for different groups, such as Marketing, Finance, HR, Development/Test, and Research. These five individual accounts can then hold automation runbooks that are specific to each group’s provisioning and lifetime management of resources. Programmatically, the resources in one Azure Automation account don’t have scope in another Azure Automation account.

To create an Azure Automation account, do the following:
1. Sign in to the Azure Management Portal at manage.windowsazure.com.

2. Click Automation in the left pane to go to the Automation page, and then click Create An Automation Account. The Add A New Automation Account dialog box appears.

3. In the Account Name text box, enter the name you want to use for the account. In the Region drop-down list box, select the region you want to use for the account. Choose the Azure Subscription that you want the Automation account to apply to, and then click the check mark.

4. The Azure Automation account is displayed on the Automation page

The Azure Automation Account page provides you with the following information:
- Dashboard tab Shows diagnostic, job, and usage information for the Automation jobs that have run. It indicates the different status of the jobs (queued, failed, stopped, suspended, completed, and running) with a granularity of one hour to 30 days. You can see the number of runbooks you have, assets (variables, connections, credentials, schedules), and more summary information.

- Runbooks tab Provides a list of runbooks and their current view. You can filter the job status by specific dates and times. Other runbooks can be imported here, or you can export one of the runbooks from this Azure Automation account to be used in another account.

- Assets tab Allows management of assets global to the mynewautomationacccount runbook. You can modify and create variables, connections, credentials, and schedules. You can also import additional modules that contain Windows PowerShell workflows to use in your runbooks.

- Scale tab Allows you to choose the Free or Standard Automation plan. The plan you choose applies to all Automation accounts in the subscription. The Free plan allows 500 minutes of job runtime per month and is not billed. If you need unlimited minutes of job use, choose the billed Standard plan.

Source of Information : Azure Automation

Enabling Azure Automation To use the Azure Automation preview feature, you must enable the Automation feature in the Azure portal. To do that, you need an Azure subscription. The easiest way to get one is to sign up for a free trial subscription at free one-month trial. With that subscription you get up to $200 in credits for Azure services that you can use during the trial period. All you need to get a trial subscription is a Microsoft account, a phone number, and a credit card. After that trial subscription, if you decide you want to keep using Azure, you can upgrade and start paying for the services.
To enable Azure Automation, do the following:

1. Go to the Azure Management Portal at manage.windowsazure.com, and enter your credentials to log in to your subscription.

2. Click Subscriptions to see a list of your subscriptions.

3. Click Manage Your Account, and then click Preview Features to see all the available Azure features. Click Try It Now for Azure Automation.

4. Select the Azure subscription for which you want to enable Azure Automation. After you complete the registration process, you will see the Azure Automation icon displayed in the left side of the portal.

5. Click Learn More in the Azure Automation section to find information to help you get started. You can find the latest documentation on Azure Automation, run a simple tutorial, jump to the Runbook Authoring Guide, and access the Azure forums to discuss and get answers from others about Azure Automation.

The Learn More page includes a link to the Automation Library. From there, you can access step-by-step directions about how to perform various Azure Automation tasks. For instance, you can learn how to create, schedule, and execute a runbook. The Learn More page provides useful sample runbooks from Microsoft that show how to simplify common tasks and demonstrate useful concepts. In addition, you will find information about how to back up Azure Automation objects before deleting an Azure Automation).

Source of Information : Azure Automation

Why Azure Automation? Azure Automation is targeted at the repetitive enterprise-level tasks, from simple to complex, that you perform regularly. Any error-prone operation that takes a long time to complete and is going to be done two or more times in its lifetime is a good candidate for Azure Automation. Its overall focus is to provide management of the previously mentioned Azure services.

Let’s look at some reasons Azure Automation might interest you from a business and technical standpoint.

Windows PowerShell workflow
You can leverage your current expertise and investment in Windows PowerShell. Azure Automation is based on Windows PowerShell, but it’s implemented via Windows PowerShell workflows. A workflow is a group of individual steps that performs a defined task. The workflow follows the model of orchestration set forth by System Center Orchestrator. It gives a flexible orchestration process for workflows and improves reliability across tools, systems, and departments in your organization with a scripting element.

You can integrate Azure Automation into existing systems and existing Windows PowerShell workflow modules to enable integration into other systems via automated repeatability. Azure Automation’s engine is the same one used by Service Management Automation (SMA) and is built on the PowerShell Workflow engine. You can take Windows PowerShell workflows you have today and, with a few modifications to adjust to the Windows PowerShell workflow model, run them in the Azure Automation portal. IT operations staff don’t need to completely learn a new scripting language.

The Windows PowerShell workflow model increases the reliability of the workflows with their checkpoint model. If for some reason a workflow is interrupted or fails due to a transient error, when it resumes, it does not start at the very beginning of the workflow. Rather, the workflow starts again at the last successful checkpoint in the workflow. This model also provides other improvements in connection pooling and throttling, workflow throttling, and parallel execution of tasks.

End-to-end automation service
With Azure Automation, you can automate end-to-end processes. For instance, if you have a set of Dev/Test VMs, virtual networks, or storage that is no longer needed when testing is done, or you have cloud services that are sitting idle for long periods of time, you can attach metrics and notifications to these processes. Then, you can notify appropriate personnel or release resources when the resources are no longer needed. You can also set up a schedule to automate shutting down resources during certain hours. For a production environment, you might want to manage updates or backups in a way that reduces downtime. Provisioning and updates are easy to manage via automation when you deploy Azure Cloud Services or Azure Virtual Machines and configure the rest of the supporting resources, or enable monitoring for the newly deployed services.

For Azure IT operations personnel, it’s a lot of work to spin up an environment and manage it manually from end to end. If deployment is going to be done two or more times, it makes sense to script deployment using Azure Automation. By automating as much work as possible, IT operations staff are free to do other work while the workflows are working in the background in a consistent and repeatable manner.

Off-premises redundancy backed storage
It’s often useful to have workflows available to an administrator anywhere in the world. Azure Automation gets workflows outside of on-premises computers and into a safe and highly available central repository where they’re available as long as you have an Internet connection. Because they’re stored in Azure locally redundant storage, three copies of the workflows within the same datacenter are backed up automatically. Azure Automation gives you an end-to-end solution so you can manage everything (deployment, maintenance, monitoring, and deprovisioning) about your workflows in a centrally and globally accessible location.

Runbook authoring and importing
Think of a runbook as a physical entity to house Windows PowerShell scripts to run within Azure. Azure Automation provides an environment via a built-in browser control to allow you to author and modify runbooks right in the Azure Management Portal (manage.windowsazure.com). You can create a runbook, import a runbook and run it as is, or you can import a runbook and modify it to fit your needs.

Scenarios
Scenarios in which you could use Azure Automation in your cloud environment include the following:

- Disaster recovery Deploy quickly new instances of Azure resources within an alternative Azure datacenter after a disaster occurs. Resources might include Azure VMs, virtual networks, or cloud services, along with database servers. This approach would be part of a less expensive ―cold‖ disaster recovery strategy where you don’t have a very high recovery time objective (RTO) and don’t need to keep an active version of your deployment up and running.

- High availability Manage service-level agreements (SLAs) related to high availability to ensure that you have the proper level of availability and personnel are notified so that they can take the appropriate steps when resources fail within a datacenter.

- Provisioning Perform initial and subsequent provisioning of a complete deployment, for example, a virtual network, where you assign VMs to it, create cloud services, and join the services to the same virtual network. Anything that you can provision with the Azure Management Portal can be done via Azure Automation.

- Monitoring Establish ways to monitor various attributes of your deployment and take appropriate actions when monitored values reach certain threshold limits.

- Deploying patches Patch remediation is especially important in the IaaS world because you’re responsible for managing the platform and deciding when and how to update the VMs. Azure Automation allows you to develop a runbook to manage the updates at scheduled times to manage patch remediation.

- Managing VMs Azure Automation can help manage the life cycle of your VMs. For instance, you might want to provision VMs, or shut down VMs at a specific time each day. You might want an additional way to scale down unused VMs and not rely on the criteria used by autoscaling criteria (CPU or queue length). After a VM is shut down, you might want to delete its accompanying virtual hard drive (VHD) files that back them up, or store them off to Azure Blob storage for later use if needed.

- Running backups Azure Automation is great for running regular backups of nondatabase systems, such as backing up Blob storage at certain intervals. Using the credential and connection assets of Azure Automation, you can do backups to external systems or servers.

Azure Automation pricing
Azure Automation provides both a Free and a Standard offering. As of this writing, Azure Automation accounts are located in the Eastern U.S., Southeast Asia, and West Europe regions.

The amount of time your jobs run (CPU time) in the system differs between the offerings. For the Free offering, you have up to 500 minutes of CPU time. For Standard, you have up to 10,000 minutes of CPU time available at $20 per month.

This is a great price for all the features that help you better manage your Azure Automation demands by storing, authoring, editing, running, testing, and deploying your automation workflows in the Azure Management Portal conveniently in one place.

Source of Information : Azure Automation

Why automation? Although it’s not a panacea for all configuration and testing scenarios, automation can truly be an incredible timesaver and increase the consistency of complex dependent deployment and testing scenarios. An enterprise best practice is to look at processes that are frequently repeated and then automate them. Automation minimizes the chance of errors tremendously because the same script is always running every time.

Repeatable deployment
Automation provides the support for repeatable and reproducible results every time a deployment occurs. Deployment can be done rapidly and in a consistent manner each time it’s executed, yielding the same results and configurations in less time. The key term here is ―same results.‖ Deployment can be one of the most error-prone operations, and it’s typically done many times over the lifetime of an application. For example, deployment occurs before a product is released but also to re-create a test environment post-release during regression testing. An application in a test environment is typically deployed repeatedly. Automating the process makes perfect sense to ensure it happens consistently and quickly each time a deployment occurs.

Consistent testing configurations
Variations in testing are a common requirement and can be a significant nuisance at times. For instance, a test configuration might require a scenario with multiple replicated database servers. To set these up manually over a number of runs is a very time-consuming process. As testing progresses and becomes more complex, being able to tweak a base configuration script according to the stage in testing is a significant timesaver. Automating test cases via scripting allows quick configuration and setup of an environment for a test team. Often, there is more than one test team within an organization working in similar environments. Via automation, multiple test teams in an organization can share and modify workflows to fit the requirements of their applications. For example, for testing within an organization, sharing a base automation script across multiple units improves the time taken to plan, design, and deploy multiple test scenarios. In addition, shared automation scripts allow you to more accurately compare results across different applications with teams that might be using the original, or slightly modified, shared testing automation script. This is because when running the same scripts the output is of the same type and can be equally compared with a relative accuracy across different organizational units.

Integrating automation into testing minimizes the time for setup and execution of different and complex test scenarios. For example, consider testing a complex multi-server configuration with SQL Server or Microsoft SharePoint using a replicated Active Directory. As a key part of the testing configuration, automation allows simple setup and teardown of that environment many times in a test cycle. In a test scenario, automation allows you to focus on the processing flow and the value of the data instead of the configuration setup and management.

Source of Information : Azure Automation

Azure Automation From an Infrastructure as a Service (IaaS) standpoint, Microsoft Azure Automation is one of the most exciting technologies Microsoft has released. After working with customers in the IaaS space over the past few years, I’ve seen the need for this type of centralized and high-performance automation functionality.

Azure Automation is a managed service to script and automate application life cycle areas such as deployment, provisioning, and life cycle management. As of this writing, the specific Azure technologies areas supported by Azure Automation include the following:

- Microsoft Azure SQL Database, which is a scaled-down version of full Microsoft SQL Server and provided as a relational database service for platform as a service (PaaS) Azure applications. This service abstracts out the file-system management of a SQL Server service-based solution.

- Microsoft Azure Storage, which encompasses tables, blobs, and files. Table storage service is a nonrelational NOSQL environment to store structured nonrelational data that is optimized for very quick access.

- Microsoft Azure Websites, a simple way to create and deploy websites in Azure by managing the infrastructure, patching, and scalability for you.

- Microsoft Azure Virtual Machines, which allows you to create an IaaS environment that can be attached to an Azure Virtual Network. You manage the non-operating-system installations and all updates from the default platform that is provided for you. Autoscaling and high availability are possible as needed when load increases.

- Microsoft Azure Cloud Services, which is virtual machines (VMs) behind the scenes, but Microsoft manages all the patching to the data and application level on your behalf. Autoscaling and high availability are possible as well.

Source of Information : Azure Automation