Planning Azure Update Manager Deployment

Leave a reply

Overview: 

Azure Update Manager has been around for a while, however recently I had a chance to deploy this in production. Sharing my experience with this amazing product which can be a perfect alternative if: 

  • you have WSUS servers, SCCM servers that are specifically used for patching. 
  • you are looking to consolidate servers across your on-prem, Azure, Or Any other location
  • you are looking for a simple, yet powerful product to solve your patching issues instead of spending on a product in the market.

To summarise in one word it is ‘seamless’. My customer was using a very old WSUS server (Yes, they still exist!!) to patch their Windows servers across their estate. The customer had a few hundred servers spread across a couple of domains! Naturally, they had a couple of WSUS servers that the IT team had to manage. Of course, over the years, patching became a nightmare/taboo topic in the organization. As everything was now manually being patched and few servers were not patched for about a year.

What Azure Update Manager can do?

  • Deploy Windows Updates (Obviously)
  • Help you plan and schedule your updates 
  • Create complex server updates status reports (using log analytics workspace)
  • Helps you automate patch deployment in your organization for the following types of updates:
    • Critical Updates
    • Security Updates
    • Update Rollups
    • Feature Packs
    • Service Packs
    • Definition Updates
    • Tools
    • Updates

What Azure Update Manager cannot do?

  • Deploy applications to servers 
  • Deploy application updates 
  • Install Printer Drivers 
  • Deploy Anti-Virus updates (except for Windows Defender)

Planning:

To effectively deploy this solution you would need the following: 

  • A log analytics workspace 
  • Automation Accounts
  • Microsoft Monitoring Agent setup for endpoints
  • A strategy for how you would be grouping the servers for patching into different patch rings
  • A patching schedule plan
  • Azure Monitor (optional for monitoring)
  • pre and post check scripts (optional)
Overall, once the solution is implemented, it would look something like this: 

Log Analytics Workspace: 

The log analytics workspace is required for the Servers / Endpoints to report in their monitoring data, this would include basic server performance information and security information related to patching. This data will then further facilitate the update manager for automation of patch deployments.

Automation Account:

An automation account is required for enabling the Azure update manager on the Servers that are reporting into the log analytics workspace associated with it. It is in this automation account that you would configure the patch rings, schedules, and also the pre/ post check scripts that you would use for patching.

Microsoft Monitoring Agent:

The purpose of the Microsoft monitoring agent is to ensure that the endpoints can feed in their information (security, updates) into the log analytics workspace. All the servers that are expected to be managed as part of the azure update manager for patching need to have the Microsoft Monitoring Agent installed.
Microsoft Monitoring Agent in turn will help you to deploy the Update Agent which is required for you to manage the servers using Update Manager.

Strategy for Patch Rings:

This is probably a bit tricky and might require some additional planning based on your customer’s preference and how advanced are they in their cloud journey. There are plenty of ways to accomplish this and you can get really creative, I will just list out a few: 

  • Patch rings based on Azure VM tags (suitable if the servers are all on Azure)
  • Patch rings based on Server Names (requires you to write log analytics workspace queries)
  • Patch rings based on Active Directory Groups (A very simple, legacy way of doing it, if the servers are spread across on-premises and Azure)

 Strategy for Schedules: 

Like planning your patch rings, you can do this in multiple ways. But typically, it would be either a fully automated approach or a semi-automated approach.

Automated Approach: 
In this approach, you would create scheduled tasks on the automation account/update-manager such that selected types of updates are automatically installed on the servers during a planned schedule. The majority of customers want to get to this state.

Semi-Automated Approach:
In this approach, you would selectively update the patches to be deployed on your servers instead of generally selecting a type of update to be deployed automatically. the only manual effort involved in this is mostly to update the KB numbers on the schedules.

Onboarding Servers to Azure Update Manager:

Onboarding servers to Azure Update Manager is quite simple. The steps involved are: 

  1. Install Microsoft Monitoring Agent 
  2. Configure Microsoft Monitoring Agent to communicate with Log Analytics workspace for update manager 
  3. Enable Update Agent on the servers

For servers on Azure, I simply used the policies to push out the agent to servers. For on-Prem, however, I utilized the GitHub script here: Install-MMA

Once the servers are onboarded to the solution and enabled for Update Management, the servers will take about 12 hours for them to successfully report information on Azure Update Manager.

Leave a Reply