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:
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:
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.
Consultant
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.