Azure Update Manager replaces Automation Update Management for patching

I stopped counting a while ago how often people ask me about patch management in Azure, and the questions have only increased since Microsoft announced that Automation Update Management will be retired by the end of August 2024. Plenty of environments still run on the old solution. Azure Update Manager is now the default for keeping Windows and Linux servers up to date, in the cloud and on-premises alike. You no longer have to juggle Automation Accounts and Log Analytics workspaces just to run a patch job. In my experience the process really is simpler now, and it's much easier to keep track of what gets patched, when and how.

Azure Update Manager drops the old dependencies on Automation and Log Analytics

The legacy solution required both an Automation Account and a Log Analytics workspace for every patch deployment. That added complexity and cost, particularly in larger or more distributed setups. Azure Update Manager gets rid of both requirements. You manage periodic update assessments, maintenance configurations and scheduled patch deployments directly in the Azure portal, and you don't need a separate workspace for any of it. Onboarding is faster, and update management sits in one place where it feels like part of the platform rather than an add-on. What I like in particular is that assessments can now run independently of patching cycles, so you can check update compliance whenever you want. The official docs give a good overview.

Maintenance configurations and dynamic scopes give you real scheduling flexibility

Coordinating maintenance windows for patching is one of the problems I run into most often. Azure Update Manager handles this with "Maintenance Configurations", where you define exact schedules, patch orchestration rules and custom time windows. Dynamic scopes are the part I value most. You group VMs by tags or other criteria, and the update policies apply automatically when servers are added or get new tags. Compared to the old system, that saves a lot of manual work, especially where virtual machines are created and removed all the time. You'll find more details in the documentation on scheduled patching.

The other thing I really like is support for Arc-enabled servers. Your machines can sit on-premises, in another cloud or at the edge, and Azure Arc still lets you manage their patches in the same place (billed per server, per month).

This mermaid diagram shows how maintenance configurations, dynamic VM groups and Arc-enabled servers relate to each other:

flowchart TD
  Group["VM group (tags/scope)"] --> Config["Maintenance Configuration"]
  Config --> Time["Schedule"]
  Config --> Orchestration["Patch orchestration"]
  Config --> Assessment["Update assessment"]
  Group --> Arc["Arc-enabled servers"]

Figure: Maintenance configuration and dynamic targeting in Azure Update Manager.

Separate update assessments show you where every machine stands

In daily work I find it very useful that update assessments can run on demand or on a schedule, separately from the actual patching. You get an almost real-time picture of which updates are missing on each machine, and that matters a lot for reporting and compliance. The patch orchestration options have also grown. You can control reboot behavior, define the order in which machines are patched and lower the risk of downtime, which helps when systems depend on each other. If you're coming from Automation Update Management, Microsoft's migration guidance walks through the main steps. In practice I've usually had to adjust a few things by hand, mostly dynamic VM groups and custom windowing.

My tip: In production, run update assessments daily, or at least before every planned patch cycle. That way you spot new vulnerabilities and compliance deviations early, before they turn into problems.

The migration from Automation Update Management needs planning

Automation Update Management and the Log Analytics agent (MMA) are retired after August 2024, so you need a migration plan. Azure Update Manager does work standalone, which helps. You'll still have to review and re-create maintenance schedules, scopes and policies, and that's more work if you built custom automation around the old setup. For monitoring you may also need to move to Azure Monitor Agent (AMA), although patch management itself no longer depends on a Log Analytics workspace.

Here's what a typical maintenance configuration in Azure Update Manager looks like in JSON:

{
  "properties": {
    "maintenanceScope": "OSUpdate",
    "schedule": {
      "frequency": "Weekly",
      "interval": 1,
      "startTime": "2024-02-01T02:00:00Z"
    },
    "duration": "PT2H"
  }
}

In a large environment, start early so the end of the old solution doesn't catch you off guard.

Hotpatching and Arc support extend what the service can do

Hotpatching for Windows Server Azure Edition VMs is getting more attention lately. Security updates install without a reboot, which makes a real difference for highly available workloads. It only works on specific Windows versions and VM types, though. With the broader Azure Arc support, you can patch traditional on-prem servers and edge deployments in the same way as your Azure VMs, and that pays off even more once you combine it with dynamic scopes and automation. Arc-enabled server management is billed per machine per month, so factor that into your cost planning.

Now is the right time to rethink your patch management

For hybrid and cloud-first organizations, Azure Update Manager is a clear improvement. Microsoft removed the old dependencies and added flexibility in scheduling and targeting, and the result is patching that is both easier and more secure. If you migrate early, you'll have less pressure and a chance to standardize your processes before the August 2024 cutoff. If you already work with Azure infrastructure, take a look at Azure Update Manager and start planning the move. It will be the standard way to patch in Azure from now on.