DCR randomly stopped sending data to log analytics workspace, AMA issue

Question

Since around February my DCR stopped sending custom logs to Log Analytics workspace, recently I went back to it and noticed that one VM again started sending this data, but in DCR resources there are 14 VMs. The rule is custom performance counter \LogicalDisk(_Total)% Free Space , so we could create alerts based on it that inform us if and disk passes 95% threshold. I tried deleting AzureMonitorWindowsAgent an reinstalling it from power shell and by readding VMs to DCR, I also created new DCR but it didn't worked. It also changed in my monitor, now those VMs are listed as not monitored and some( about 7) have "Cannot enable - Unable to determine if OS is supported" even though nothing really changed in them and before they did not have that problem. Strangely the VM that started sending logs back still lists as " not monitored" in monitor, but its agent sends heartbeat to log analytics and is visible in agents.

All VMs have AzureMonitorWindowsAgent with status Provisioning succeeded, I also tried changing DCR rule to default rules and changing destination but nothing works.

Answer 1

Hello PawelD

Thank you for posting your query on Microsoft Q&A platform.

It sounds like your Data Collection Rule is heart-beating fine but your custom “% Free Space” performance counter isn’t flowing from most of your VMs.

Please have a look into below provided checklist you can run through:

1. Confirm you’re on the latest AMA extension:

• In the portal, go to each VM’s Extensions blade and enable automatic upgrades for AzureMonitorWindowsAgent.

• If a VM shows “transitioning” or “corrupted,” RDP in, delete the registry key

HKLM\SOFTWARE\Microsoft\AzureMonitorAgent\Secrets\PersistenceKeyCreated

then restart the AzureMonitorAgent service.

• Failing that, remove and reinstall via PowerShell:

#Remove 
Remove-AzVMExtension -ResourceGroupName RG -VMName MyVM -Name AzureMonitorWindowsAgent -Force

# Reinstall
Set-AzVMExtension -ResourceGroupName RG -VMName MyVM -Name AzureMonitorWindowsAgent `
  -Publisher Microsoft.Azure.Monitor -Type AzureMonitorWindowsAgent -TypeHandlerVersion 1.0 `
  -EnableAutomaticUpgrade $true

2. Verify your DCR configuration & VM associations :

• In Azure Portal → Monitor → Data Collection Rules → select your DCR → VM associations

• Make sure all 14 VMs are listed, in the same region as your Log Analytics workspace and (if used) your Data Collection Endpoint.

3. Validate the counter locally On each affected VM, run the below command:

Get-Counter '\LogicalDisk(_Total)\% Free Space'

You want a valid output there with no errors, if that fails, the counter path is wrong or missing.

4. Turn on DCR diagnostics & metrics:

• In your DCR’s Diagnostic settings, send allLogs to a Log Analytics workspace.

• Query the DCRLogErrors table:

DCRLogErrors
| where _ResourceId contains "your-dcr-name"

Look for transformation or ingestion errors.

• In Metrics Explorer, plot Logs Rows Dropped per Min to see if rows are being filtered or dropped.

5. Check network & proxy rules:

Even though heartbeats are passing, confirm there’s no NSG or firewall blocking port 443 to:

• *.monitor.azure.com

• *.ods.opinsights.azure.com

From each VM: Run below commands: If you use private endpoints or a proxy, make sure the AMA traffic (“Arc,AMA”) is bypassed.

Test-NetConnection monitor.azure.com -Port 443
Test-NetConnection <yourRegion>.ods.opinsights.azure.com -Port 443

6. Investigate the “Cannot enable – Unable to determine if OS is supported” message :

• Verify your Windows Server build/version is in the supported list for AMA.

• If these VMs were deployed from a custom image or clone, clear out old persistence keys (see step 1) so each VM reports uniquely.

**7. **Validate ingestion in Log Analytics:

After making changes, wait 5–10 minutes then run: You should see recent timestamps for all your VMs.

Perf
| where TimeGenerated > ago(15m)
| where CounterName == '% Free Space'
| summarize Last = max(TimeGenerated) by Computer

If you still don’t see data, can you share:

• The exact AzureMonitorWindowsAgent version on a working VM vs a non-working VM

• The OS build/version of your VMs

• Any errors you find in the DCRLogErrors table

• The “Logs Rows Dropped per Min” metric for your DCR

