How to Fix Azure Update Manager: Setup, Errors & Best Practices
Why Azure Update Manager Isn't Working the Way You Expect
Azure Update Manager is one of those services that looks straightforward until you actually try to get it running at scale , and then things get complicated fast. I've seen this pattern repeat constantly: an engineer enables Azure Update Manager on a handful of VMs, compliance data either never populates or shows wildly inaccurate numbers, scheduled deployments silently fail, and the error messages in the portal are so vague you almost wish they hadn't bothered showing them at all.
Here's the honest truth about why most Azure Update Manager problems happen. The service depends on two layers of infrastructure working correctly before it can do anything useful: the VM agent running on your machine, and the Azure extension that Update Manager installs the first time any operation is triggered. If either of those is broken, misconfigured, or simply too old, every single Update Manager feature , compliance checks, scheduled patching, on-demand installs, periodic assessments, will either fail silently or throw generic errors that point you nowhere specific.
On Azure VMs, that extension is Microsoft.CPlat.Core.WindowsPatchExtension for Windows machines and Microsoft.CPlat.Core.LinuxPatchExtension for Linux. On Azure Arc-enabled servers, Update Manager actually installs two extensions instead of one. A lot of people don't know that, and it catches them off guard when Arc machines behave differently than their native Azure VMs.
Another frequent source of frustration: the update source configuration. Azure Update Manager doesn't publish or provide updates itself. It reads and respects whatever your Windows Update Agent (WUA) is already configured to use, whether that's Windows Update, Microsoft Update, or your own WSUS server. If WUA is pointed at a WSUS server that's unreachable, or if group policy is overriding your settings without you realizing it, Azure Update Manager will faithfully report "no updates available" even when you're months behind on patches. The service isn't broken, your source configuration is.
I know this can feel genuinely maddening, especially when you're trying to prove compliance to a security team or meet a patching SLA. The good news is that the vast majority of Azure Update Manager issues fall into a handful of fixable categories, and none of them require opening a support ticket if you know where to look.
The Quick Fix, Try This First
Before you go digging into logs and registry keys, try this. It resolves probably 60% of Azure Update Manager issues in under five minutes.
Go to the Azure portal and navigate to Azure Update Manager. In the left-hand menu, select Machines. Find the VM that's giving you trouble, click on it, and then click Check for updates, not from the VM's blade, but from directly within Update Manager. Hit that button and wait.
What this actually does: it forces Update Manager to trigger its extension installation if it hasn't happened yet. Remember, Update Manager extensions are not pre-installed. They only get deployed the first time you run an operation, a compliance check, an on-demand install, a scheduled deployment, or a periodic assessment. If the extension was never triggered, nothing works and no errors are shown. You're just looking at an empty dashboard.
After clicking Check for updates, head over to the VM's blade in the portal, select Settings > Extensions + applications, and click the Extensions tab. Within a few minutes, you should see WindowsPatchExtension or LinuxPatchExtension listed with a status of Provisioning succeeded. If that status shows up, go back to Update Manager, your compliance data should start populating within 10–15 minutes.
If the extension shows Provisioning failed instead, or doesn't appear at all, that's your smoking gun and you'll need the full step-by-step below. But for a brand-new machine that just "never showed up" in the Update Manager dashboard, triggering that first operation is almost always the answer.
Everything in Azure Update Manager runs on top of the VM agent. For Azure VMs, that's either the Azure Windows VM Agent (WindowsAzureGuestAgent.exe) or the Azure Linux VM Agent (waagent). For Azure Arc-enabled servers, it's the Azure Connected Machine agent. If this agent is outdated, stopped, or corrupted, the Update Manager extension will either fail to install or fail to report back.
On a Windows VM, open an elevated PowerShell session and run:
Get-Service WindowsAzureGuestAgent | Select-Object Status, StartTypeYou want to see Status: Running and StartType: Automatic. If it's stopped:
Start-Service WindowsAzureGuestAgent
Set-Service WindowsAzureGuestAgent -StartupType AutomaticTo check the agent version, look here:
Get-Item "C:\WindowsAzure\GuestAgent_*" | Sort-Object Name -Descending | Select-Object -First 1On a Linux VM:
sudo systemctl status waagent
waagent --versionIf the agent version is more than 6 months old, upgrade it. On Windows VMs this happens automatically through Windows Update in most configurations, but on older images or machines where Windows Update is partially disabled, the agent can stagnate. On Linux, use your package manager: sudo apt-get install walinuxagent on Ubuntu/Debian, or the equivalent for RHEL/SUSE.
If the agent is current and running, you'll see a green status indicator on the VM's Overview blade under Agent status in the portal. That's your confirmation this layer is healthy before moving on.
With the VM agent confirmed healthy, the next thing to check is the Update Manager extension itself. In the Azure portal, navigate to your VM, go to Settings > Extensions + applications, then click the Extensions tab. Look for Microsoft.CPlat.Core.WindowsPatchExtension (Windows) or Microsoft.CPlat.Core.LinuxPatchExtension (Linux).
If the extension shows Provisioning failed, click on it and check the status message. Common failure messages include "Handler not ready" and "VM agent is not in a ready state", both of which circle back to the agent issue from Step 1. If the agent is healthy but the extension still fails, try removing and letting Update Manager reinstall it.
To remove the extension via PowerShell:
Remove-AzVMExtension `
-ResourceGroupName "YourResourceGroup" `
-VMName "YourVMName" `
-Name "WindowsPatchExtension" `
-ForceAfter removal, go back to Azure Update Manager, find the VM, and click Check for updates again. This triggers a fresh extension install. Watch the Extensions + applications blade, within 5–10 minutes you should see the extension reappear with Provisioning succeeded.
For Azure Arc-enabled machines, remember that Update Manager installs two extensions, not one. Both need to show as successfully provisioned. If one is stuck, remove both and let Update Manager reinstall the pair together by triggering any Update Manager operation on that machine.
A successful reinstall means the extension status reads Provisioning succeeded and the Handler status reads Ready. Once you see both, the machine is properly onboarded to Azure Update Manager.
One of the most common complaints I hear about Azure Update Manager is "the compliance data is wrong" or "it says my machines are up to date but I know they're not." Nine times out of ten, this comes down to periodic assessment not being enabled. Without it, the update compliance data you see in the dashboard is just a snapshot from the last time someone manually checked, which might have been weeks ago or never.
Periodic assessment, when enabled, automatically checks your machines for available updates every 24 hours without requiring any manual action. Here's how to turn it on for individual machines:
- In the Azure portal, go to Azure Update Manager
- Select Machines from the left menu
- Click the machine you want to configure
- Under Update settings, click Change update settings
- Set Periodic assessment to Enable
- Click Save
For Azure Arc-enabled servers the path is the same. If you need to enable this at scale across hundreds of machines, the right approach is Azure Policy, specifically the built-in policy definition "Configure periodic checking for missing system updates on azure virtual machines." Assign it at the subscription or management group level and it will handle enablement automatically for every matching machine.
After enabling periodic assessment, don't expect instant results. The first automated scan runs within 24 hours of enablement. If you need data faster than that, use the Check for updates button to trigger an immediate on-demand assessment. You'll see the Last assessment time column in the Machines view update to reflect the fresh scan timestamp once it completes.
If your machines are showing "no updates" despite clearly being behind, the problem is almost certainly the update source. Azure Update Manager doesn't decide where Windows looks for patches, that's governed by the Windows Update Agent configuration on each machine, and Update Manager simply respects whatever is already set.
To check the current WUA configuration on a Windows machine, open an elevated PowerShell session and run:
$wu = New-Object -ComObject "Microsoft.Update.ServiceManager"
$wu.Services | Select-Object Name, IsDefaultAUService, ServiceIDThis shows you every update source registered on the machine. The one with IsDefaultAUService: True is what WUA is actually using. Common values:
- Windows Update, the standard Microsoft-hosted service
- Microsoft Update, same as above but also includes Office and other Microsoft products
- Your WSUS server name, indicates WUA is pointed at an internal WSUS server
If you see a WSUS server listed and WSUS is unreachable (network outage, expired certificates, server decommissioned), that explains everything. WUA can't find updates, so Update Manager reports none. You have two options: fix the WSUS connectivity issue, or switch the machine to pull from Windows Update directly.
To check and update the WSUS registry settings manually:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" `
| Select-Object WUServer, WUStatusServer, UseWUServerIf UseWUServer is set to 1 and the server in WUServer is unreachable, that's your problem. If Group Policy is setting this, you'll need to address it at the policy level, changing the registry directly will just get overwritten on the next Group Policy refresh.
Scheduled update deployments are where Azure Update Manager gets genuinely powerful, but also where things can go wrong in ways that aren't obvious. If your scheduled deployments are running but no updates are being installed, or the schedule doesn't seem to trigger at all, work through this.
First, confirm the maintenance schedule itself is correctly configured. In Azure Update Manager, select Scheduling from the left menu (or History to review past runs). Check that the schedule's start date and time are in UTC, the portal shows local time in some views, which trips people up when deployments appear to "run late."
Second, check that the target machines are actually associated with the maintenance configuration. In the schedule detail view, look at the Resources tab. This is also where Dynamic Scoping comes in, if you're using dynamic scopes to group machines by criteria like tags or resource groups, verify the scope query is returning the machines you expect. A typo in a tag value is enough to exclude an entire fleet from patching.
For deployments that trigger but install nothing, check the History view and click into the specific deployment run. Look at the per-machine results. Common status values:
- Succeeded with no updates installed, the machine was fully patched already, or its update source returned no results
- Failed, click through to see the error detail; extension errors often show here as "Handler not ready"
- NotStarted, the machine was unreachable during the maintenance window (shutdown, network issue, or the VM agent wasn't responding)
If machines are frequently showing NotStarted, consider enabling the pre-event functionality in Update Manager to perform a health check before the deployment window starts. You can set up pre and post events using Azure Automation webhooks or Azure Functions, these fire before and after the maintenance window runs, giving you the chance to verify machine readiness or send notifications when something goes wrong.
Once a scheduled deployment completes successfully, the History view will show a green Succeeded status with a count of updates installed per machine. That's your confirmation the whole pipeline worked end to end.
Advanced Troubleshooting for Azure Update Manager
If the step-by-step above didn't get you sorted, you're dealing with something less common. Here's where I'd go next.
Role-Based Access Control Gaps
Azure Update Manager uses Azure RBAC for access control at the per-resource level, not at the Automation Account or Log Analytics Workspace level like the old Update Management solution. This is actually an improvement, but it means someone could have the right subscription-level permissions but still be blocked from running updates on specific machines because of a missing resource-group-level role assignment.
For Azure Update Manager operations, the relevant built-in roles are Azure Update Manager Contributor and Azure Update Manager Reader. If someone can see the dashboard but can't trigger operations, check their role assignment at the resource group level for the machines they're trying to patch.
Get-AzRoleAssignment -SignInName "user@yourdomain.com" `
-ResourceGroupName "YourResourceGroup" | Select-Object RoleDefinitionNameEvent Viewer Analysis on Windows
When extension operations fail and the portal error messages are too vague, the Windows Event Viewer on the machine itself often has better detail. Open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational. Event IDs to look for:
- Event ID 20, Installation failure: Windows failed to install the following update
- Event ID 25, A reboot is required to complete update installation
- Event ID 31, WUA failed to connect to the update service
For the extension itself, check the Azure Guest Agent logs at C:\WindowsAzure\Logs\WaAppAgent.log and the handler logs at C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension\. These logs capture exactly what happened during the extension's install and execution phases and are far more useful than anything in the portal UI.
Azure Arc Connectivity Problems
Azure Arc connectivity is a hard prerequisite for Update Manager on non-Azure machines. If the Arc agent can't reach Azure endpoints, Update Manager can't do anything, period. On Arc machines, check agent connectivity with:
azcmagent checkThis runs a connectivity test against all required endpoints and reports any failures. Common blockers include proxy misconfiguration and firewall rules blocking the Arc service URLs. All required endpoints need to be reachable over HTTPS (port 443). If you're running a proxy, configure it in the Arc agent with:
azcmagent config set proxy.url "http://your-proxy:port"Checking for Policy Conflicts
If machines consistently bounce back to incorrect WUA settings after you fix them, a Group Policy Object is almost certainly overwriting your changes. In an enterprise domain environment, run gpresult /h gpresult.html on the affected machine and open the output. Search for "Windows Update" in the Computer Configuration section to see exactly which GPO is setting the WSUS or Windows Update policy and which OU it's coming from.
If extension provisioning continues to fail after agent reinstallation, or if Azure Arc-enabled machines report "Handler not ready" despite the Connected Machine agent showing healthy, you've likely hit a platform-level issue that isn't fixable from your end. Same goes for situations where the Update Manager API calls succeed in the portal but nothing actually happens on the machine, no log entries, no extension activity. At that point, open a support case with the details from your extension logs and agent logs in hand. Microsoft Support has backend tooling that can inspect extension host logs on their side that you can't access yourself.
Prevention & Best Practices for Azure Update Manager
Once you've got Azure Update Manager working, the goal is keeping it that way. These practices are what separate teams that have smooth patch cycles from the ones scrambling every Patch Tuesday.
First, build your onboarding into your VM provisioning pipeline. The moment a new VM or Arc-enabled server comes online, trigger a Check for updates operation automatically, either through an Azure Policy or as part of your IaC deployment scripts. This ensures the extension is installed and the machine appears in your compliance dashboard from day one, rather than being discovered weeks later when someone runs a report and notices a gap.
Second, use Dynamic Scoping for your maintenance configurations rather than static machine lists. Maintenance schedules that use static machine lists become stale the moment you add or retire machines. Dynamic scopes that query by resource group, subscription, or tag automatically include new machines and exclude decommissioned ones without any manual updates to the schedule.
Third, take advantage of Azure Workbooks for reporting. The built-in Update Manager workbooks give you compliance status across your entire fleet, including historical trends. Set these up before your security or compliance team asks for a report, not after. You can customize the workbooks to filter by environment tags, operating system, or update classification (security vs. non-security).
Fourth, configure alerts. Azure Update Manager lets you create Azure Monitor alerts on update status. At minimum, set up an alert for machines that haven't had a successful assessment in more than 48 hours, that's your early warning system for agent problems or connectivity issues that would otherwise go unnoticed until patch day.
Finally, test your scheduling logic in a non-production subscription before rolling it out broadly. Dynamic scoping queries and pre/post event logic are worth validating on a handful of test machines before you attach them to a maintenance configuration covering hundreds of production servers.
- Enable periodic assessment via Azure Policy at the management group level so every new machine is auto-enrolled the moment it's provisioned
- Tag your VMs with an environment tag (prod, staging, dev) and use dynamic scopes to create separate maintenance windows for each, this naturally creates ring-based patching with zero extra configuration
- Set the Patch Tuesday alignment option in your maintenance schedule to automatically sync your patch window with Microsoft's monthly security release cadence
- Use hotpatching for Windows Server Azure Edition VMs where supported, it applies critical patches without a reboot, which means your maintenance windows only need to handle non-hotpatch updates
Frequently Asked Questions
Why does Azure Update Manager show my VM as compliant when it clearly has missing updates?
This almost always means periodic assessment isn't enabled, so you're looking at stale compliance data from the last manual check, which might have been days or weeks ago. Enable periodic assessment under the machine's update settings in Azure Update Manager, which schedules an automatic compliance check every 24 hours. If you need fresher data right now, hit Check for updates to run an on-demand scan. The compliance status in the dashboard will update within a few minutes of the scan completing.
Do I need Log Analytics or Azure Automation for Azure Update Manager to work?
No, and this is one of the most significant differences between Azure Update Manager and the older Update Management solution in Azure Automation. Azure Update Manager is built as native functionality on Azure VMs and Azure Arc-enabled servers with no dependency on Log Analytics workspaces or Automation accounts. You don't need to set either up, and you don't need to install the MMA or OMS agent. The service works entirely through the VM agent extensions it manages itself.
My Azure Arc machine isn't appearing in Azure Update Manager, what's going on?
Azure Arc connectivity is a hard requirement for Update Manager on non-Azure machines. Start by running azcmagent check on the machine to test connectivity to all required Azure endpoints. If any check fails, that's your root cause, typically a firewall rule or proxy misconfiguration blocking the Arc service URLs on port 443. Once connectivity is restored, trigger any Update Manager operation (like Check for updates) to kick off the dual extension installation that Arc-enabled machines require. Both extensions need to show as successfully provisioned before the machine is fully functional in Update Manager.
Can Azure Update Manager patch machines in multiple Azure subscriptions from one place?
Yes, cross-subscription patching is a supported feature. From a single Update Manager view, you can see and manage machines across multiple subscriptions as long as you have the appropriate RBAC permissions on the target resources. When creating maintenance configurations and dynamic scopes, you can scope them across subscriptions by targeting at the management group level. Just make sure the user or service principal running the operations has the Azure Update Manager Contributor role assigned in each relevant subscription or resource group.
What's the difference between automatic VM guest patching and a scheduled maintenance window in Azure Update Manager?
Automatic VM guest patching is a fully hands-off option where Azure automatically applies critical and security patches to your Azure VMs on a rolling basis within 30 days of release, with no maintenance window required from you. It's great for machines where you just want patches applied without any scheduling overhead. A scheduled maintenance window gives you control, you define exactly when patches are applied, which update classifications are included, and you can set pre/post events to handle things like taking snapshots or notifying teams beforehand. For production environments where timing matters, scheduled windows are the right choice. Automatic guest patching fits better for dev or test machines where you just want updates to happen automatically.
How do I apply only security updates and skip optional updates in Azure Update Manager?
When creating or editing a scheduled update deployment in Azure Update Manager, you get the option to filter by update classification. Under the Updates to include section of the schedule, you can select specific classifications: Critical, Security, Update Rollup, Feature Pack, Service Pack, Definition, Tools, or Updates. Select only Critical and Security to scope the deployment to security-relevant patches only. This same filter applies to on-demand installs, when you click Install one-time update, you can review the list of available updates and manually select or deselect individual patches before confirming the installation.