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.

Figure 1: Overview of the scheduled task

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.

Figure 2: Overview of the XML input in the code

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.

Figure 3: Overview of the first health check rule

id	Type	Service check	Service name
B862E7A7-FE34-47F3-A648-EDD4803F781A	Services	ServiceExists	IntuneManagementExtension

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.

Figure 4: Overview of the second health check rule

id	Type	Service check	Service name	Startup state
05980F21-0099-4AC4-8BA7-C9F5F0CD0B7F	Services	ServiceStartupType	IntuneManagementExtension	Automatic

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.

Figure 5: Overview of the third health check rule

id	Type	Service check	Service name	Service status
64103933-CDE5-419B-ABC7-4BFE5C535C4A	Services	ServiceStatus	IntuneManagementExtension	Active

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.

Figure 6: Overview of the fourth health check rule

id	Type	Memory check	Process	Memory threshold
0CF538CD-6BBA-4690-8776-E1F63F6D8D63	Memory	Memorycheck	Microsoft.Management.Services.IntuneWindowsAgent	20

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.

Figure 7: Overview of the health report

More information

This process is currently not documents in the Microsoft docs.