Azure Automation – How to get started

• Author
• Recent Posts

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

Latest posts by Paul Schnackenburg (see all)

• Azure Sentinel—A real-world example - Tue, Oct 12 2021
• Deploying Windows Hello for Business - Wed, Aug 4 2021
• Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021

Behind the scenes, it’s a scalable, highly available service that is built on the same foundation as Service Management Automation (SMA), which is available for your on-premises Azure Pack deployment. It runs PowerShell in the form of runbooks, which are basically workflows with some additions, and it provides a management infrastructure for you to store, schedule, edit, publish, and troubleshoot automation jobs.

Setting up an account

To get started, you need an Azure subscription, which you can set up as a trial if you don’t have one. You then need to sign up for the preview here; scroll down until you see Azure Automation and click Try it. Once the preview has been activated for your account, you should see the “gears with lightning bolt” icon in the list of available services in the management console on the left.

Click Create in the bottom middle of the screen to name your new automation account. Each subscription can have up to 30 different accounts. Presumably, you’ll be able to have these in different regions around the world once the service becomes generally available, but currently you can only select East US.

Azure Automation dashboard

Getting started with Automation

When Automation first came out, a number of steps were involved in getting started as you had to work with certificate-based authentication; this excellent video series covered those steps in detail. Fortunately, since late August 2014, you can now use Azure Active Directory instead, as explained in this blog post for authentication, which considerably lowers the first hurdle to get started.

I won’t repeat the steps required. Make sure you follow the blog post so that you have a user setup in your directory who is an administrator of your subscription and has been added as a global asset under Automation.

This brings me to one of the best things about Azure Automation. Many people new to automation tend to think in terms of scripts that run “to make things happen” and believe that each of these are standalone, with everything they need inside them. Unfortunately, that makes it very difficult to maintain over time because hardcoded variables, credentials, and time-based settings are now all stored in the script itself. If you need to change something, you have to find every script where that something is used and change it.

Setting up a schedule

Automation provides a better solution with global assets where you can define connections, credentials, schedules, and variables that you can then use in any of your runbooks. If one of these needs changing, you can simply do it once, and all runbooks using that setting will pick up the change.

Your first runbook

Go here and download the Hello World runbook to a local folder on your computer. Then, go to the dashboard in the console for your newly created automation account and click the Runbooks tab. Click Import at the bottom and browse to the ps1 file you downloaded. After that file is uploaded, click it in the console. That takes you to the dashboard for the runbook (each script has its own dashboard where you can see particulars for it). Click the Author tab.

Edit a runbook in your browser

Each runbook can be in one of two states: Draft or Published. In draft mode, you can edit it directly in the browser and test it. (Note that this will actually run the script, not just simulate it.) Once you’re happy with a script, click Publish. Click Start to run the script interactively. This particular runbook will ask for your input (in case you want it to print anything other than “Hello World”); you can imagine having questions for VM or website names, settings, etc. Go back to the dashboard for the runbook and click the date and time you ran it to see the output.

Automation job history tab output

Runbooks galore

As with anything PowerShell related, there’s no point in reinventing the wheel. The Script Center has a whole section with Azure runbooks provided by either Microsoft or the community (136 are currently available). There are runbooks for starting and stopping VMs on a schedule (great for saving compute costs), creating VMs, creating websites, backing up VMs, copying VMs between subscriptions, creating a snapshot of a running VM, creating VMs with an SQL Always On availability group, monitoring Azure websites, and creating an Azure Files share. There’s even a script to identify if your Site-to-Site VPN public IP address has changed and update your Azure network configuration file accordingly.

The ability to pick runbooks directly from the console was recently added. Simply click the New button at the bottom left of the console, click runbook, and select “from gallery.” There’s some overlap with the Script Center runbooks, with fewer scripts available in the gallery than in the Center.

The cool thing about Automation is that, when you first look at it, you think it’s all about managing the stuff you have in Azure: websites, VMs, cloud services, etc. But, as demonstrated in this presentation from TechEd NA 2014, it can also be used to reach out to systems outside of Azure, both in your own datacenter and elsewhere on the Internet to integrate and automate.

As you can see on the Assets tab, you can import other PowerShell modules apart from the Azure one that’s there by default. Given the restrictions (you can’t access the underlying infrastructure in Azure, of course), it should be possible to automate a wide range of systems provided they have a module.

Similar to Orchestrator and SMA in general, the main recommendation for working with runbooks is to keep them small, doing a single task and then stringing them together for more complex runbooks.

Conclusion

Once Automation becomes generally available, there will be a free tier, with up to 20 runbooks and 5 MB of storage (which is plenty, given the size of most scripts), and a standard tier, with 100 runbooks and 25 MB of storage.

As expected in a public cloud with rapid development, some overlap with other services exists. For instance, some of the deployment functionality is also available in Azure Resource groups (which we’ll cover in a later part in this series). PowerShell on premises connected to Azure can also achieve most of what Automation can do today but, of course, lacks in the high availability and global assets space.

The challenging thing about Azure is that it’s so new and changes so quickly that it’ll take some time for IT departments to figure out how best to integrate it into their processes. There’s no doubt, however, that Azure Automation is a required cornerstone to bringing true production-level, managed environments to this brave new, hybrid cloud world.