If you’ve been following my blog, you know that I mention the Intune Management Extension (IME) in several of them. The IME is a powerful tool that help you to manage your devices. In this blog, I’d like to go into more detail and take a look behind the scenes to explain how the IME works and what you should know about it. So let’s get started!

What is the Intune Management Extension

The Intune Management Extension is a complement to the out of the box windows management functions like the omadmclient. The IME allows to install applications on managed systems or to execute e.g. PowerShell scripts. Additional the IME checks and reports the compliance state of your device.

How often does the IME sync

The IME syncs per default ever 60 min but you can change the time if you create an registry value Interval in MKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Settings. In this value you can specify the time in seconds.

Where can I find the logfiles

You can find the logfiles in the following folder C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

AgentExecution.log: Logfile for troubleshooting of PowerShell or Proactive Remediation scrips.

ClientHealth.log: Write health events related to the IME and also remediation action

IntuneManagementExtension.log: Logfile for installations of IntuneWin applications

Sensor.log: Logging of subscribed events

How can I change the log level of the IME

How this works I have already explained in deep in this blog. Also I wrote a script which helps you to change the log level. You can find this script in my GitHub repo.

How does a Application installation works

To deploy a app via Intune you have to create a Intune.win file. How you can create such a file and how you can create a new Win32 app in Intune I describe in the this blog post. But now I want to explain how the local app installation process works:

Get Token

The IME needs an AAD token for the authentication. This token will be requested using the service URL https://login.microsoft.com.

The method GetTokenSilentlyAsync is used to request the token. The static resource ID (26a4ae64-5862-427f-a9b0-044e62572a4f) is added to the request. From the response we get then the token.

Retrieve Metadata

Next, the current proxy server is checked and a request is sent to the proxy to get the content meta data. The previously received token is used for authentication.

In the meta data are all kinds of information that are needed for the pre and post checks of the app installation like the detection rule, requirement rules or the different commands.

Processing App

Search for the line —->>[Win32App] Processing app… from here the actual processing of the app starts

Installation checks

Before the installation can start, two checks are made. The first is a detection if the app is already installed and the second is if the app is applicable for this system this means does the system full fill the requirements of the app.

App Detection check

The detection check is to check if the app is already installed on the system or not. This can be a registry key or the existence of a file or an MSI product code. Addition to that there are also the possibility to write a PowerShell script for the detection. This check is configured during the app creation in Intune.

In my case the Path does not exist and with this the app is not installed. This means this check is passed.

App Applicability / Requirements check

The applicability check is used to check if the system meets the requirements of the app like min disk space, OS architecture, OS version or you can also create custom checks for a file, regkey or a custom script. Also this is configured during the creation of the app in Intune.

Also here are all checks passed in my case. There are two steps one is the applicability check the upper definitions and the second step is the check of the extended requirements this are the mentioned custom checks.

App Download

After all checks were successful, the content is now downloaded.

For this a content request is prepared for sending to Intune. In this request you see several information’s, some of them are transmitted as numbers. The number 3 does for example mean required installation (1 = Available, 4 = Uninstall). An exact translation of what the other individual values mean I have unfortunately not found. But you can guess what the values mean e.g. the targeted type 2 is probably the same as the install behavior and therefore an installation in the system context. But what you can clearly see is that the installation takes place outside of the ESP.

In the next log section we have a lot of information. First of all, a new token will be requested from the AAD. How this works you can see above in section Get Token.

After that the request mentioned above is sent to Intune and a response is returned. Let’s have a look what is in this response. We see a lot of general information about the request like the SessionId, the Key and some others. But what is much more interesting is the content of the ContentInfo.
Here we see for example the download type in my case 2. I guess this is the delivery optimization priority if it is a foreground or background download.
We also see the UploadLocation this is the downloadlink for the *.intunewin.bin file. Additionaly we find the DoFileId this ID is used for the search for delivery optimization peers.

Now we go to the last step of the content download. If you have configured a toast notification for the app, it will be triggered by the agentexecutor.exe.

After that a new download job will be created. This is also where delivery optimization comes into play. The *.intune.bin file is now downloaded into the “C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming\” folder.

When the download is completed the Delivery Optimisation Service is notified that the download is done and telemetry data is generated for the Deliver Optimisation reporting. You can see how many bytes from which source (Internet/Lan/Group/MCC) are downloaded or how long the download took.

