When Azure Change Tracking Goes Silent: My Debugging Journey

After enabling the Change Tracking and Inventory agent on one of my Windows VMs, I expected to see a nice stream of inventory data showing up in the Azure portal. Instead, I was greeted with… nothing. No inventory data, no configuration updates—just a quiet portal and a suspicious feeling that something had gone wrong.

Digging into the agent logs confirmed my suspicion. Here’s what I saw:

time="2025-09-23T15:23:03Z" level=info msg="Agent Process got the configFolder C:\\Packages\\Plugins\\Microsoft.Azure.ChangeTrackingAndInventory.ChangeTracking-Windows\\2.35.0.0. \n"
time="2025-09-23T15:23:03Z" level=error msg="socket/pipe Error while sending request data"
time="2025-09-23T15:23:03Z" level=error msg="Error while reading settings  open \\\\.\\\\pipe\\\\CAgentStream_CloudAgentInfo_AzureMonitorAgent: The system cannot find the file specified."
time="2025-09-23T15:24:03Z" level=error msg="Failed to find an output stream for CONFIG_CHANGE_BLOB"
time="2025-09-23T15:24:03Z" level=error msg="Error sending kusto telemetry data through output handler."

That “pipe not found” error immediately stood out. It looked like the Change Tracking agent was trying to send data to the Azure Monitor Agent (AMA), but couldn’t reach it. Essentially, the Change Tracking agent depends on the AMA to send telemetry to Azure—but if that communication channel fails, all the data just… stalls.

To understand what was going on, I stumbled upon a great deep dive by Lucas Lifes: Deep Dig into Windows Change Tracking and Inventory with Azure Monitor Agent. It explains beautifully how the Change Tracking extension feeds its configuration and telemetry through the AMA. This gave me a clue: maybe the problem wasn’t with Change Tracking itself, but with the Monitor Agent underneath it.

Sure enough, when I checked the AMA logs under
C:\WindowsAzure\Resources\AMADataStore.test-vm0\Configuration,
I found this gem:

Info (2025-10-06T10:01:13Z): MonAgentManager.exe - Non-success status code from IMDS for MSI token with default identity. 
URI [/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://monitor.azure.com/], 
Status code=400, response [{"error":"invalid_request","error_description":"Identity not found"}]

There it was. The AMA was failing to get an MSI (Managed Service Identity) token from the Azure Instance Metadata Service (IMDS). Without a valid identity, it couldn’t authenticate to Azure Monitor, and without authentication, it couldn’t send data.

In plain terms:

Change Tracking was trying to push its telemetry.
AMA was supposed to handle that transmission.
AMA couldn’t talk to Azure because it had no identity.
Therefore, no data appeared in the portal.

The fix came from another excellent write-up by Ramana Reddy. The solution was to ensure the VM has a system-assigned or user-assigned managed identity enabled, and that the Azure Monitor Agent is allowed to use it. Once that was configured properly, the errors vanished, and the inventory data started flowing in as expected.

It’s a small but classic example of how Azure agents rely on a daisy chain of dependencies—one missing link, and the whole system quietly fails. The key takeaway?
When your Change Tracking data doesn’t show up, don’t just look at the extension. Follow the pipes—literally. The problem might be sitting one layer below, in your monitor agent’s authentication chain.

Next time you enable Change Tracking and Inventory, double-check that your VM has a valid managed identity and that Azure Monitor Agent can use it. It’ll save you a few hours of log spelunking.