Entra Connect Health not working: the agent, not the sync

The alert reads Health service data is not up to date. It sits on an Entra Connect server that is synchronising perfectly, the Synchronization Service Manager shows clean run profiles, and nothing on the box looks wrong. Entra Connect Health not working is a reporting fault rather than a sync fault, and reinstalling Entra Connect fixes nothing, because the thing that failed is a separate agent with its own outbound path and its own licence requirement. What follows is the documented list of what blocks that path, in the order worth checking.

It is worth having working. Connect Health is the only monitoring Microsoft provides for a synchronisation product it has already named a successor to, and the Connect Sync deadline and what replaces it sets out what that succession actually commits you to. Every fact below was verified against Microsoft Learn on 18 October 2026, and the dates on those pages are given where they matter.

What the alert measures, and what it does not

The alert is arithmetic, not diagnosis. Microsoft’s Health service data isn’t up to date alert article states that it fires when the service has not received complete data from an agent in the past two hours, and that a background process running every two hours generates and re-evaluates it. Two consequences follow, and both of them waste afternoons.

The first is that a correct fix still looks like a failure. The article is explicit: because the background process runs every two hours, it can take up to two hours for the alert to clear. If you repair a firewall rule and refresh the portal, you learn nothing.

The second is that the severity carries information most people miss. A Warning fires when the Health Service received only partial data types from the server in the last two hours, and a Warning does not trigger email notifications to configured recipients. An Error fires when it received none at all, and that one does email. So a server stuck on Warning can sit broken and silent for months, which is the usual explanation for an alert nobody remembers appearing.

Entra Connect Health not working: the five documented blockers

The agent installation article, last updated 26 May 2026, carries a prerequisites section that reads like a list of reasons the agent will not report. Five of them are easy to have in place by accident.

TLS inspection. The requirement is that TLS inspection for outbound traffic is filtered or disabled, and Microsoft states that registration or data upload operations might fail where there is TLS inspection or termination at the network layer. The same page also asks you not to disable security monitoring of those URLs, which is a narrower instruction than it first appears: allow them, do not intercept them.

Authenticated proxies. Authenticated proxies using HTTPBasic are not supported. Not degraded, not slow. Not supported.

The wrong proxy mechanism. Setting the proxy with netsh WinHttp set ProxyServerAddress is explicitly unsupported, because the agent uses System.Net rather than Windows HTTP Services to make its web requests. An administrator who configured WinHTTP, saw it applied cleanly and moved on has configured something the agent never reads.

Windows Server Core. Server Core does not support installing the Connect Health agent. That is a design decision, not a bug, and it quietly excludes the Core domain controllers that a well-run estate is most likely to have.

Ports. TCP 443 is required. TCP 5671 was required historically, and Microsoft now states that the latest agent version does not need it and that the agent falls back to 443 if 5671 is blocked, while still recommending 5671. An old agent behind a firewall that only ever permitted 443 is a plausible silent failure, and upgrading the agent is the cheaper half of that test.

The Local System trap

This is the one that costs the most time, because the obvious test passes. The connectivity cmdlet runs in whichever account you are signed in as, and that account usually has a working proxy configuration from Internet Options or Windows settings. The agent does not. It runs as Local System, which has its own proxy configuration, and Local System is where the configuration is usually missing.

Microsoft’s troubleshooting article for data freshness alerts makes the point directly: if the user-context test succeeds but all data types are missing, the proxy setting may be correct for the user and not for Local System. The fix is to test in the right context.

1# Tests the outbound path in the account the agent actually runs as, not yours.
2# -Role accepts Sync, ADDS or ADFS. The agent must be registered first.
3Test-AzureADConnectHealthConnectivityAsSystem -Role Sync

And to read the proxy Local System is really using, rather than the one you can see:

1# Opens Windows settings in the Local System context. Then: Network and internet,
2# Proxy, Edit under Manual proxy setup. Restart the agent services afterwards.
3PsExec.exe -i -s "start ms-settings:"

A caution on those cmdlet names, because this is a live inconsistency rather than a typo on my part. The installation article documents the connectivity test as Test-MicrosoftEntraConnectHealthConnectivity, under the renamed product. The troubleshooting article still documents Test-AzureADConnectHealthConnectivity and Test-AzureADConnectHealthConnectivityAsSystem. Both pages are current. Which name your server accepts depends on the agent version installed on it, so if one is not recognised, try the other before concluding the module is broken. A Microsoft Q&A thread titled Test-AzureADConnectHealthConnectivity is not recognized currently ranks on the first page of results for this problem, which suggests the rename catches people regularly.

The licence arithmetic nobody mentions