Finally the file hash is checked and the intunewin.bin file is decrypted and unzipped. This *.intunewin file is now located in the “C:\Windows\IMECache\” folder.

App Installation

The next step is to install the application.

For this, the installation script is executed. In my case it is the install.bat script. For the installation an installer process is started as a user or machine session. After the installation is finished the process is evaluated if it ended with an error or if the installation was successful. The status of the installation can be found in the registry: “HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\user\appid“.

Afterwards it is checked if a restart is necessary for the application. This was also defined in Intune when creating the app.

App Detection

Like before the app installation, the app detection is executed again after the app installation to check if the app is detected based on the configured criteria after the installation. In my case the app was detected.

Completion of the installation

Last but not least, the app installation is now completed. This is divided into two phases. One is to set the compliance state and one is to report the status back to Intune.

In the compliance phase, the compliance is checked based on the status of the installation and the app detection. This compliance status is written into the registry under: “HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\user\appid\ComplianceStateMessage“. When this is done, the content of “C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming\” is deleted.

In the very last phase, a report of the installation is saved locally and sent to Intune. Additionally also the IMECache in “C:\Windows\IMECache\” is cleaned to finally complete the installation.

How often is an installation retried when it fails

The installation is repeated 3 times. However, there must be at least 5 minutes between the attempts. When all this 3 attempts fails then at the app is in the GRS (Global Reevaluation Scheme). This means the IME waits 24h to try the next attempt to install the app.

How can I start a new installation attempt for an app that is in the GRS?

To start directly a new installation attempt of an app you can delete the key from the application in the following registry path:

• “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\SID\AppGuid“

• “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\SID\GRS\AppId“

If you have deleted the key of the app then restart the IME process then a new installation attempt should start.

Triggering of an IME sync

The easiest way to trigger a sync of the IME is to restart the process. Open the Task manager and navigate to Services und search for Intune Management Extension. Right click on the Process and click Restart.

But there are also some other ways to do this. The first way is to trigger the sync via a PowerShell. If you look ate the code of the IME you see that there are two possible args for triggering an sync. This is an URL Monikers.

In the registry (HKLM\SOFTWARE\Classes\) you can find the action intunemanagementextension. When you call this action you can add after the action name :// to pass the argument syncapp or synccompliance.

To do this via PowerShell you can use the following command:

Sync apps:

    $syncIme = New-Object -ComObject Shell.Application
    $syncIme.open("intunemanagementextension://syncapp")

Sync compliance:

    $syncIme = New-Object -ComObject Shell.Application
    $syncIme.open("intunemanagementextension://synccompliance").

Or you can trigger the sync via the company Portal:

Sync apps:

Sync compliance:

Where on the system the IME leaves traces

Registry

An important path in the registry that can always helps is: “HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\“

Here you can find for example the inventory of all apps that are installed on your system. You can then find this inventory in Intune under discovered apps.

You can also find the Inventory settings in this path. You can find here e.g. the time when the last full sync took place.

But you can find much more info here.

Folder

As already mention above the logfiles can be found in the following folder: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

But the most important folder is this one: C:\Program Files (x86)\Microsoft Intune Management Extension.

This is the location of the Microsoft.Management.Services.IntuneWindowsAgent.exe.

Schedule Tasks

In the Task scheduler you can find an task with the name Intune Management Extension Health Evaluation. The Task will runs once a day and the action is to execute the (C:\Program Files (x86)\Microsoft Intune Management Extension\ClientHealthEval.exe)

The job is very simple, it checks if the IME service is running as it should or not. What the task does in detail you can see in the HealthCheck.xml. It checks if the service exists, how the startup type and the status is checked and how the memory usage is. If a check is not as it should be a remediation is executed. The result of the last run can be seen in the HealthReport.json.

Other good reads about the IME

• Triggering Intune Management Extension (IME) Sync – (Oliver Kieselbach)
• Retry Lola Retry – (Rudy Ooms)
• Intune Management Extension Deep Dive – Win32 App Deployment Troubleshooting Help Guide – (Anoop C Nair)

Conclusion

I hope that this blog post has given you a view behind the scenes of the Intune management extension. As with every blog post, I try to keep this up to date and update the blog constantly. Thank you for reading my blog post.

Stay healthy, Cheers
Jannik