Understanding the Intune Management Extension client health check

This week is sort of a follow-up on the posts of the last couple of weeks about Win32 apps. This week, however, the focus is more on the process that is in place to make sure that everything around the Intune Management Extension (IME) keeps functioning. The IME contains many important components for installing Win32 apps, for running PowerShell scripts, for running inventories, and more. That makes it important that the IME is running successfully. To make sure that the IME is running successfully, the Intune Management Extension Health Evaluation was introduced. That evaluation is focused on performing checks on the service of the IME. This post will have a closer look at the IME client health check and the actions that it performs.

Starting with the scheduled task

When looking at the IME client health check, it all starts with the Intune Management Extension Health Evaluation scheduled task (as shown below in Figure 1). That scheduled task is created during the installation of the IME and runs on a daily basis with a randomized delay of an hour. More importantly, that scheduled task runs C:\Program Files (x86)\Microsoft Intune Management Extension\ClientHealthEval.exe. The ClientHealthEval.exe contains the binaries for the client health check and uses the ClientHealthEval.exe.config to set the source, the log level and the log file. That log file is the ClientHealth.log and is available in the standard log directory of IME, being C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. The information in that log file is coming from the ClientHealth component with information around the actual checks and from the IntuneManagementExtension component with information around the more generic tasks related to the client health check.

Looking closer at the client health checks

For a lot more information around the internal workings of the client health check, it’s possible to look directly at the code by opening the ClientHealthEval.exe with something like JetBrains dotPeek. That will provide a whole lot of information around the checks that are performed and shows the importance of the HealthCheck.xml that contains all the rules that should be checked during the client health check. The starting point of that is shown below in Figure 2. In most cases, however, it is more then enough to be familiar with the rules that are defined. Mainly because those rules are pretty well described, including the remediation action. The XML-file describes four rules that should be checked during the health check.

The first rule is Verify Intune Management Extension service exists and that rule checks for the existence of the Microsoft Intune Management Extension service. That rule is shown below in Figure 3 and the main details of that rule are summarized in the table below. There is no remediation for this specific rule.

idTypeService checkService name
B862E7A7-FE34-47F3-A648-EDD4803F781AServicesServiceExistsIntuneManagementExtension

The second rule is Verify/Remediate Intune Management Extension Service startup type and that rule checks for the startup type of the Microsoft Intune Management Extension service. That rule is shown below in Figure 4 and the main details of that rule are summarized in the table below. Besides that, also note that this rule depends on the first rule. The remediation of this rule is to get the service back to the desired startup type.

idTypeService checkService nameStartup state
05980F21-0099-4AC4-8BA7-C9F5F0CD0B7FServicesServiceStartupTypeIntuneManagementExtensionAutomatic

The third rule is Verify/Remediate Intune Management Extension service status and that rule checks for the status of the Microsoft Intune Management Extension service. That rule is shown below in Figure 5 and the main details of that rule are summarized in the table below. Besides that, also not that this rule depends on the first rule. The remediation of this rule is to get the service back to the desired service status.

idTypeService checkService nameService status
64103933-CDE5-419B-ABC7-4BFE5C535C4AServicesServiceStatusIntuneManagementExtensionActive

The fourth rule is Verify/Remediate Intune Management Extension memory usage and that rule checks for the memory usage of the Microsoft Intune Management Extension service. That rule is shown below in Figure 6 and the main details of that rule are summarized in the table below. Besides that, also not that this rule depends on the first rule. The remediation of this rule is to restart the Microsoft Intune Management Extension service.

idTypeMemory checkProcessMemory threshold
0CF538CD-6BBA-4690-8776-E1F63F6D8D63MemoryMemorycheckMicrosoft.Management.Services.IntuneWindowsAgent20

The process of the different rules can be followed within the ClientHealth.log log, based on the id and the name of the rule.

Reporting about the status of the client health checks

When the client health check is completed, the information will be collected in the HealthReport.json. That report will contain an overview of the status of the different rules, based the id of the rule. An overview of that report is shown below in Figure 7. After collecting the information, that report will be sent to Microsoft Intune.

More information

This process is currently not documents in the Microsoft docs.

3 thoughts on “Understanding the Intune Management Extension client health check”

Leave a Comment

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