Patching with Azure

The Background Story

Back when I was an Infrastructure Engineer for a Managed Service Provider, patch management was both the bane of my life and something I enjoyed.

I didn't enjoy the late nights patching and restarting servers, having to be on site on my own watching servers tentatively start up and sometimes crash and burn because of the patches I installed. However, I did enjoy scheduling it out, figuring out what servers were able to be patched during the day without service impact, etc. I developed some really good documentation, colour spreadsheets and repeatable material we could use for all of our clients.

Thankfully in my current role that isn't something I need to worry about. But recently I've kicked some life into my home lab and when setting it up and installing new virtual machines (VMs) onto it I've had the dreaded you have 4 gazillion patches to install. Which I have to do before I get involved in the actual work that I spun up the lab for unfortunately.

Back in my previous jobs we (mostly) used Windows Server Update Services (WSUS), in our client environments to manage their server and desktop patch management. I didn't want to use that within my home lab setup as setting that up takes time, can be quite time consuming to manage and maintain. As I'm all Azure based these days at work I wanted to focus on seeing how Azure could help me solve this issue.

My Home Lab

In previous blogs I've mentioned that my home lab equipment is getting a bit old now, it is a HP ProLiant Microserver N40L, Generation 8.  It still allows me to do some testing on features, and build environments that mimic what customers often have, not everyone has flashy new tin or the latest operating systems within their datacenters so trying to understand how you can still use Azure in these situations is helpful.

VMware to Hyper-V

So for the last few months I've been running VMware on my home lab in order to make use of Azure Migrate, but with the announcement that Hyper-V support is now in private preview for Azure Migrate I'm rebuilding my lab from the VMware ESXi 5.5.0 Update 2 environment I've been running to a Windows Server/Hyper-V environment.

The Problem

This brings up the problem of patches. The ISO file that I downloaded of Windows Server 2012 R2 for those host operating system (OS) is out of date. So my first hurdle before actually building my Hyper-V environment is to patch the host. On first boot up, I had 135 updates waiting for me on the first check.

I knew if I used that ISO to build my VMs I'd have the same problem, plus I'd have to manage the machines going forward each time new patches came out, so onto the solution....

Patching with Azure Update Management

Azure Update Management is part of the Azure Automation solution. It can be used to patch Azure machines and non Azure machines. However, to use it on non Azure machines you also need to utilise Log Analytics. So as my environment is non Azure I need to have a Log Analytics workspace set up as well as the Automation.

Getting Started

So the first step is creating a Resource Group within Azure for my resources to be stored. If you go over to the Azure Portal, click on Create a Resource and find Resource Group. Make sure you give it an appropriate name and select the correct location for your resource group.

The second step is to create a Log Analytics workspace in Azure. Within your Resource group click on Add and create a Log Analytics space.

Now that is deployed, in order for my on premises machine(s) to talk to the Azure Log Analytics workspace I need to install the agent.

Agent Installation

The Agent that you need to install is the Microsoft Monitoring Agent (MMA), for those of you familiar with SCOM you will be familiar with this agent, it is the same one that Log Analytics needs. The agent can be downloaded from within your Log Analytics workspace under Settings. During the installation of the agent you will need to input your Workspace ID and Workspace Key, so have them to hand during the installation.

Now that the agents are installed and my machines are talking to Log Analytics, I need to start implementing the functionality I need in order for my machines to be patched automatically for me. This means Log Analytics Solutions...

Log Analytics Solutions

Within Log Analytics there are things called Solutions. Solutions help you to leverage services within Azure. In order to do Patch Management I need to install the Update Management solution within Log Analytics.

To install the solution, open the OMS Portal. Down the left handside you will see five buttons down the left hand side. The fourth button from the top is the Solutions Gallery, click into this.

You are looking for the Update Management solution. When you select this you will be asked to configure it. The configuration screens will ask about an Automation account, if you already have one set up and wish to reuse it for this then input the relevant details. Otherwise create a new one as directed.

Now that the solution is installed I can start to setup a patching schedule for my machines. To do that I need to open the Automation Account blade.

One of the options, the 9th down the list is Update Management, click into that. You will be presented with several options. The first one to explore is Schedule Update Deployment, this is where you define what machines need to be updated, when, how often, what patches to apply and whether the schedule is allowed to restart the machine.

This is very much like how you would set up Group Policy Settings for use with WSUS, with a bit of extra functionality.

I've set up three groups in my configuration:

• N40L Host - this patches my Host machine
• Windows VMs - this patches the Windows virtual machines within my host
• Linux VMs - this patches the Linux virtual machines within my host

Each of my groups have slightly different maintenance windows and patching schedule relevant to their role within my environment. I'd always recommend you do the same, group machines relating to their function, adhering to your high availability needs and demands. Within my schedules I am allowing the Update Management solution to reboot my machines if it is needed. Again, evaluate whether this would be okay within your environment. Automating the patching schedule within your environment has many great benefits but be sure to plan it out and apply the appropriate settings for your machines.

Below is a screenshot of my environment:

It shows that the Update Management solution has been working away to patch my environment and get it up to date. Some machines are considered compliant and up to date while others are still in a non-compliant state.

The Update deployments have ran, failed succeeded or had to short a maintenance window to fully complete. This is shown below:

The failure can be explained by me, I had left a bootable USB plugged into the host so when it restarted it got confused and tried to boot into that instead.

The maintenance window being too small is partly due to the amount of patches that the update deployment is trying to deploy and also my settings. It's one to watch out for within your environment, if you have to short a maintenance window it may never be fully compliant with all the patches you are applying. This is something you need to have a think about and whether or not it will be acceptable in your environment or if you need to schedule a large maintenance window, say once a month to try and catch up.

Going forward

Going forward my update deployments will take care of the patching for me and whenever I build a new machine within my lab if I install the agent and add it to the update deployment group patching will be taken care of.

Some of the process is still manual but it should save me time in the long run.

As always if you’d like to reach out and speak to me about any of the above please get in touch via Twitter @TechieLass