Azure Update Manager: Modern Patching for the WSUS Administrator

If you’ve spent time as a Sysadmin or in an IT Operations team, chances are you’re familiar with Windows Server Update Services (WSUS). It’s the default option for patching Windows in many organisations. Managing WSUS often involves battling disk space consumption, unexpected failures, and the occasional full rebuild. Sound familiar? 

For those still navigating the complexities of WSUS, there’s a more streamlined, modern approach: Azure Update Manager (AUM). This cloud-native service is designed for patching Windows and Linux servers efficiently across Azure, on-premises, and even multi-cloud environments. 

Let’s explore how Azure Update Manager in the context of its similarities and differences to WSUS.  

Key Comparisons: Azure Update Manager vs. WSUS 

Here’s a side-by-side look at how WSUS and Azure Update Manager handle key aspects of patch management: 

Feature/Aspect	WSUS (Windows Server Update Services)	Azure Update Manager (AUM)
Primary Update Source	Microsoft Update	Microsoft Update (or other configured repositories)
Operating System Scope	Windows OS & Microsoft Products (e.g. SQL Server)	Windows OS & Microsoft Products plus native Linux support (using apt, yum, etc.)
Supported Systems Focus	Windows Servers & Windows Client devices (e.g., Windows 10/11)	Primarily Server Operating Systems (Windows Server & Linux). (Clients managed via Intune/Autopatch)
Update Types Handled	OS Updates, Application Updates, Driver Updates	OS & Application Updates. Excludes driver updates. (Often less critical for servers, especially VMs where hypervisor updates manage hardware compatibility).
Machine Targeting	Typically, Active Directory OUs & Group Policy (static)	Azure Tags & Dynamic Scopes (query-based groups) for flexible, automated targeting
Update Distribution Model	Downloads updates centrally, stores locally. Requires sync & storage.	Clients pull updates directly from source (e.g., Microsoft Update). No central storage needed.
Infrastructure Impact	Requires significant local storage, bandwidth for sync, DB maintenance.	Minimal infrastructure footprint. Reduces storage and management overhead.
Onboarding & Management	Relies on Active Directory & Group Policy.	Azure-native. Uses Azure Arc for on-prem/multi-cloud, enabling hybrid management.
Key Dependency	Active Directory	Azure (via Azure Arc for non-Azure machines)

Why Organizations Are Migrating from WSUS to AUM 

Assisting customers with this transition, we typically implement structured approaches focusing on: 

• Simplified Targeting: Leveraging tag-based dynamic grouping for easier VM management. 

• Reduced Risk: Implementing staggered deployment schedules across different environments (Dev, Test, Prod). 

• Automation: Creating automated patching schedules based on environment criticality and maintenance windows. 

• Business Alignment: Defining patch windows that minimise disruption to business operations and user activity. 

• Enhanced Visibility: Utilising Azure dashboards and compliance reporting for internal audits and security posture assessments (like Essential Eight maturity in Australia). 

A common strategy involves piloting AUM with non-production systems before rolling out to production workloads, often split across multiple maintenance windows. 

Practical Considerations and Lessons Learned 

Migrating to and effectively using Azure Update Manager involves more than just replacing WSUS. Here are key considerations and lessons learned from real-world implementations:

1. Meeting Compliance Requirements (Essential Eight / ISM)

• Increased Frequency: Compliance frameworks like Australia’s Essential Eight and ISM often mandate rapid patching. Moving to AUM typically involves increasing patch frequency compared to older WSUS schedules. 

• Strict Timelines: Key requirements often include patching internet-facing or critical services within 48 hours of vulnerability disclosure or patch release, and patching all other systems within two weeks. AUM’s automation and scheduling capabilities are crucial for meeting these timelines reliably. 

• Targeted Approach: Design schedules specifically for critical systems (like those in a DMZ) to meet the 48-hour window, separating them from less critical workloads with longer patch windows. (Check out our blog on DMZ patching strategies). 

2. Understanding Patch Tuesday Timing for Scheduling 

• The Anchor Point: Microsoft’s “Patch Tuesday” is the critical date around which most Windows patching schedules are planned. It occurs on the second Tuesday of each month, typically releasing updates around 10:00 AM Pacific Time (PST/PDT). 

