When Azure Arc Servers Patch Too Early: Understanding Update Manager Behavior

You’ve configured Azure Update Manager, defined maintenance windows, everything looks correct — and yet your servers onboarded to Azure Arc start patching before the scheduled window.

If this sounds familiar, you’re not alone. This is a fairly common scenario, and today I’d like to explain why it happens and how Azure Update Manager actually works under the hood, especially in Azure Arc environments.

How Azure Update Manager Really Works

One of the easiest mistakes to make is to assume that Azure Update Manager controls patching. It doesn’t. Azure Update Manager coordinates patching, schedules it, reports on it — but the actual work is done by the operating system itself.

On Windows, that’s still the good old Windows Update Agent. On Linux, it’s whatever package manager the system uses. Azure Update Manager doesn’t ship updates and it doesn’t override how the OS behaves by default. It simply asks the local update client: “What’s missing?” and “Can you install this now?”

Azure Update Manager simply:

Assesses update compliance using the local update client
Triggers installation using that same local client

To do this, it installs specific extensions depending on the platform:

Azure VMs
- Azure VM Agent
- Windows/Linux Patch Extensions
Azure Arc machines
- Azure Connected Machine Agent
- Update Manager extensions

This architectural difference is the key to understanding the behavior you’re seeing.

Azure VMs vs Azure Arc Machines — Why Behavior Differs

Azure virtual machines and Azure Arc machines look identical in the portal, but they behave very differently.

With Azure VMs, Azure can step in and temporarily take control. When you enable Azure-orchestrated patching, Azure is allowed to tweak Windows Update behavior just enough to enforce your maintenance window. This is why Azure VMs usually behave exactly as expected.

Azure Arc servers are different. They remain fully OS-driven. Azure Update Manager does not change Windows Update registry settings and does not override Group Policy. Whatever Windows is configured to do locally is exactly what it will do — with or without Azure Update Manager watching.

This is the point where most “maintenance window issues” are born.

Why Patching Starts Too Early

When a Windows server patches outside the maintenance window, it’s usually because Windows was simply allowed to do so.

By default, Windows is perfectly happy to install updates on its own. If Automatic Updates are enabled and no policy tells it otherwise, the OS won’t wait politely for Azure Update Manager’s schedule. It will just patch.

Azure Update Manager sees this happen, reports it correctly, and gets blamed anyway.

The GPO Setting That Changes Everything

If you want predictable patching on Azure Arc servers, you need to be very intentional about Windows Update configuration. The most important setting is NoAutoUpdate.

In Group Policy, this lives here:

			
Computer Configuration
 → Administrative Templates
   → Windows Components
     → Windows Update
       → Configure Automatic Updates

		

If this policy is Not Configured (which is surprisingly common), Windows will do what Windows does best: patch whenever it feels like it.

To keep patching under control, you typically want something like:

			
Configure Automatic Updates: Enabled
Configure automatic updating: 2 – Notify for download and auto install

Under the hood, this results in:

NoAutoUpdate = 1

This tells Windows: “Do not install updates on your own. Wait to be told.”

If you need to add the registry key to the machine that is not domain joined you can use this powershell snippet:

			
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Force | Out-Null
New-ItemProperty `
  -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" `
  -Name "NoAutoUpdate" `
  -PropertyType DWord `
  -Value 1 `
  -Force

		

If you want to verify it afterward:

			
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" |
Select-Object NoAutoUpdate

On Azure VMs, Azure can enforce this for you. On Azure Arc servers, you must do it yourself. Azure Update Manager will not step in.

What Azure Update Manager Actually Does Well

Once Windows Update behavior is aligned with your expectations, Azure Update Manager works exactly the way you want it to. It schedules patching, respects maintenance windows, gives you clean reporting, and lets you manage patching centrally across hybrid environments.

But it assumes that the operating system is already behaving properly. It doesn’t fix Windows Update misconfigurations — it exposes them.

The Takeaway

If your Azure Arc servers are patching before the maintenance window, the root cause is almost never Azure Update Manager. It’s usually Windows doing what it was told to do — or not told not to do.

Azure Arc gives you visibility and orchestration, not control over the OS. Once you accept that and configure Group Policy accordingly, patching becomes boring again. And boring patching is the best kind.

Discovering Azure