KnowledgeBase: High CPU Usage for Azure AD Connect Health Sync Monitor with .NET Framework 4.7.2 Installed

Reading Time: 3 minutes

Smoking CPU

KnowledgeBaseToday, there is an issue in a component of Azure AD Connect version 1.1.819.0, Microsoft free Hybrid Identity bridge product, that enables you to synchronize objects and their attributes between your on-premises Active Directory Domain Services (AD DS) environment(s) and Azure Active Directory.

The Azure AD Connect Health Sync Monitor Service consumes lots of CPU.

 

About Azure AD Connect Health

Azure AD Connect Health helps administrators monitor and gain insights into their Hybrid Identity implementations. It enables you to maintain a reliable connection to Office 365 and Microsoft Online Services by providing monitoring capabilities for your key identity components:

  • Azure Active Directory Connect installations
  • Active Directory Federation Services (AD FS) servers
  • Web Application Proxies
  • Active Directory Domain Controllers

Azure AD Connect Health makes the key data points about these components easily accessible in the Azure AD Connect Health portal so performance monitoring, usage analysis, troubleshooting and gaining other important insights becomes easy.

Note:
The Azure AD Connect Health component is installed, by default, with Azure AD Connect and, by default, sends diagnostic data to Microsoft. However, an Azure AD Premium license is needed to access the Azure AD Connect Health Portal.

 

The situation

You have installed Azure AD Connect version 1.1.819.0 or your Azure AD Connect version has automatically upgraded to version 1.1.819.0, along with the auxiliary components, like Azure AD Conect’s Health Agent for Sync. Version 1.1.819.0 of Azure AD Connect comes with Health Agent for Sync version 3.0.164.

You can check these versions in Programs and Features:

Azure AD Connect's version and components in Programs and Features (click for original screenshot)

 

The issue

The Azure AD Connect Health Sync Monitoring Service with version 3.0.164 of the Health Agent for Sync (AzureADConnectHealthSyncMonitor) is always running with high CPU usage. When you stop the service and start it again, CPU usage is normal for the service for a few minutes, before it starts consuming many CPU cycles again.

Reinstalling or reregistering the Azure AD Connect Health Sync Monitoring Service does not resolve the situation.

 

The cause

Azure AD Connect Health’s Sync Monitoring Service is causing high CPU usage, because of .NET Framework 4.7.2.

 

The solution

Uninstalling the package that upgrades .NET Framework to version 4.7.2 from the Windows (Server) installation that runs Azure AD Connect solves the issue:

    • On Windows Server 2012, uninstall the Update for Microsoft Windows (KB4054542).
    • On Windows 8.1 and Windows Server 2012 R2, uninstall the Update for Microsoft Windows (KB4054566).
    • On Windows 10 Anniversary Update, Windows 10 Creators Update and Windows Server 2016, uninstall the Update for Microsoft Windows (KB4054590).
    • In Windows 10 Fall Creators Update, uninstall the Update for Microsoft Windows (KB4073120).

Note:
.NET Framework 4.7.2 is not a security release of .NET Framework, but a compatibility update…

 

Concluding

Software isn’t perfect. It has bugs and vulnerabilities, but the speed in which a software vendor remedies these brings trust. When two teams in a large software vendor, like Microsoft, create incompatibilities, this reduces trust.

Further reading

What's new in the .NET Framework
Azure AD Connect Health Sync Monitor High CPU Usage

15 Responses to KnowledgeBase: High CPU Usage for Azure AD Connect Health Sync Monitor with .NET Framework 4.7.2 Installed

  1.  

    Thanks for posting this.

    I fought up and down with their horrible support and they could not tell me what the issue is. They continue to "run tests on the backend which can take up to 24hrs".

    It's sad how horrible this company has gotten, all at the expense of the IT professionals who have to support their garbage. Hopefully they release an update soon.

  2.  

    We have Windows Server 2012 R2. The server is a VM with 2 CPUs.
    We did not installed the Update for Microsoft Windows (KB4054566).
    However, CPU utilization is 99-100%, 93% is used by Azure AD Connect Health’s Sync Monitoring Service

  3.  

    I'm having this issue on Windows Server 2012 Standard, but the update you mentioned is not installed????
    The CPU consumption did start after windows updates though.

    We installed:

    KB4338830
    KB4338421
    KB4338418

    • Hi Oliver,

      The July updates also seem to contain .Net Framework changes.

      The following updates might cause Azure AD Connect to consume lots of CPU on Azure AD Connect installations:

      Windows Server 2016: KB4338814
      Windows Server 2012 R2: KB4338824 / KB4338815
      Windows Server 2012: KB4338820 / 4338830
      Windows Server 2008 R2: KB4338823 / KB4338818
      Windows Server 2008: KB4295656

      The above updates have been pulled by Microsoft and will be replaced. Currently, it isn't 100% known if the replacement updates do not cause high CPU usage for Azure AD Connect installations.

       
  4.  

    I wish KB4338814 was pulled it reinstalls every reboot after I manually uninstall it…

  5. Azure AD Connect version 1.1.880.0 was released as an automatic upgrade for Azure AD Connect installations, today. It will be released shortly as a download for organizations utilizing their own life cycle management process for Azure AD Connect.

    Azure AD Connect version 1.1.880.0 installs version 3.1.7.0 of the Azure AD Connect Health agent. This version no longer experiences the race condition when you have installed any of the .Net related updates above.

    After Azure AD Connect version 1.1.880.0 is installed, you can safely install the updates you have been putting off to avoid the high CPU usage of the Azure AD Connect Health Sync Monitoring Service.

    Azure AD Connect Health version 3.1.7.0 is also available as a separate download.

     
  6.  

    Thanks for the great information. 🙂
    Microsoft released also a knowledge base article about this. (But its not up-to-date yet)

  7.  

    Sander, can I force the auto update? I have this high CPU thing going on and haven't received the 880 version and the download isn't available yet.

    • Hi Edwin,

      I'm sorry to hear you're among the ones experiencing this issue.

      As far as I know, there's no way to trigger the Automatic Upgrade process for Azure AD Connect.
      However, there is documentation on troubleshooting non-upgrading Azure AD Connect installations, that you might want to look at.

      Don't stop or disable the Azure AD Connect Health Monitoring service itself, though, because the automatic upgrade functionality uses Azure AD Connect Health for the upgrade infrastructure.

       
  8.  

    I have disabled my AD Health Monitoring service because of the high CPU utilization, therefore my AAD Connect agent will never auto-upgrade and MSFT STILL hasn't released the MSI. This is insanely frustrating.

  9.  
  10.  

    I had a similar problem, I upgraded to AD Connect 1.1.880.0 and the CPU is no loger shooting.

  11.  

    Thank you, Azure AD Connect version 1.1.880.0 fixed my high cpu problem.

  12.  

    I look after 20+ client servers that have this issue and none of them have automatically updated. They are all set to do so (enabled) and none are logging things in the Application event log. I have tried to manually update but the Azure AD Connect wizard wants the sync account and password added back in and gives no indication of what was originally used – these were set up by the customers themselves in a lot of cases and we don't have records for it. Basically the whole situation is a total mess, some testing would have been good by MS before we got into this situation!

  13.  

    Hi ,

    I would like to know why Azure AD Connect Health Sync Insights Service is Not Running.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.