Resolve Data Freshness Alerts in Azure AD Connect Health: A Troubleshooting Guide

Updated: 05 Jul, 2025 • 0 • min read

Table of Contents

This guide provides common diagnostic and resolution steps for the data freshness alert titled “Health service data is not up to date.” This alert triggers when the Microsoft Entra Connect Health Service in the cloud has not received data from its agents installed on your on-premises servers for a period exceeding two hours. Such delays can hinder your ability to monitor the health and performance of your identity infrastructure accurately.

The data freshness alert is relevant for the Health Service components monitoring the following crucial identity services:

Azure AD Sync service (Microsoft Entra Connect Sync)
Microsoft Entra Domain Services (managed domain service in Azure, though agents are on domain controllers)
Active Directory Federation Services (AD FS)

Understanding the state of data flow from your on-premises infrastructure to the Azure portal is essential for maintaining a reliable hybrid identity environment. When this flow is interrupted or delayed, it can obscure potential issues within your Sync engine, domain controllers, or AD FS servers that Azure AD Connect Health is designed to highlight proactively. Resolving these freshness issues ensures you have the most current insights into your system’s health.

Prerequisites for Troubleshooting¶

Before diving into the troubleshooting steps, ensure you have the necessary components and tools installed or available. These prerequisites are fundamental for the data collection and diagnostic processes described later in this guide.

Microsoft Entra Connect: This is required if you are monitoring the Azure AD Sync service. Ensure the latest version is installed and configured correctly.
Microsoft Entra Connect Health agent for AD DS: This agent must be installed on your domain controllers if you are monitoring Active Directory Domain Services.
Microsoft Entra Connect Health agent for Active Directory Federation Services: This agent is necessary if you are monitoring AD FS. It should be installed on your AD FS and Web Application Proxy servers.
PsExec tool: This Sysinternals tool is invaluable for executing commands, including troubleshooting commands and accessing system contexts, remotely on the monitored server. Download it from the Microsoft Sysinternals website.

Ensure that the service accounts running the Azure AD Connect Health agents have the necessary permissions on the local server to collect performance counters, read event logs, and access other required data sources. Network connectivity from the monitored server to the required Azure endpoints is also a critical underlying requirement.

Identifying the Data Freshness Alert¶

To confirm and view the details of the data freshness alert within the Azure portal, follow these steps. This process will help you identify which specific service and server are affected by the alert.

Access the Azure portal.
In the search bar at the top, search for and select Microsoft Entra Connect Health.
On the Microsoft Entra Connect Health | Quick start menu pane, navigate to the section corresponding to the service experiencing the issue (e.g., select AD DS Services for domain controllers).
Select the specific domain name or service instance that is showing an alert.
In the subsequent pane for the selected service, select Alerts.
Review the list of active alerts. Locate and select the Health service data is not up to date alert.
On the alert details pane, you will see a list of affected servers. Select the Server Name that is reporting the data freshness issue. This action will display detailed properties, including Alert Details and Data Type Details, providing more context about which specific data types might be missing or outdated.

Understanding the exact scope of the alert—which service, which server, and potentially which data types—is the first crucial step in diagnosing the root cause. Note down the server name(s) for subsequent troubleshooting steps.

Troubleshooting Azure AD Connect Health

Common Diagnostic Steps¶

Before delving into specific component troubleshooting, consider these general diagnostic steps. These often address common underlying causes for data transmission issues and can quickly resolve the alert.

First and foremost, verify the operational status of the Azure AD Connect Health agent services on the affected server. There are typically monitoring, insights, and potentially diagnostics services associated with the Health agent for each service type (Sync, AD DS, AD FS). Ensure these services are running and configured for automatic startup. Restarting these services can sometimes resolve temporary glitches or communication breakdowns.

Check basic network connectivity from the server to the internet and specifically to Azure endpoints. Firewall restrictions, either local Windows Firewall or corporate network firewalls, can block outbound connections required by the Health agents. The agents need to be able to communicate with the Azure AD Connect Health service endpoints over HTTPS (port 443). Use tools like Test-NetConnection or ping (if DNS resolution is the concern) to verify connectivity to a known external address or specifically to Azure endpoints if they are known. Consult the Azure AD Connect Health documentation for the specific endpoint URLs required for agent communication.

