Fix Sentinel Data Connector "Disconnected" & No Data Received (AMA/DCR)

A Microsoft Sentinel data connector reports that nothing is arriving:

Status: Disconnected
Data received: No data received in the last 14 days

The connector was configured, the agent appears to be deployed, and the workspace is healthy — but the tables stay empty. This guide works through the causes in the order they are most likely.

Why This Happens

Connector status is derived from whether data has actually arrived, not from whether you completed the configuration wizard. So a connector showing Disconnected is telling you the pipeline is broken somewhere between the source and the workspace, without telling you where.

For anything built on Azure Monitor Agent, that pipeline has four links, and a break in any one produces the same silent symptom:

1. The agent is installed and running on the source machine.
2. A Data Collection Rule exists and is associated with the machine, defining what to collect and where to send it.
3. The DCR and the workspace are in the same region.
4. The agent's identity has permission to write to the workspace.

Notably, three of those four fail quietly — no error appears in the portal, and the deployment reports success.

Fix 1: Check the Heartbeat Table First

This is the fastest way to split the problem in half. Azure Monitor Agent emits a heartbeat automatically once per minute, so its absence is definitive.

In Logs on the workspace, run:

Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastHeartbeat = max(TimeGenerated) by Computer, Category, Version
| order by LastHeartbeat desc

If the machine appears, the agent is alive and authenticated, and the workspace is reachable. Your problem is collection configuration — skip to Fix 3.

If the machine is missing, AMA is not operational on that host. Continue with Fix 2.

To see which machines you expected but are not reporting:

Heartbeat
| where TimeGenerated > ago(24h)
| summarize LastSeen = max(TimeGenerated) by Computer
| where LastSeen < ago(1h)
| order by LastSeen asc

Fix 2: Confirm the Agent Is Running

On a Windows machine, check that the core agent process is running:

Get-Process MonAgentCore -ErrorAction SilentlyContinue

If MonAgentCore.exe is not running there will be no heartbeat and no logs. Check the core agent logs for the failure reason:

C:\WindowsAzure\Resources\AMADataStore.<virtual-machine-name>\Configuration

On Linux, check the agent service:

sudo systemctl status azuremonitoragent
sudo journalctl -u azuremonitoragent --since "1 hour ago" | tail -50

Then confirm the network path. AMA must reach Azure Monitor endpoints over TCP 443; a firewall or proxy blocking that causes a silent failure with no heartbeat and no portal error:

# From the source machine
curl -v https://global.handler.control.monitor.azure.com 2>&1 | head -20

In restricted networks, the supported approach is an Azure Monitor Private Link Scope rather than broad egress rules.

Fix 3: Verify a DCR Exists and Is Associated

This is the single most common cause of a connector showing disconnected: no Data Collection Rule is associated with it. The agent can be perfectly healthy and still collect nothing, because the DCR is what tells it what to gather and where to send it.

Check in the portal under Monitor → Data Collection Rules:

• Does a DCR exist for this data type?
• Under Resources on that DCR, is the source machine actually listed?
• Under Data sources, are the facilities, event logs or severities you expect included?

Or from the CLI:

# List DCRs in a resource group
az monitor data-collection rule list --resource-group <rg> --output table

# List associations for a specific machine
az monitor data-collection rule association list \
  --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>" \
  --output table

A DCR that exists but has no association with the machine is functionally the same as no DCR at all.

Fix 4: Check the Region Match

A Data Collection Rule and its target Log Analytics workspace must be in the same region. A mismatch prevents ingestion entirely, and nothing in the portal flags it — the configuration simply looks right.

# Workspace region
az monitor log-analytics workspace show \
  --resource-group <rg> --workspace-name <workspace> \
  --query location --output tsv

# DCR region
az monitor data-collection rule show \
  --resource-group <rg> --name <dcr-name> \
  --query location --output tsv

If they differ, create a new DCR in the workspace's region and re-associate the resources. A DCR cannot be moved between regions.

Fix 5: Check the Managed Identity Permissions

The system-assigned managed identity used by Azure Monitor Agent needs Log Analytics Contributor on the target workspace. Without it, AMA installs cleanly and sends zero data — a failure mode that looks identical to a network problem but has nothing to do with the network.

# Confirm the VM has a system-assigned identity
az vm identity show --resource-group <rg> --name <vm> --output json

# Check role assignments on the workspace
az role assignment list \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace>" \
  --output table

Grant it if missing:

az role assignment create \
  --assignee <principal-id> \
  --role "Log Analytics Contributor" \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace>"

Fix 6: Syslog and CEF — Connected but Missing Events

A connector can report as connected while specific event types never arrive. On a Linux forwarder, confirm the local daemon is actually forwarding to the agent:

# Which syslog daemon is running
sudo systemctl status rsyslog syslog-ng 2>/dev/null | head -20

# Confirm the Azure Monitor forwarding configuration is present
ls -la /etc/rsyslog.d/ | grep -i azure

# Watch messages arriving on the forwarder
sudo tail -f /var/log/syslog

Then confirm the DCR includes the facilities and severities you expect. Collecting auth at info and above will never surface a local4 debug message, no matter how healthy the connector looks.

Verify the Fix

1. Confirm heartbeat has resumed for the machine using the Heartbeat query above.
2. Query the destination table directly rather than trusting the connector tile:

Syslog
| where TimeGenerated > ago(30m)
| summarize count() by Computer, Facility
| order by count_ desc

3. Allow 90 to 120 minutes for the connector page to reflect a healthy state — the tile lags the data.
4. Confirm the analytics rules that depend on this table are still evaluating, and back-check whether the outage created a detection gap in the period the data was missing. See creating analytics rules for reviewing rule coverage.

That last point matters more than the connector tile turning green: a connector that was disconnected for two weeks means two weeks in which those detections could not fire.

Prevention

• Deploy DCRs as code. Templates or Bicep prevent the association and region mistakes that cause most of these failures, and make them reviewable.
• Alert on missing heartbeats rather than discovering silence at audit time. A scheduled rule on machines absent from Heartbeat for over an hour catches this within the hour.
• Standardise regions. Keeping workspaces and DCRs in a small, documented set of regions removes an entire class of silent failure.
• Grant Log Analytics Contributor as part of onboarding, not as an afterthought when data is missing.
• Document expected tables per connector, so you can tell the difference between "connected" and "collecting what we actually need".
• Do not recreate connectors as a first response. It loses configuration and creates a real coverage gap while you rebuild.

Related Guides

• How to connect data sources to Microsoft Sentinel
• How to create analytics rules in Microsoft Sentinel
• How to investigate incidents in Microsoft Sentinel