• Confirmation that your workspace, DCR and DCE (if used) are all in the same Azure region

That info will help narrow down the root cause. Hope this helps!\

Thanks,

Suchitra.

Answer 2

Use a structured check of the Azure Monitor agent (AMA), the DCR, and the workspace to isolate why only one VM is sending data.

1. Verify AMA health on each VM
   • On each Windows VM, confirm the extension state:
     • Azure portal → VM → Settings → Extensions + applications → AzureMonitorWindowsAgent must show Provisioning succeeded.
     • If not, follow the basic AMA troubleshooting steps for Windows VMs:
       • Check extension logs on the VM at:
         • C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent
       • If errors persist, uninstall and reinstall the extension, then re-check status.
   • Confirm the core agent is actually running:
     • Run a Heartbeat query in the Log Analytics workspace:

              Heartbeat
              | where Category == "Azure Monitor Agent"
              | where Computer == "<computer-name>"
              | take 10
       

     • If no heartbeat:
       • On the VM, open Task Manager and verify MonAgentCore.exe is running.
       • If not running, check core agent logs at:
         • C:\WindowsAzure\Resources\AMADataStore.<virtual-machine-name>\Configuration
       • Fix any errors indicated there (for example, connectivity to Azure Monitor endpoints or configuration download failures).
2. Confirm DCR existence and association for each VM
   • A VM can show as “not monitored” if the DCR is missing, in the wrong region, or not associated.
   • For each VM:
     • In Azure portal → Monitor → Data Collection Rules:
       • Confirm the DCR exists and is in the same physical region as the Log Analytics workspace.
       • On the Resources tab, verify the VM is listed and associated with the DCR.
   • If migrating from logs-based VM insights to OpenTelemetry metrics, ensure that any logs-based DCR association removal has not unintentionally removed the DCR needed for the custom performance counter. If a logs-based DCR was removed, recreate or re-associate the appropriate DCR and confirm that InsightsMetrics or the custom counter data resumes.
3. Validate the DCR content for the custom performance counter
   • Ensure the DCR actually defines collection of the custom performance counter \LogicalDisk(_Total)\% Free Space and that the destination is the correct Log Analytics workspace.
   • If the DCR was recreated, confirm:
     • The rule includes the performance counter section.
     • The target resource type and OS type match the VMs.
4. Check for workspace-level ingestion issues
   • If data stopped around a specific date for many VMs, verify the Log Analytics workspace is not blocking ingestion due to daily cap:
     • Run in the workspace:

              Operation
              | where OperationCategory == 'Data Collection Status'
       

     • If OperationStatus shows Warning around the time data stopped, the daily cap may have been reached. Increase the daily cap or wait for reset; data collection resumes after reset.
5. Address “Cannot enable – Unable to determine if OS is supported”
   • This status in Monitor usually indicates Monitor cannot correctly detect OS details or compatibility for AMA/VM insights, even if the agent is technically installed.
   • Since AMA is installed and shows Provisioning succeeded, focus on:
     • Ensuring the VM is correctly registered as a supported resource type and region.
     • Verifying that the DCR is associated and that AMA can reach the Azure Monitor Configuration Service (AMCS) to download configuration.
   • The fact that one VM sends data but still shows “not monitored” suggests a UI/monitoring configuration mismatch: the agent and DCR are working, but the VM is not associated with the expected “monitoring” DCR or VM insights configuration. Confirm the VM is associated with the correct DCR used by Monitor for that workspace.
6. Compare a working VM vs non-working VMs
   • On the VM that is sending data:
     • Note the exact DCR(s) associated with it.
     • Confirm the AMA logs show successful configuration download and data upload.
   • On a non-working VM:
     • Ensure the same DCR is associated.
     • Compare AMA logs and configuration files under C:\WindowsAzure\Resources\AMADataStore.<virtual-machine-name> to identify differences (for example, missing configuration, failed AMCS calls, or different workspace IDs).

These checks will isolate whether the issue is with AMA health, DCR association/region, DCR content (performance counter definition), or workspace ingestion limits.

---

References:

• Troubleshooting guidance for the Azure Monitor agent on Windows virtual machines and scale sets
• Troubleshoot why data is no longer being collected in Azure Monitor
• Migrate from logs-based to OpenTelemetry metrics for Azure virtual machines