• Australian Timing: Due to time differences, this usually translates to the early hours of the second Wednesday of the month in Eastern Australia (AEST/AEDT). Be mindful that exact timing can shift slightly due to daylight saving changes in different hemispheres. 

• Scheduling Impact: Since Patch Tuesday falls on different dates each month (though always the second Tuesday), relying on fixed dates for patching can be unreliable. Basing recurring schedules on offsets from Patch Tuesday (e.g., “Third Monday”) ensures consistent timing relative to patch releases. 

3. The Importance of Reboots 

• Applying the Fix: Many critical updates require a system reboot to fully apply the fix and modify necessary system files or services. 

• Risks of Skipping Reboots: Simply installing updates without rebooting when required leaves the system in an unknown and potentially vulnerable state. The patches aren’t truly active. For example, applying a critical .NET security update without a reboot won’t protect the running web application until that reboot occurs. 

• AUM Reboot Control: AUM provides explicit control over reboots (RebootIfNeeded, NeverReboot, AlwaysReboot). Whenever feasible, configure schedules to reboot if required (RebootIfNeeded or AlwaysReboot) to ensure patches are effective. 

4. Strategic Selection of Update Classifications 

• Automate Core Security: For automated schedules, focus on classifications like Critical, Security, and Definition updates. These are essential for maintaining security posture. Update Rollups (UpdateRollup) often bundle these and can be included. 

• Caution with Functional Changes: Be cautious when automatically applying Feature Packs, Service Packs, or Tools, especially in production environments. These classifications often introduce new functionality or significant changes that require testing to avoid unexpected side effects or application compatibility issues. Consider applying these manually or in controlled non-production phases first. 

5. Establishing Clear Naming Conventions 

• Consistency is Key: As you create Azure Tags for grouping and AUM Maintenance Configurations (schedules), adopt a clear, consistent naming standard. This is vital for manageability, automation, and understanding your patching structure at a glance. 

• Example Standard: We often use a structure that incorporates key details, especially when managing multiple schedules with different timings (e.g., 12 AM and 3 AM windows) within the same group of machines: Environment-GroupTiming-Time-Classifications-RebootOption 

• • Environment: NonProd, Prod, Prod-DMZ, NonProd-DB-AG1 (identifies workload/location) 

• • GroupTiming: Defines the schedule relative to Patch Tuesday (assumes Patch Tuesday is Day 1). Examples:  

• • • NP: Non-Production (e.g., Second Thursday) 

• • • G1: Group 1 (e.g., Third Monday) 

• • • G2: Group 2 (e.g., Third Friday) 

• • • G3: Group 3 (e.g., Fourth Monday) 

• • Time: Patching window start time: 12am, 3am. (Can denote specifics like AG1/AG2 for staggered cluster patching at 12 AM / 3 AM respectively). 

• • Classifications: Included update types: All, Definition, CriticalSecurityRollup 

• • RebootOption: Reboot, RebootIfNeeded, NoReboot 

Example Result: Prod-DMZ-G1-12am-CriticalSecurityRollup-RebootIfNeeded clearly indicates patching Production DMZ servers in the first group (Third Monday) at 12 AM, applying Critical/Security/Rollups, and rebooting if needed.

6. Overcoming Common Migration Hurdles 

Remember those initial setup challenges: 

• Lingering legacy WSUS GPOs overriding AUM settings. 

• Persistent registry entries redirecting update checks to decommissioned WSUS servers. 

• Firewall rules blocking necessary communication with Microsoft Update endpoints or Azure services. 

• Azure Arc agent onboarding challenges (often resolved via scripting or targeted GPOs for agent deployment). 

Modernise Your Patch Management Strategy 

Azure Update Manager provides a reliable, scalable, and policy-driven solution for managing updates across today’s hybrid IT landscapes, without the infrastructure burden and limitations of traditional WSUS setups. 

Still relying on WSUS? It might be time to evaluate a modern alternative. 

Ready to modernise your patch management? Codify can guide your transition from WSUS to Azure Update Manager, ensuring a streamlined, secure, and efficient patching process tailored for your environment.

Get In Touch with Codify’s Microsoft Azure Specialists