This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.

Scenario

In Part 1  and Part 2  we saw how we could deploy a web server on a new VM in using a Desired State Configuration file using Azure Devops and even The Azure Portal. The next section will describe one of the most powerful Automation tools in our arsenal, the Azure Automation Account. To understand how it ties in with DSC we will first start with an overview of the features at our disposal.

Part 3: Azure Automation Account Overview Functionality

What will I need? 

- Azure Subscription (with Permissions to read resources)

- Azure Automation Account

- Visual Studio Code

- Azure DevOps Organization connected to Azure Automation (Use source control integration in Azure Automation | Microsoft Docs)

 Steps

1. Let’s start with the overview page of the Automation Account. Ever heard of Azure Update Management? Yes, the solution that patches your servers. Well, that uses an Automation Account in the background. You will also see features like Inventory and Change Tracking and you can read up on these in our official documentation (Azure Automation Change Tracking and Inventory overview | Microsoft Docs). For this blog series we are focusing on DSC and in this article, Automation in general.

2. What does the Automation account have to do with DSC? Well there are two answers to this question. If we go into the “Shared Resources” section and click on “Modules Gallery” guess what comes up. DSC Resources! Does this mean I don’t have to write all my own DSC script to utilize these? Yes! We have access to DSC scripts that have been written by the community and even Microsoft internal teams.

3. How do I use these “Modules”? First of all you will click on them and then click Import.

4. Upon successful import these modules will show up under “Shared Resources” and you can start using them in scripts and runbooks. What is a runbook? A runbook is basically a script that I write and deploy to my servers (In Azure, On-Premises and even other clouds). Runbooks can reference many modules which is why you want to do the module import in the first place.

5. What if I wanted to write my own runbook? Will runbooks update if I push them to my Repo in Azure DevOps so I can collaborate with my team? Let’s take a look at that by creating a simple PowerShell script that will ping the Google DNS Servers.

6. Now I will commit the file to my Azure DevOps Repo

7. One cool feature of Azure Automation is that it connects to my Azure Devops Source Control. This means my file will automatically sync into my runbooks section

8. If this does not happen “fast enough” for me I can also start a manual Sync as seen below.

9. Once the runbook has been created I can click on it

10. I can then click on Start to start the runbook

11. To view the output I can click on output of the Job

12. I have other options to execute the runbooks like linking it to a schedule for example every day at 9:00pm.

13. (ADVANCED) I also have the option to use a Webhook and combining it with PowerAutomate and PowerApps to create an Application on my Mobile device that starts the Runbook whenever I want.

Video

Conclusion

In this article we explored all the features an Azure Automation Account brings to the table. In the next and final part of the series we will explore how we can use Azure Automation Account to make our lives easier when using DSC.