Connect Health is a feature of Microsoft Entra ID P1 or P2, which most organisations running hybrid identity already have. The part that surprises people is how the entitlement is counted. From the Connect Health FAQ, last updated 15 June 2026: the first registered agent requires at least one P1 or P2 licence, and each additional registered agent requires 25 more.

Agent count is the total across all monitored roles, so AD FS, Connect and AD DS agents are added together. The licences do not have to be assigned to named users: Microsoft states you only need the requisite number of valid licences. That is a different model from almost everything else in the tenant, and it is the opposite of the assignment problem behind most group based licensing errors. If the licence count is what is marginal here, the Entra ID P1 vs P2 licence maths is the calculation to run first, because P1 is sufficient for Connect Health and the per-agent step is the same in both.

The practical effect is that monitoring four domain controllers properly has a licence cost that nobody put in the design document. An organisation of 40 people cannot monitor five servers, because it cannot reach 101 licences.

Why it is just staging mode is the wrong answer

A staging mode Connect server does not export to Entra ID, so the received wisdom is that this alert is expected on staging servers and can be ignored. That answer is repeated in community threads whenever Entra Connect Health not working is raised against a staging box, and it is partly true, which is what makes it expensive.

In the clearest public example I can point at, a Microsoft Q&A thread from mid 2025 about exactly this, the asker was told the warning was expected and normal for staging mode. The status only changed to Healthy after they updated a firewall policy to permit outbound connections to the Service Bus endpoint, and their connectivity test had been failing on port 5671. The alert was not cosmetic. It was correctly reporting a real connectivity fault that happened to be sitting on a staging server.

Those are community posts rather than an official Microsoft statement, and I am treating them as a reported case rather than documentation. But the asymmetry is worth taking seriously. If you accept the staging mode explanation and the real cause is a blocked endpoint, you have accepted a broken agent on the server you intend to promote during an incident. The cost of being wrong in that direction is much higher than ten minutes with the connectivity test.

The failure modes

A decommissioned server that still alerts. Removing an agent does not remove the server from the Connect Health portal. Microsoft’s FAQ states that if you manually remove an agent, or remove the server itself, you have to delete the server entry from the portal by hand, and that deleting monitored servers requires Global Administrator permissions or the Contributor role in Azure role-based access control. A stale entry has no agent, so it reports no data, so it alerts forever. This is the most common false positive in the product.

Missing performance counters. If the counter categories the agent reads do not exist, there is nothing to upload and the data type simply never arrives. All four of these must return True.

1# Any False here explains a missing PerfCounter data type on its own.
2[System.Diagnostics.PerformanceCounterCategory]::Exists("Processor")
3[System.Diagnostics.PerformanceCounterCategory]::Exists("TCPv4")
4[System.Diagnostics.PerformanceCounterCategory]::Exists("Memory")
5[System.Diagnostics.PerformanceCounterCategory]::Exists("Process")

One service stopped, one data type gone. The data types map to different services. PerfCounter comes from the Connect Health Sync Monitoring Service. The AadSyncService data types, which cover connectors, run profile results and service configuration, come from the Sync Insights Service. A single stopped service produces a partial upload, which produces a Warning, which does not email anyone.

A short memory, not a long one. When the agent cannot reach Azure it caches locally, in roughly 20 MB of buffer. That is a buffer, not an archive. A long outage does not backfill once connectivity returns.

The sync error report is not the health agent. The object level synchronisation error report is updated every 30 minutes and requires Entra Connect 2.5.79.0 or higher. Separately, if Entra Connect is not using the default configuration, custom attribute filtering being the example Microsoft gives, the agent will not upload Connect error events at all and the portal shows a banner saying so. Monitoring then has to be switched on explicitly in the sync service settings. A server can therefore be perfectly healthy, correctly licensed and still show an empty error report.

What I would do differently

I have not run a Connect Health agent behind an inspecting proxy in production. My tenant is a lab and there is no on-premises estate behind it, so everything above is what Microsoft documents plus one public incident, and I have said which is which. What I would change is the order of work, because the documentation implies a different one.

Test in the Local System context first, before reading any log. Most of the documented blockers are network configuration, the user-context test passes under all of them, and the AsSystem variant separates a real connectivity fault from everything else in about a minute.

Then decide what you are actually monitoring, before registering a third agent. The 25 licence step means the honest answer for a lot of organisations is one agent on the Connect server and nothing else, and one monitored server with a working agent beats five with alerts nobody reads. The failure discipline is the same one that applies to a hybrid join that is not working: find the phase that is failing before changing anything, because every component in the chain reports success right up to the one that does not.

The thing I would push back on hardest is treating a Warning as informational. Microsoft has written down that it does not email anyone. On a server in staging mode, which is the server you least often look at and the one you promote under pressure, a silent Warning is the exact shape of a problem you find at the worst moment.

Last verified: 18 October 2026