Azure Update Manager Says "No Update Data"? Here's What I Learned After Breaking (and Fixing) It

Infrastructure changes have a way of producing unexpected side effects! (a.k.a. gather around for another lively lesson learned the hard way...)

Sometimes it's a routing issue that doesn't surface until something tries to use the affected path. Sometimes it's a service dependency that nobody documented because it always just worked. And sometimes it's discovering that cloud management platforms don't automatically resume where they left off after you've changed the environment underneath, even when every status indicator says otherwise.

The scenario I'm walking through here comes up more often than you'd expect: networking changes are made in a hybrid Azure environment (new routes, updated firewall rules, revised NSG configs, or just general infrastructure cleanup) and everything comes back online cleanly. Or at least, that's what it looks like at first.

The Arc-connected Windows Servers show as Connected in the portal, so heartbeats are flowing. The relevant status indicators are there and seem to highlight that things should be working, but then you open Azure Update Manager and it says No Update Data. Not "updates available." Not "assessment failed" with a red icon you can dig into. Just nothing. It's a blank slate where patch status and update history are supposed to live.

If you're here after making network changes, rebuilding a server, restoring from backup, or recovering an Arc-enabled machine after some kind of failure, this is the exact scenario. What follows is the troubleshooting sequence in the order it should actually be performed, because the order of operations matters far more than most guides seem acknowledge.

The Misconception That Wastes Your First Hour

Before getting into the steps, it's worth addressing the assumption that burned me initially. I (incorrectly) assumed Azure Update Manager continuously inventories updates as long as the machine is online and Arc-connected. That felt reasonable. The machine is connected, Azure can see it, so updates should naturally flow. Right? That's unfortunately not how it works.

Several distinct pieces have to align before update information appears in the portal:

• The Azure Connected Machine agent has to be healthy (not just present)

• Azure has to be receiving regular heartbeats on schedule

• The Windows Update service stack has to be functioning normally on the VM

• An update assessment has to successfully complete and report results

• Azure has to ingest and publish those assessment results before they appear

Think of connectivity is the foundation, not the whole building. Think of Azure Arc as telling Azure "I'm alive and I can be reached." That's the heartbeat side of the relationship. Azure Update Manager is a separate conversation that has to then ask "Great, now what updates do you have installed, and what's available for you?" Those two conversations happen on different schedules through different mechanisms. When networking changes disrupt one, the other doesn't automatically catch up just because the first one recovered.

The Connected status you see in the portal reflects the heartbeat conversation. It says nothing about whether the assessment pipeline recovered as well.

Step 1: Confirm Azure Arc Is Actually Healthy, Not Just Connected

This distinction matters more than it sounds. "Connected" in the portal means the heartbeat is flowing. "Healthy" means the agent is fully operational and capable of running extensions and assessments.

Type this from an elevated PowerShell prompt:

azcmagent check

This runs a series of connectivity and health checks against the agent and its dependent services. Ideally, every check comes back healthy.

If it doesn't, stop here and solve those issues first. Update Manager depends on Arc being fully operational, not just showing a Connected status. A partially recovered agent can send heartbeats while still failing at extension execution, which is exactly the kind of thing that produces a persistent "No Update Data" state with no obvious error.

You can also get a broader view of agent state:

azcmagent show

