Azure Automation is a cloud service in Microsoft Azure which let you schedule execution of PowerShell cmdlets and PowerShell workflows. Azure Automation uses the concept of runbooks to execute a set of repeatable, repetitive tasks via PowerShell. Consistency in execution, reduction of errors, and of course saving time, are all key objectives - which makes DBAs and system admins happy, eh?

Examples of How You Could Use Azure Automation

• Shut down a virtual machine in a development environment on a schedule to avoid charges when it's not being used
• Pause Azure SQL Data Warehouse on a schedule to avoid compute charges during the time it's not serving queries or processing data loads
• Check size of an Azure resource to determine if it's close to reaching its threshold for scaling up
• Scale Azure resources up or down on a predefined schedule
• Deployment of resources from Dev to Test environment (i.e., in conjunction with ARM deployments)
• Deployment of test scenarios, particularly if an environment needs to be deleted and recreated numerous times as part of the testing cycle
• Scheduling of routine processes such as backups, file copy operations, or custom scripts
• Auditing and logging of all resources in a resource group (optionally with Log Analytics in Operations Management Suite)
• Kick off a task in response to an Azure alert (requires a webhook-enabled runbook which can respond automatically to alerts)
• Execute a task on an on-premises server (requires the Hybrid Runbook Worker feature)
• Deployment of patches for Azure virtual machines

Obviously the above list isn't all-inclusive; there are so many ways in which automation techniques can make your life easier.

The "Lingo" in Azure Automation

• Automation Account: The container for your runbooks and assets; associated with a Run As account and certificate
• Runbook: Contains the PowerShell scripts which perform the operation(s)
• Jobs: History of when runbooks were executed
• Assets: Objects which are reusable across runbooks, including:
  • Schedules: Schedule to execute a runbook hourly, daily, weekly, or monthly
  • Modules: aka Integration Modules - PowerShell modules uploaded to AA or imported from the Gallery, each of which contains encapsulated functionality
  • Variables: Values for variables which can be called from runbooks
  • Credentials: Encrypted user name and password for authenticating to an external source
  • Certificates: Encrypted .cer or .pfx file for authenticating to an external source
  • Connections: Encrypted info re: connecting to an external source
• Hybrid Runbook Worker: Allows you to run AA runbooks on your on-premises (non-cloud) resources
• Webhook: Allows you to execute the runbook from an HTTP request; this allows for a runbook to be dependent upon something else that has occurred

Getting Started With Azure Automation

• The first thing to do is create an Azure Automation acccount.
• When you set up an Azure Automation account, you get 4 tutorial runbooks created automatically (though they aren't scheduled). After you've perused and learned from them, you probably want to delete them. 
• There is a Runbook Gallery which contains a ton of runbooks created by Microsoft or the developer community.
• Microsoft Press has a free e-book. This e-book was published mid-2015 so some things have definitely changed since it was published - for instance, only PowerShell workflows were supported at the time that e-book was written.

Tips, Suggestions, and Comments About Azure Automation

• When you create an Azure Automation account, give some thought to the scope of how you intend to use it. Depending on how you have chosen to set up resource groups within your subscription (a *very* important decision!), you might want to align your automation account in a similar way. Do keep in mind that runbooks can't be shared across different automation accounts, so that might lend itself to the automation account being more broad so as not to duplicate scripts. Conversely, owner/contributor/reader/operator roles are all at the automation account level which might justify being more granular.
• Schedules can be set to run as frequently as once an hour (at the time of this writing, fall 2016).
• Look into using Assets for sharing connections, credentials, and variable values across runbooks (within the scope of one automation account).
• Runbooks can be nested; that is, one runbook can call another runbook. This allows for reuse of scripts or other useful patterns. (The runbook being called needs to be in a published status for this to work.)
• There are 3 statuses: draft, edit, and published. If you have "undeployed" changes in draft or edit status, a published version of your runbook will keep running in its published state.
• If it's being edited, a runbook's status will be in edit mode. If you wish to make changes to a runbook that's in edit status (i.e., being edited by another contributor), you should wait until it's back safely in published status. Otherwise, two authors at one time will absolutely, positivelyget in each other's way.
• Design any runbooks, or checkpoint durations, to be less than 3 hours. Currently (fall 2016), any Azure Automation job running 3 hours will be temporarily unloaded. This means it will be restarted from the beginning or the most recent checkpoint (if applicable). (This limit used to be 30 minutes but was increased to 3 hours in 2015.)
• There are 4 types of runbooks:  PowerShell, PowerShell Workflow, Graphical PowerShell, and Graphical PowerShell Workflow. They can't currently be converted from one type to another. 
• Azure Automation can be integrated with GitHub for source control. Visual Studio Online (TFS) is coming soon.
• Every single Azure service isn't supported by Azure Automation, so be sure you verify for your scenario.
• Runbooks can be created directly in the Azure portal if you like, or they can be imported (.ps1 or .graphrunbook file types). An imported file needs to be <1MB.
• Be sure to read the chapter called Best Practices in Using Azure Automation as part of the e-book. It's got lots of good tips. In the first edition, it's chapter 6 which starts on page 83.

Desired State Configuration

The Desired State Configuration (DSC) is a specific type of Azure Automation. It utilizes PowerShell in a declarative way to enforce configuration settings or validate a specific state. DSC monitors computers in your environment, which are referred to as target "nodes." The nodes can be in Azure on on-premises, physical or virtual.

Examples of using Desired State Configuration include:

• Validation that machines comply with corporate security standards
• Auditing of server state, registry settings, environment variables, etc
• Validation of server roles and features enabled
• Management of files, folders, settings, software installations, etc

Finding More Information

Azure Documentation

You Might Also Like...

Setting Up a PC for Cortana Intelligence Suite Development

How to Create a Demo/Test Environment for Azure Data Catalog