You’ve probably heard the quote from the infamous Bill Gates: “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” While I would not describe myself or any other IT admin as “lazy,” I do appreciate setting up automated systems and workflows so that I (or other admins) have to do as little as possible to accomplish our day-to-day tasks. Most admins have worked in Ye Olde Task Scheduler; others may have had shiny tools like System Center Orchestrator or other, more DevOps-oriented, tools. For those in the Azure space, another option is to simplify and streamline your current automated processes by using Azure Automation.
To start working in Azure Automation, you will need to create an Automation Account resource in your Azure tenant. As part of this creation process, you will have the option of creating a Run As Account. This account is a service principal linked to the Automation Account resource and is automatically granted Contributor rights to the subscription it exists in. This will grant your Automation Account the access it needs to manage resources in the subscription. If you have other subscriptions you wish to manage through this Automation Account, you can grant access for the account to those subscriptions as well.
Out of the box, the Automation Account has several built-in solutions that you can leverage for Azure and non-Azure machines (though some cost may be incurred for non-Azure machines). These solutions require a Log Analytics workspace, so you should set one up and link it to your Automation Account (this can also be done through the Azure portal).
Below are the solutions available through Azure Automation:
- Change Tracking – Tracks changes in software, files, and services on enabled VMs
- Inventory – View installed software/updates for enabled VMs
- Update Management – Deploy updates, manage update deployments, and view update compliance status for enabled VMs
But the real fun part is under Runbooks. These are PowerShell or Python 2 scripts that run in your Azure tenant. You can write them yourself (and customize them for your environment), or you can browse the Runbooks Gallery and import a pre-written runbook into your Automation Account. These runbooks can then be run manually or can be scheduled to run at specific times.
For example, say I wanted to get a basic report of all the RBAC assignments that are currently set in my subscription. I can create a runbook using PowerShell script to go through the following process:
- Connect to my Azure tenant.
- Set subscription context to my subscription.
- Run the below command to get all RBAC assignments and export them to CSV file:
$rbac = Get-AzRoleAssignment | select Scope,DisplayName,SignInName,RoleDefinitionName,ObjectType | Export-CSV -Path “.\RG_Permissions.csv” -NoTypeInformation -Append - Using SendGrid (a third-party SMTP service that has integrations in Azure; free tier allows up to 25,000 emails/month), send an email to me (and other admins) with the CSV file attached.
I can then schedule this runbook to run periodically so I can review what access is assigned to which users/groups.
Note that to use certain PowerShell cmdlets, you will need to have the proper PowerShell module installed. The Automation Account comes with some Azure modules but other modules can be found in the Modules Gallery. From there, you can search and import modules as needed for your scripts.
Another nice feature of Azure Automation is the Credentials section. Sometimes we need to run a script that requires either a specific login, an API key, or some other credential information. For obvious reasons, we do NOT want to put highly sensitive password information directly into our scripts. Typically, we would run Get-Credential to submit this information interactively. However, that option is not available with Azure Runbooks. This is where the Credentials feature comes in. Here we can create a credential object with the password value encrypted that we can then import into our runbooks without displaying the password. Once a credential object is created in the Automation Account, you will not be able to view the saved password in plaintext.
You may have noticed that the initial setup for the Automation Account/Run As Account granted access to your Azure subscription and resources/resource groups inside it. That’s great if you’re just managing Azure resources. But you will likely need to manage machines outside of Azure, or run scripts that need to be run within a server’s OS. The solution to that is the Hybrid Runbook Worker feature. This is a small service you can install on a machine that links back to your Automation Account. When a runbook is started (either manully or by schedule), you have the option to run it in Azure or on a Hybrid Worker. If you select Hybrid Worker, the runbook script is passed to the server and is run from there rather than from the Azure backend. Note that you will need to install any required PowerShell modules on the Hybrid Worker machine since it is still a separate entity from the Automation Account.
Leveraging Azure Automation in your Azure tenant allows you to centralize the scripts that run in your environment and removes the need to manage any potentially problematic infrastructure. It also includes tools that can simplify your life as an IT admin at a potentially low cost. I highly recommend looking into it and getting more proficient in PowerShell scripting to start automating your administrative processes.
This concludes the first installment of our 2-part blog series. Thanks for reading! The next installment will dive deeper into the Hybrid Worker feature and will explain how to use it in your local environment. But until then dear reader, we at Anexinet would love to have a conversation with you about your Azure journey. Whether it be Automation, Azure Site Recovery, Optimizing Your Spend, or any other aspect of Azure, please feel free to contact us at any time. We would love to discuss.
Share on
