Azure Update Management - Part 5 - Automation accounts

Hello there, the goal of this serie is to describe a real world implementation of Azure Update Management. This service was designed to update any machine in your infrastructure, whether they are hosted on Azure or elsewhere, provided your OSs are technically supported.

In order for every reader to understand and find answers to their need, to I’ll try to give a comprehensive feedback from my experience, as well as sharing tips about design and architecture, automation, effectivement, troubleshooting issues, and so on!

Have a nice reading.

Plan

• Part 0 - Introduction
• Part 1 - Architecture
• Part 2 - Azure Policy
• Part 3 - Azure ARC
• Part 4 - Log Analytics agents
• Part 5 - Automation accounts (you’re here)
• Part 6 - Monitoring
• Part 7 - Security patches on Azure ARC
• Part 8 - Security patches on CentOS machines

Introduction

In the previous post we saw how the basic and simple properties of a Log Analytics workspace. We also saw how to deploy Log Analytics agents with various methods. In this method, you will find all you need to know about Automation Account and their update management feature.

Context

This part will be very important since it define all the strategy to configure the Automation Accounts. So, if you remember my introduction post, we want to update machines bases on the following rules :

• Apply only security and critical patches
• Apply patches once a week
• Reboot only if needed

All of this can be configured in In addition to those rules, we will configure deployment schedules, which are some sort of automation accounts sub-resources. For each automation account, we will 21 deployement schedule! This is a lot, be let me explain : the goal of this solution is to allow any business application to patched. To make it possible, we need to propose many schedules to comply with all application constraints. So we decided to propose 3 schedule maintenance per day : at 3:00, 12:00, and 22:00 (3*7 = 21 schedules).

My ultimate goal with this is to create a deployment schedule that select the appropriate machines, based on machines tags. Just imagine how simple it would be : if a machine must be updated, I assign a tag to it (the tag MON-03:00 for instance), and I know that my deployment schedules will update it. Let’s see how to do this!

Automation accounts

Create deployment schedule

We can create a first deployment schedule to check what it looks like.

1. Create an Automation Account if not done
2. Navigate to your Automation Account
3. Navigate to the Update management pane
4. Click on Schedule update deployment
5. You will see settings to be configured as described in the following table.

What we observe so far is that we can’t merge Linux and Windows in the same deployment schedule, so our deployment schedules will now look like this :

Let’s continue with the settings groups to update and machines to update, which are both settings that allow you to choose which machines should be updated with the current deployment schedule.

Machines to update

When using this feature, we can define a group of machines to target with the current deployment schedule. This group of machines can be created from multiple sources as discussed in the Microsoft documentation :

• Log query
• Log search API
• Active Directory
• Configuration Manager
• Windows Server Update Services

As mentioned in the first part of this post, I want my VMs to be updated if they have a specific tag. Unfortunately, with this setting, we can’t update machines based on their tags! So let’s take a look at the Groups to update feature then.

Groups to update

As described in the Microsoft documentation, we can filter machines based on their tags, awesome right? So this will be our solution, but our solution has an important limitation : this does not apply to Azure ARC VMs! This is immediately not so awesome… But I have a workaround that I will describe in a future post, so let’s continue with Azure VM only for now.

I recommend to do some testing if you want to get familiar with deployment schedules capabilities. If you want to go straight foreward, let’s deploy some stuff now!

Deployment

The only thing you need to do for deployment is to create a dedicated resource group where our resources will be deployed. You will need two files :

• The core_infrastructure_azure.json file is a simple ARM template that describe the architecture we’re about to deploy.
• The core_infrastructure_azure.parameters.json file is a parameter file where you can change resources names.

Before running the commands below, make sure you chose an existing resource group or created one.

az login
az account set --subscription <subscriptionId>
az deployment group create --name <anyName> --resource-group <resourceGroupName> --template-file core_infrastructure_azure.json --parameters core_infrastructure_azure.parameters.json

Here is a sample output for deployment.

What did we deployed? We deployed the three following resources.

We can’t see deployment schedule here : we can view them from the automation account, so navigate to the resource, and you will see two deployment schedules that look the same, expect one is for Windows OS, the other for Linux.

If you take a look at the Linux deployment schedule, you will see the configuration we pushed through our ARM template. In the Groups to update setting, we look for machines located in the current subscription and tagged with patch:LINUX-MON-03:00 tag.

Now that the core infratructure is deployed, we can assign an Azure policy (c.f. Part 2 of the serie) to the subscription scope and enforce Log Analytics agent to report to our newly deployed Log Analytics workspace. Then you can deploy a VM that will be directly onboarded!