Examine the server’s event logs for any errors or warnings related to the Azure AD Connect Health agent services. Look in the Application and System logs, as well as any custom logs created by the Health agent installers. These logs can provide valuable clues about why the agent might be failing to collect or transmit data, such as permissions errors, configuration issues, or transient network problems. Correlate event timestamps with the time the data freshness alert began.

Ensure the server has sufficient resources (CPU, memory, disk space). While unlikely to cause a complete data freshness alert unless the server is severely resource-constrained, resource contention can sometimes impact background service operations like data collection and transmission. Check the server’s performance metrics using Task Manager or Performance Monitor.

Verify that the time is synchronized correctly on the server. Significant time drift can cause authentication failures or prevent successful communication with cloud services that rely on accurate timestamps. Configure the server to synchronize its time with a reliable time source, such as a domain controller or a public NTP server.

If the issue persists after these initial checks, proceed to the more specific troubleshooting sections below, focusing on potential HTTP proxy configurations, performance counter issues, or problems with specific data types.

HTTP Proxy Troubleshooting Steps¶

HTTP proxies are common in corporate environments and can often interfere with cloud service connectivity if not configured correctly, especially when services run under the Local System context. If your environment uses an HTTP proxy for internet access, follow these detailed steps to diagnose and resolve potential connectivity issues affecting the Health agents.

SSL Inspection (TLS Interception): If your proxy performs SSL inspection, it might intercept and re-encrypt the secure communication between the Health agent and Azure endpoints. Ensure that the required Azure AD Connect Health service endpoints are excluded from SSL inspection (added to an allow list or bypass list) on your proxy appliance. A crucial endpoint often requiring exemption is policykeyservice.dc.ad.msft.net, but other service-specific endpoints may also need to be bypassed. Consult Microsoft documentation for a comprehensive list of required URLs and ports for Azure AD Connect Health communication.
Testing Connectivity from the System Context: While network connectivity might work for a logged-in user, the Health agent services typically run under the Local System account, which might have different proxy settings or permissions. Use the Test-AzureADConnectHealthConnectivityAsSystem cmdlet to check connectivity from the perspective of the Local System account.

Open PowerShell as an administrator and run the appropriate command based on the affected service role:
- For Azure AD Sync:
```
Test-AzureADConnectHealthConnectivityAsSystem -Role Sync
```
- For Microsoft Entra Domain Services (monitoring AD DS):
```
Test-AzureADConnectHealthConnectivityAsSystem -Role ADDS
```
- For Active Directory Federation Services (AD FS):
```
Test-AzureADConnectHealthConnectivityAsSystem -Role ADFS
```
This cmdlet tests connectivity to the necessary endpoints and should report any issues encountered, such as proxy authentication failures or blocked connections. If this test fails while a test run under your user context succeeds, it strongly indicates a proxy configuration problem for the Local System account.
Checking and Configuring System Proxy Settings: The Local System account does not use the same proxy settings as a logged-in user configured via browser settings or system control panel items accessible to standard users. To inspect and potentially configure the proxy settings for the Local System account, you can use the PsExec tool.

Open a command prompt as administrator and execute the following PsExec command:
```
PsExec.exe -i -s "start ms-settings:"
```
This command launches the Windows Settings application (ms-settings:) running under the Local System context (-s) in an interactive session (-i). Within this settings window, navigate to Network & internet > Proxy. Under the Manual proxy setup heading, select Edit.

Review the proxy server address and port configured here. These settings apply to services running under Local System. Ensure they match the correct proxy configuration for your network. If the settings are incorrect or missing, update them accordingly. After making any changes, click Save.

After verifying or updating the proxy settings for the Local System account, it is crucial to restart the Azure AD Connect Health agent services on the server. This ensures that the services pick up the new configuration. Restart the relevant Monitoring and Insights services through the Services snap-in (services.msc).

Correctly configuring the proxy for the Local System account is a frequent resolution for data freshness issues in proxy-heavy environments, as it ensures the Health agents can communicate with Azure without being blocked or encountering authentication challenges from the proxy.

Performance Counter Troubleshooting Steps¶

Azure AD Connect Health agents heavily rely on Windows Performance Counters to collect metrics about the health and performance of the monitored services (Sync, AD DS, AD FS). If these performance counters are missing, corrupted, or inaccessible, the agent cannot collect the required data, leading to data freshness alerts.

Run the following PowerShell commands on the affected server to check for the existence of critical performance counter categories used by the Health agents:

(Get-Counter -ListSet "AD FS" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD FS Diagnostics" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD DS Domain Controller" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD DS Directory Services" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD DS Database Performance" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD DS Replication" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD Sync Database" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD Sync Directory Manager" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD Sync Engine" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD Sync Extensible Connector" -ErrorAction SilentlyContinue) -ne $null
(Get-Counter -ListSet "AD Sync Provisioning" -ErrorAction SilentlyContinue) -ne $null

These commands check if the performance counter categories specific to AD FS, AD DS, and Azure AD Sync are registered on the system. If any of these commands return False, it indicates that the corresponding performance counter category is missing or corrupted. This is a significant problem because the Health agent cannot collect data from a non-existent source.

If any necessary performance counter categories are missing, you may need to rebuild or repair the performance counter library on the server. This can often be done using the lodctr utility.

Open Command Prompt as an administrator.
To rebuild the performance counter settings from the registry and resync with installed services:
```
lodctr /r
```
You might also need to re-enable performance counters if they were disabled:
```
lodctr /e:<service_name>
```
Replace <service_name> with the relevant service names (e.g., ADFS, ADSync). You can list all registered services using lodctr /q.

In some cases, the Health agent might lack the necessary permissions to access or read the performance counters. Ensure the service account running the Health agent service is a member of the “Performance Monitor Users” or “Performance Log Users” group on the server. This group grants the required permissions to collect performance data.

After addressing potential issues with performance counters (rebuilding, checking permissions), restart the relevant Azure AD Connect Health agent services. Allow some time for the agent to start collecting and sending data again. Monitor the Azure portal to see if the data freshness alert is resolved.

Data Type Troubleshooting Steps¶

The “Health service data is not up to date” alert can sometimes be specific to certain data types, even if the agent is generally communicating. This section provides troubleshooting steps for scenarios where particular categories of data are not being reported. This is an area requiring deeper inspection into the agent’s operation and the data sources it relies upon.

The Health agent collects various data types specific to the service it monitors. For AD FS, this includes sign-in activity, performance metrics, and configuration data. For AD DS, it includes replication status, domain controller performance, and health metrics. For Azure AD Sync, it includes sync statistics, connector status, and engine performance. If only certain data types are missing, it suggests an issue with the agent’s ability to collect that specific type of data, rather than a complete communication failure.

Consider the following potential causes and troubleshooting steps for specific data types:

Specific Event Logs Not Accessible: Some data types, like sign-in activity for AD FS, are collected by reading specific Windows Event Logs. Ensure the service account running the Health agent has read permissions on the relevant event logs (e.g., ‘AD FS/Tracing’, ‘AD FS/Admin’ for AD FS; Security log, Directory Service log for AD DS/Sync). If the logs are archived or wrapped too quickly, data might be missed.
Underlying Service Component Failure: The Health agent collects data from the monitored service (AD FS, AD DS, Sync). If a specific component of the monitored service is failing or not functioning correctly, it might not be generating the data the Health agent expects. For example, if AD FS auditing is disabled, sign-in data cannot be collected. If AD DS replication is failing, replication metrics will be stale. Troubleshoot the underlying service components first if you suspect this is the case.
Agent Configuration Issues: Although less common, a specific configuration setting within the Health agent itself could potentially prevent the collection or processing of certain data types. Review the agent’s configuration files (discussed in the log collection section) for any non-default settings that might be interfering.
Data Processing or Serialization Errors: Occasionally, the agent might collect data but fail to process or serialize it correctly before sending it to Azure. This could be due to unexpected data formats or internal agent issues. Checking agent logs is crucial here.

If you’ve identified specific missing data types via the Azure portal (as described in the Symptoms section), focus your troubleshooting on the source of that particular type of data. For instance, if AD FS sign-in data is missing, investigate AD FS auditing settings and relevant event log permissions. If AD DS replication data is missing, check AD DS replication status and event logs on the domain controller.

Analyzing the agent logs, as detailed in the next section, is often the most effective way to pinpoint issues related to specific data types. The logs will typically contain error messages indicating failure to access a specific data source or process a particular type of data.

Collect Logs for the Monitoring Agent and Insights Agent¶

When standard troubleshooting steps don’t resolve the data freshness alert, collecting detailed logs from the Azure AD Connect Health agent services is the next crucial step. These logs provide granular information about the agent’s operations, connectivity attempts, data collection processes, and any errors encountered. You will typically need logs from the Monitoring Agent and the Insights Agent. The Diagnostics Agent logs are also relevant, specifically for AD FS.

To collect logs from these services running under the Local System account, you will again use the PsExec tool to open a command prompt in that context.

Start by opening a command prompt as administrator and running the following command:

PsExec.exe -i -s cmd

This command launches a new command prompt window running with Local System privileges. This is necessary because the agent services run under this account, and their logs or console output will be accessible within this context.

Collect Monitoring Agent Logs¶

The Monitoring Agent is responsible for collecting health data, performance counters, and event logs from the monitored service. Collecting its console output can reveal real-time errors during data collection or submission.

In the remote command prompt window opened via PsExec, enter services.msc to open the Services snap-in running under the Local System context.
Locate and Stop the Monitoring Service for the relevant service type. For example:
- For AD FS: Microsoft Entra Connect Health AD FS Monitoring Service
- For AD DS: Microsoft Entra Connect Health AD DS Monitoring Service
- For Sync: Microsoft Entra Connect Health Sync Monitoring Service
  Select the service from the list, right-click, and select Stop, or use the stop icon in the toolbar.

Navigate to the directory where the Monitoring Agent executable is located. The path depends on the service type:

Service Type	Path	Executable Name
Sync	`C:\Program Files\Microsoft Azure AD Connect Health Sync Agent\Monitor`	`Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe`
AD DS	`C:\Program Files\Azure AD Connect Health Adds Agent\Monitor`	`Microsoft.Identity.Health.Adds.MonitoringAgent.Startup.exe`
AD FS	`C:\Program Files\Azure Ad Connect Health Adfs Agent\Monitor`	`Microsoft.Identity.Health.Adfs.MonitoringAgent.Startup.exe`

Use the cd command to change directories. For example, for AD FS:

cd "C:\Program Files\Azure Ad Connect Health Adfs Agent\Monitor"

4. Edit the Monitoring Agent’s configuration file to enable console debugging. The configuration file has the same name as the executable with a .config extension. Open it in a text editor (like Notepad) from the PsExec command prompt:

notepad "Microsoft.Identity.Health.Adfs.MonitoringAgent.Startup.exe.config"

In the configuration file, typically within the <appSettings> section, insert or modify the following line to set ConsoleDebug to true:

<add key="ConsoleDebug" value="true" />

Save and close the configuration file.
5. Run the Monitoring Agent executable directly from the command prompt with its output redirected to a log file. This allows you to capture the console output.
For example, for AD FS:

Microsoft.Identity.Health.Adfs.MonitoringAgent.Startup.exe > monitor.log

6. Let the agent run in this mode for about 15 minutes. This duration should be sufficient for it to attempt data collection and transmission cycles and log any recurring errors. After 15 minutes, press Ctrl+C in the command prompt window to stop the service.
7. Inspect the monitor.log file created in the agent’s directory using Notepad or another text editor. Look for error messages (Error), warnings (Warning), or exceptions that might indicate why data collection or transmission is failing.

Collect Insights Agent Logs¶

The Insights Agent processes the data collected by the Monitoring Agent and sends it to the Azure AD Connect Health service in the cloud. Collecting its logs helps diagnose issues with data processing, formatting, or successful transmission.

In the remote command prompt window opened via PsExec, enter services.msc to open the Services snap-in.
Locate and Stop the Insights Service for the relevant service type. For example:
- For AD FS: Microsoft Entra Connect Health AD FS Insights Service
- For AD DS: Microsoft Entra Connect Health AD DS Insights Service
- For Sync: Microsoft Entra Connect Health Sync Insights Service
  Stop the service using the context menu or the stop icon.

Navigate to the directory where the Insights Agent executable is located. The path depends on the service type:

Service Type	Path	Executable Name
Sync	`C:\Program Files\Microsoft Azure AD Connect Health Sync Agent\Insights`	`Microsoft.Identity.AadConnect.Health.AadSync.Host.exe`
AD DS	`C:\Program Files\Azure AD Connect Health Adds Agent\Insights`	`Microsoft.Identity.Health.Adds.InsightsService.exe`
AD FS	`C:\Program Files\Azure Ad Connect Health Adfs Agent\Insights`	`Microsoft.Identity.Health.Adfs.InsightsService.exe`

Use the cd command. For example, for AD FS:

cd "C:\Program Files\Azure Ad Connect Health Adfs Agent\Insights"

4. Run the Insights Agent executable directly from the command prompt, using the /console parameter to enable console output and redirecting it to a log file.
For example, for AD FS:

Microsoft.Identity.Health.Adfs.InsightsService.exe /console > insights.log

5. Let the agent run in console mode for about 15 minutes. This allows it to attempt processing and sending data. Press Ctrl+C to stop the service.
6. Inspect the insights.log file. Look for errors related to processing collected data, connecting to Azure endpoints, or transmitting data packages. Proxy authentication failures, serialization errors, or service endpoint issues are often logged here.

Collect Logs for the Diagnostics Agent (for AD FS only)¶

For AD FS environments, there is an additional agent, the Diagnostics Agent, responsible for collecting specific diagnostic data, often related to configuration and operational health. Collecting its logs can be helpful if the issue seems related to AD FS specific diagnostics.

In the remote command prompt window opened via PsExec, enter services.msc to open the Services snap-in.
Locate and Stop the Diagnostics Service for AD FS: Microsoft Entra Connect Health AD FS Diagnostics Service.

Navigate to the diagnostics directory for AD FS:

cd "C:\Program Files\Azure Ad Connect Health Adfs Agent\Diagnostics"

Run the Diagnostics Agent executable using the -Debug parameter to increase logging verbosity and redirect the output to a log file.
```
Microsoft.Identity.Health.Adfs.DiagnosticsAgent.exe -Debug > diagnostics.log
```
Press Enter to start the agent in debug console mode.
Let the agent run for approximately 15 minutes to collect and process data. Press Ctrl+C to stop the service.
Copy the console output (which was redirected to diagnostics.log) to a file if necessary (though the redirection should have handled this). Inspect the diagnostics.log file for any errors or warnings specific to AD FS diagnostic data collection or reporting. Search for terms like Error, Failed, or Exception. This log might provide insights into specific AD FS configuration or operational issues that the agent is attempting to report but failing to transmit.

After collecting and reviewing the logs from the relevant agents, you should have a clearer picture of where the process is failing – whether it’s during data collection (Monitoring Agent), data processing/sending (Insights Agent), or specific diagnostic checks (Diagnostics Agent for AD FS). The error messages in the logs are the most valuable clues for identifying the root cause, whether it’s a network issue, permissions problem, configuration error, or an issue with the underlying service itself.

Data Flow Diagram (Conceptual)¶

Here is a simplified conceptual diagram illustrating the data flow from your on-premises infrastructure to the Azure AD Connect Health service in the cloud. Understanding this flow can help visualize potential points of failure when troubleshooting data freshness.

```mermaid
graph LR
A[On-Premises Server
(Sync, AD FS, AD DS)] → B(Performance Counters,
Event Logs,
Service State)
B → C{Azure AD Connect Health Agents
(Monitoring, Insights, Diagnostics)}
C → D(Data Processing
& Aggregation)
D → E(Secure Tunnel/
HTTPS Outbound)
E → F(Internet/Proxy)
F → G(Azure Endpoints
for Connect Health)
G → H[Azure AD Connect Health Service
(Data Storage & Analysis)]
H → I[Azure Portal
(Visualizations & Alerts)]

subgraph On-Premises
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
end

subgraph Azure Cloud
    G --> H
    H --> I
end

F -.-> G

```

This diagram highlights the key stages: data sources on the server, collection by agents, processing, secure transmission, potential network/proxy hops, Azure ingress, and finally, display in the portal. Issues at any stage can cause data freshness problems.

Conclusion¶

Resolving the “Health service data is not up to date” alert in Azure AD Connect Health requires a systematic approach, investigating potential issues from basic connectivity to agent-specific problems and underlying service health. By systematically checking network connectivity, verifying proxy configurations for the correct user context, ensuring performance counters are available, troubleshooting data type specific issues, and ultimately analyzing detailed agent logs, you can identify and rectify the root cause.

Maintaining current data in Azure AD Connect Health is vital for proactive monitoring and ensuring the reliability of your hybrid identity components. Regular checks and prompt resolution of such alerts contribute significantly to a stable and performant identity infrastructure.

Did this troubleshooting guide help you resolve the data freshness alert? Do you have additional tips or scenarios you encountered? Share your experiences and feedback in the comments below to help others in the community.

Computacionvinchi