This gives you details on agent version, resource group association, tenant, and connectivity mode. Anything unexpected here (wrong tenant, disconnected state that doesn't match the portal) is worth investigating before moving forward.

Step 2: Verify the Windows Update Stack Is Functional

This step sounds obvious but networking changes can quietly introduce DNS, proxy, or outbound firewall issues that the Windows Update stack tolerates until it actually needs to scan. Then it fails ever so silently, and Azure Update Manager has nothing to report because Windows itself couldn't complete an assessment.

First, check that the core services are running:

Get-Service HIMDS
Get-Service wuauserv
Get-Service UsoSvc

The HIMDS service is the Azure Instance Metadata Service for hybrid machines, and it's the bridge between the Arc agent and Azure's management plane. The wuauserv and UsoSvc services are the Windows Update and Update Orchestrator services respectively. All three should be running.

Then force a Windows Update scan manually:

UsoClient StartScan

If Windows itself can't discover updates due to a broken update stack or blocked outbound connectivity to Microsoft Update endpoints, Azure Update Manager won't fix that from the cloud side. The assessment data has to originate from a successful local scan. Azure is consuming and displaying those results, not generating them independently.

Step 3: Trigger a Fresh Assessment from the Portal

This is the step that actually resolved my issue, and it's the one that's easiest to skip because it requires going into the Azure portal rather than running a command.

Inside Azure Update Manager, navigate to your machine and manually trigger an assessment. This is different from waiting for the next scheduled assessment window.

A healthy machine that's recovering connectivity doesn't automatically run a new update inventory the moment the Arc agent reconnects. Azure's assessment pipeline runs on its own schedule, and after a networking disruption, that schedule may not align with when you're looking at the portal and expecting data to appear.

Triggering a manual assessment explicitly asks Azure to initiate the assessment cycle right now instead of waiting for the next scheduled window. After triggering it, give it 10 to 30 minutes before concluding it failed. Update Manager isn't real-time, and metadata publication has its own latency. Checking back two minutes later and seeing nothing doesn't mean it didn't work.

Step 4: Verify Azure Can Actually Reach the Required Endpoints

Since my issue started after networking changes, outbound connectivity from the VM to Azure's management endpoints was the next thing I validated. Arc being connected doesn't mean every required endpoint is reachable, because Arc uses a relatively small set of endpoints while Update Manager and Guest Configuration depend on additional ones.

These tests verify access to the critical services:

Test-NetConnection login.microsoftonline.com -Port 443
Test-NetConnection management.azure.com -Port 443
Test-NetConnection guestconfiguration.azure.com -Port 443

Failures here usually trace back to one of a few causes:

• DNS resolution broken at a specific endpoint (partial DNS failure is common after route changes)

• Firewall rules that weren't updated alongside the network changes

• Proxy configuration that's no longer correct for the new network path

• Missing or incorrect routes in the routing table

• NSG rules blocking outbound traffic on Azure-side resources

• Custom outbound filtering that's more aggressive than intended

If any of these tests fail, that's likely your root cause. The assessment pipeline can't complete if Azure's management plane can't be reached during the assessment cycle, even if heartbeats are flowing through a different code path.

The full list of required endpoints for Arc-connected machines is documented in the Azure Arc network requirements, and it's worth reviewing that list against your firewall ruleset if you made significant networking changes.

Step 5: Restart the Azure Arc Agent Services

Sometimes the Arc agent simply needs a fresh start after a networking disruption. Even if azcmagent check shows everything healthy, the agent may be in a state where it's passing health checks but not functioning correctly for extension operations.

Restart-Service HIMDS

Or if you want to reference the full service name:

Restart-Service AzureHybridInstanceMetadataService

Give Azure a few minutes to re-establish the connection after the service restarts before checking Update Manager again. The reconnection process isn't instantaneous, and checking immediately after the restart will just show you the same blank state.

Step 6: Read the Logs Before Assuming the Worst

If everything above looks healthy but update data still refuses to appear, it's time to go past what the portal is telling you and look at what the agent itself is reporting. The Azure Connected Machine Agent logs live here on the VM:

C:\ProgramData\AzureConnectedMachineAgent\Log\

The files worth focusing on first are himds.log and extensionhandler.log. You're looking for patterns like repeated failed heartbeats, extension download failures, authentication errors against Entra ID, or continuous retry loops that suggest something is stuck in a broken state rather than actually recovering.

These logs are frequently much more informative than the Azure portal. The portal shows you summarized status. The logs show you what's actually happening, including failures that the portal doesn't surface in any obvious way. An authentication failure that's causing assessment extensions to fail silently will show up in the logs before it ever produces an actionable error in the portal. Guest configuration logs in the same directory are also worth checking if you're seeing policy compliance issues alongside the Update Manager problem, since the same agent infrastructure serves both.

Step 7: Remove and Reinstall the Update Manager Extension

If the Arc agent is healthy, Windows Update works, networking is validated, manual assessments have been triggered, and the assessment still never populates after 30 to 60 minutes, the Update Manager extension itself may be in a stuck or corrupted state.

In the Azure portal, navigate to your Arc-connected machine, go to Extensions, and remove the Azure Update Manager extension (it appears as MicrosoftWindowsUpdate or similar depending on the OS). Once removed, you can reinstall it either through the portal or by triggering an assessment again, which will prompt Azure to reinstall the extension.

Removing and reinstalling forces Azure to rebuild the assessment pipeline from scratch for that machine. The extension re-registers, re-authenticates, and runs an initial assessment as part of the installation process. It's not the first thing to try because it takes time and introduces a window where the machine has no update coverage, but it's frequently what finally resolves persistent blank-state issues where nothing else has worked.

The Broader Lesson: Connection Status and Operational Status Are Not the Same Thing

This whole experience reinforced something that's easy to overlook when working with layered cloud management platforms:

When Azure Arc shows a machine as Connected, that's a statement about the heartbeat channel. It means Azure can send commands to the machine and receive acknowledgment that it's alive. It doesn't mean every management service that runs through that connection has resumed where it left off.

Update Manager, Azure Monitor, Defender for Cloud, Guest Configuration, Policy compliance, Change Tracking, and Inventory all have their own pipelines. Each one has its own extension, its own assessment schedule, its own state machine, and its own recovery behavior after a disruption. A networking change that takes the machine offline for 20 minutes might not affect the heartbeat at all once it recovers, while leaving half a dozen management extensions in a state that requires manual intervention to unstick.

When you make networking changes in a hybrid environment, especially where you're making changes more freely than you would in production (lab, testing, etc.), the connected status should be your starting point, not your ending point. Go through each management service you care about and verify that it actually recovered operationally, not just that the underlying connection shows as healthy.

The Arc agent and the VM were perfectly fine. Azure was perfectly fine. They just needed to be reintroduced to each other through the specific handshake that Azure Update Manager requires, and that handshake doesn't happen automatically just because the heartbeat recovered.

Sometimes the fix is as simple as triggering one manual assessment and waiting. Other times it takes working through all seven steps in order as well. But starting with the assumption that Connected means everything is working will reliably send you in the completely wrong direction. Trust me... ;)