Thema dieser Seite: Intune Management Extension: IME-Guide 2026
Wenn du meinen Blog verfolgst, weißt du, dass ich die Intune Management Extension (IME) in mehreren Beiträgen erwähne. Die IME ist ein mächtiges Werkzeug, das dir bei der Verwaltung deiner Geräte hilft. In diesem Blog möchte ich näher darauf eingehen und einen Blick hinter die Kulissen werfen, um zu erklären, wie die IME funktioniert und was du darüber wissen solltest. Also legen wir los!
Inhaltsverzeichnis
Kurzantwort: Die Microsoft Intune Management Extension (IME) ist der Windows-Agent für Win32-Apps, PowerShell-Skripte, Remediations, Custom Compliance und weitere unterstützte Intune-Workloads. Sie installiert sich nach einer passenden Zuweisung automatisch, prüft normalerweise alle acht Stunden auf neue Arbeit und schreibt ihre Logs nach C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
Last verified: 22. Juli 2026
Inhalt
- Inhalt
- Was ist die Intune Management Extension
- Wie oft synchronisiert die IME
- Wie gelangt die IME auf das Gerät?
- Wo finde ich die Logdateien
- Wie kann ich das Log-Level der IME ändern
- Wie funktioniert eine Anwendungsinstallation?
- Wie oft wird eine Installation bei einem Fehler wiederholt
- Wie kann ich einen neuen Installationsversuch für eine App starten, die sich in der GRS befindet?
- Auslösen einer IME-Synchronisierung
- Wo die IME Spuren auf dem System hinterlässt
- Remediation
- Weitere lesenswerte Beiträge zur IME
- Fazit
Was ist die Intune Management Extension
Die Intune Management Extension ist eine Ergänzung zu den standardmäßigen Windows-Verwaltungsfunktionen wie dem omadm- / mmp-c-Client. Die IME ermöglicht es, Anwendungen auf verwalteten Systemen zu installieren oder z. B. PowerShell-Skripte auszuführen. Zusätzlich prüft und meldet die IME den Compliance-Status deines Geräts.
Neu: Auch die Device Queries nutzen die Intune Management Extension, um die Werte zu erfassen.
Wie oft synchronisiert die IME
Die IME synchronisiert sich standardmäßig alle 8 Stunden. Die Synchronisierung wird durch einen geplanten Task ausgelöst, den du hier findest:
In diesem Ordner befinden sich aber auch drei verschiedene Tasks. Schedule #1 und #2 werden nur unmittelbar nach der IME-Installation ausgelöst. Schedule #3 ist derjenige, der dauerhaft läuft.
Wie gelangt die IME auf das Gerät?
Ein CSP wird auf das Gerät gepusht, das die Installation auslöst. Wenn die Installation erfolgreich war, siehst du das im Registry-Key: •HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseDesktopAppManagementS-0-0-00-0000000000-0000000000-000000000-000MSIguid
oder wenn der Prozess läuft:
Wo finde ich die Logdateien
Du findest die Logdateien im folgenden Ordner C:ProgramDataMicrosoftIntuneManagementExtensionLogs
AgentExecution.log: Logdatei für das Troubleshooting von PowerShell- oder Proactive-Remediation-Skripten.
ClientHealth.log: Schreibt Health-Events im Zusammenhang mit der IME sowie Remediation-Aktionen
IntuneManagementExtension.log: Logdatei für Installationen von IntuneWin-Anwendungen.
Update: Dies wurde geändert. App-Workloads wurden in die Appworkload.log verschoben.
Sensor.log: Logging von abonnierten Events
Appworkload.log: Hier findest du den gesamten App-Installationsprozess.
Wie kann ich das Log-Level der IME ändern
Wie das funktioniert, habe ich bereits ausführlich in diesem Blog erklärt. Außerdem habe ich ein Skript geschrieben, das dir hilft, das Log-Level zu ändern. Dieses Skript findest du in meinem GitHub-Repo.
Wie funktioniert eine Anwendungsinstallation?
Um eine App über Intune bereitzustellen, musst du eine Intune.win-Datei erstellen. Wie du eine solche Datei erstellst und wie du eine neue Win32-App in Intune anlegst, beschreibe ich im Beitrag Deploy a Win32 app with Intune. Jetzt möchte ich aber erklären, wie der lokale App-Installationsprozess abläuft:
Get Token
Die IME benötigt für die Authentifizierung ein Microsoft Entra ID Token. Dieses Token wird über die Service-URL https://login.microsoft.com angefordert.
Zum Anfordern des Tokens wird die Methode GetTokenSilentlyAsync verwendet. Die statische Resource-ID (26a4ae64-5862-427f-a9b0-044e62572a4f) wird der Anfrage hinzugefügt. Aus der Antwort erhalten wir dann das Token.
Retrieve Metadata
Als Nächstes wird der aktuelle Proxy-Server geprüft und eine Anfrage an den Proxy gesendet, um die Content-Metadaten zu erhalten. Das zuvor erhaltene Token wird zur Authentifizierung verwendet.
In den Metadaten befinden sich allerlei Informationen, die für die Pre- und Post-Checks der App-Installation benötigt werden, wie die Detection Rule, Requirement Rules oder die verschiedenen Befehle.
Processing App
Suche nach der Zeile —->>[Win32App] Processing app… ab hier beginnt die eigentliche Verarbeitung der App
Installationsprüfungen
Bevor die Installation starten kann, werden zwei Prüfungen durchgeführt. Die erste ist eine Detection, ob die App bereits installiert ist, und die zweite, ob die App für dieses System anwendbar ist, also ob das System die Anforderungen der App erfüllt.
App-Detection-Prüfung
Die Detection-Prüfung dient dazu, zu prüfen, ob die App bereits auf dem System installiert ist oder nicht. Das kann ein Registry-Key oder das Vorhandensein einer Datei oder eines MSI-Produktcodes sein. Zusätzlich besteht auch die Möglichkeit, ein PowerShell-Skript für die Detection zu schreiben. Diese Prüfung wird während der App-Erstellung in Intune konfiguriert.
In meinem Fall existiert der Pfad nicht und damit ist die App nicht installiert. Das bedeutet, diese Prüfung ist bestanden.
App-Applicability- / Requirements-Prüfung
Die Applicability-Prüfung wird verwendet, um zu prüfen, ob das System die Anforderungen der App erfüllt, wie minimaler Speicherplatz, OS-Architektur, OS-Version, oder du kannst auch eigene Prüfungen für eine Datei, einen Registry-Key oder ein Custom Script erstellen. Auch dies wird während der Erstellung der App in Intune konfiguriert.
Auch hier sind in meinem Fall alle Prüfungen bestanden. Es gibt zwei Schritte: einer ist die Applicability-Prüfung mit den oben genannten Definitionen, und der zweite Schritt ist die Prüfung der erweiterten Requirements, das sind die erwähnten Custom Checks.
App Download
Nachdem alle Prüfungen erfolgreich waren, wird nun der Content heruntergeladen.
Dazu wird eine Content-Anfrage vorbereitet, die an Intune gesendet wird. In dieser Anfrage siehst du verschiedene Informationen, einige davon werden als Zahlen übertragen. Die Zahl 3 bedeutet zum Beispiel Required-Installation (1 = Available, 4 = Uninstall). Eine genaue Übersetzung, was die anderen einzelnen Werte bedeuten, habe ich leider nicht gefunden. Aber man kann erahnen, was die Werte bedeuten, z. B. ist der targeted type 2 vermutlich dasselbe wie das Install-Behavior und damit eine Installation im Systemkontext. Was du aber klar erkennen kannst, ist, dass die Installation außerhalb des ESP stattfindet.
Im nächsten Log-Abschnitt haben wir eine Menge Informationen. Zunächst wird ein neues Token von Microsoft Entra ID angefordert. Wie das funktioniert, siehst du oben im Abschnitt Get Token.
Danach wird die oben erwähnte Anfrage an Intune gesendet und eine Antwort zurückgegeben. Schauen wir uns an, was in dieser Antwort steht. Wir sehen viele allgemeine Informationen zur Anfrage wie die SessionId, den Key und einige andere. Aber viel interessanter ist der Inhalt der ContentInfo.
Hier sehen wir zum Beispiel den Download-Typ, in meinem Fall 2. Ich vermute, das ist die Delivery-Optimization-Priorität, ob es sich um einen Foreground- oder Background-Download handelt.
Wir sehen außerdem die UploadLocation, das ist der Download-Link für die *.intunewin.bin-Datei. Zusätzlich finden wir die DoFileId, diese ID wird für die Suche nach Delivery-Optimization-Peers verwendet.
Jetzt kommen wir zum letzten Schritt des Content-Downloads. Wenn du für die App eine Toast-Benachrichtigung konfiguriert hast, wird diese von der agentexecutor.exe ausgelöst.
Danach wird ein neuer Download-Job erstellt. Hier kommt auch die Delivery Optimization ins Spiel. Die *.intune.bin-Datei wird nun in den Ordner “C:Program Files (x86)Microsoft Intune Management ExtensionContentIncoming” heruntergeladen.
Wenn der Download abgeschlossen ist, wird der Delivery Optimization Service benachrichtigt, dass der Download fertig ist, und es werden Telemetriedaten für das Delivery-Optimization-Reporting generiert. Du kannst sehen, wie viele Bytes aus welcher Quelle (Internet/Lan/Group/MCC) heruntergeladen wurden oder wie lange der Download gedauert hat.
Schließlich wird der File-Hash geprüft und die intunewin.bin-Datei wird entschlüsselt und entpackt. Diese *.intunewin-Datei befindet sich nun im Ordner “C:WindowsIMECache“.
App Installation
Der nächste Schritt ist die Installation der Anwendung.
Dazu wird das Installationsskript ausgeführt. In meinem Fall ist es das install.bat-Skript. Für die Installation wird ein Installer-Prozess als User- oder Machine-Session gestartet. Nachdem die Installation abgeschlossen ist, wird der Prozess ausgewertet, ob er mit einem Fehler endete oder ob die Installation erfolgreich war. Den Status der Installation findest du in der Registry: “HKLMSOFTWAREMicrosoftIntuneManagementExtensionWin32Appsuserappid“.
Anschließend wird geprüft, ob für die Anwendung ein Neustart erforderlich ist. Dies wurde ebenfalls beim Erstellen der App in Intune definiert.
App Detection
Wie schon vor der App-Installation wird die App Detection nach der App-Installation erneut ausgeführt, um zu prüfen, ob die App anhand der konfigurierten Kriterien nach der Installation erkannt wird. In meinem Fall wurde die App erkannt.
Abschluss der Installation
Last but not least ist die App-Installation nun abgeschlossen. Dies ist in zwei Phasen unterteilt. Die eine ist das Setzen des Compliance-Status und die andere das Zurückmelden des Status an Intune.
In der Compliance-Phase wird die Compliance anhand des Status der Installation und der App Detection geprüft. Dieser Compliance-Status wird in die Registry geschrieben unter: “HKLMSOFTWAREMicrosoftIntuneManagementExtensionWin32AppsuserappidComplianceStateMessage“. Wenn dies erledigt ist, wird der Inhalt von “C:Program Files (x86)Microsoft Intune Management ExtensionContentIncoming” gelöscht.
In der allerletzten Phase wird ein Report der Installation lokal gespeichert und an Intune gesendet. Zusätzlich wird auch der IMECache in “C:WindowsIMECache” bereinigt, um die Installation endgültig abzuschließen.
Wie oft wird eine Installation bei einem Fehler wiederholt
Die Installation wird 3-mal wiederholt. Zwischen den Versuchen müssen jedoch mindestens 5 Minuten liegen. Wenn alle diese 3 Versuche fehlschlagen, landet die App in der GRS (Re-evaluation Schedule). Das bedeutet, die IME wartet 24 h, bis sie den nächsten Versuch unternimmt, die App zu installieren. Du siehst das im Log an dieser Zeile:
„is still in GRS. GRS start time is <date> <time>“
Gründe könnten sein:
- Fehlerhaftes App-Paket
- Probleme auf dem Client während der Installation
Wie kann ich einen neuen Installationsversuch für eine App starten, die sich in der GRS befindet?
Um direkt einen neuen Installationsversuch einer App zu starten, kannst du den Key der Anwendung im folgenden Registry-Pfad löschen:
- „HKEY_LOCAL_MACHINESOFTWAREMicrosoftIntuneManagementExtensionWin32AppsSIDAppGuid“
- „HKEY_LOCAL_MACHINESOFTWAREMicrosoftIntuneManagementExtensionWin32AppsSIDGRSAppId“
Wenn du den Key der App gelöscht hast, starte dann den IME-Prozess neu, und ein neuer Installationsversuch sollte starten.
Shout-out an Florian Salzmann für sein Skript, das dir diese Arbeit abnimmt:
Auslösen einer IME-Synchronisierung
Der einfachste Weg, eine Synchronisierung der IME auszulösen, ist, den Prozess neu zu starten. Öffne den Task-Manager und navigiere zu Dienste und suche nach Intune Management Extension. Klicke mit der rechten Maustaste auf den Prozess und klicke auf Neu starten.
Es gibt aber auch einige andere Möglichkeiten, dies zu tun. Die erste Möglichkeit ist, die Synchronisierung über PowerShell auszulösen. Wenn du dir den Code der IME ansiehst, siehst du, dass es zwei mögliche Argumente zum Auslösen einer Synchronisierung gibt. Das sind URL-Monikers.
In der Registry (HKLMSOFTWAREClasses) findest du die Aktion intunemanagementextension. Wenn du diese Aktion aufrufst, kannst du hinter dem Aktionsnamen :// hinzufügen, um das Argument syncapp oder synccompliance zu übergeben.
Um dies über PowerShell zu tun, kannst du den folgenden Befehl verwenden:
Apps synchronisieren:
$syncIme = New-Object -ComObject Shell.Application
$syncIme.open("intunemanagementextension://syncapp")Compliance synchronisieren:
$syncIme = New-Object -ComObject Shell.Application
$syncIme.open("intunemanagementextension://synccompliance").Oder du kannst die Synchronisierung über das Company Portal auslösen:
Apps synchronisieren:
Compliance synchronisieren:
Wo die IME Spuren auf dem System hinterlässt
Registry
Ein wichtiger Pfad in der Registry, der immer helfen kann, ist: “HKLMSOFTWAREMicrosoftIntuneManagementExtension“
Hier findest du zum Beispiel das Inventar aller Apps, die auf deinem System installiert sind. Dieses Inventar findest du dann in Intune unter Discovered Apps.
Du findest in diesem Pfad auch die Inventory-Einstellungen. Hier findest du z. B. den Zeitpunkt, wann der letzte vollständige Sync stattgefunden hat.
Aber du findest hier noch viel mehr Infos.
Ordner
Wie bereits oben erwähnt, finden sich die Logdateien im folgenden Ordner: C:ProgramDataMicrosoftIntuneManagementExtensionLogs
Der wichtigste Ordner ist aber dieser: C:Program Files (x86)Microsoft Intune Management Extension.
Dies ist der Speicherort der Microsoft.Management.Services.IntuneWindowsAgent.exe.
Geplante Tasks
Im Task-Scheduler findest du einen Task mit dem Namen Intune Management Extension Health Evaluation. Der Task läuft einmal täglich und die Aktion ist das Ausführen der (C:Program Files (x86)Microsoft Intune Management ExtensionClientHealthEval.exe)
Der Job ist sehr einfach, er prüft, ob der IME-Dienst wie vorgesehen läuft oder nicht. Was der Task im Detail macht, siehst du in der HealthCheck.xml. Er prüft, ob der Dienst existiert, wie der Startup-Typ und der Status geprüft werden und wie die Speicherauslastung ist. Wenn eine Prüfung nicht so ist, wie sie sein sollte, wird eine Remediation ausgeführt. Das Ergebnis des letzten Laufs siehst du in der HealthReport.json.
Remediation
Bevor wir auf dieses Thema eingehen, habe ich einen Fun Fact für dich. Custom-Compliance-Skripte sind im Hintergrund nur Remediation-Skripte, die eine feste Laufzeit von alle 8 Stunden haben.
Remediation-Skripte durchlaufen einen ähnlichen Prozess wie oben beschrieben. Die Skripte werden in den folgenden Ordner heruntergeladen:
- C:WindowsIMECacheHealthScripts
Stelle sicher, dass du in deinem Skript keine Secrets verwendest, denn wenn der Benutzer schnell ist, kann er die Skripte und das Secret sehen. Du findest in der Registry außerdem die Historie und den Status der Ausführungen in diesem Pfad:
- HKEY_LOCAL_MACHINESOFTWAREMicrosoftIntuneManagementExtensionSideCarPoliciesScripts
- HKLM:SOFTWAREMicrosoftIntuneManagementExtensionSideCarPoliciesScriptsReports<USER_GUID><SCRIPT_ID>
Weitere lesenswerte Beiträge zur IME
- Triggering Intune Management Extension (IME) Sync – (Oliver Kieselbach)
- Retry Lola Retry – (Rudy Ooms)
Fazit
Ich hoffe, dieser Blogbeitrag hat dir einen Blick hinter die Kulissen der Intune Management Extension gegeben. Wie bei jedem Blogbeitrag versuche ich, diesen aktuell zu halten und den Blog laufend zu aktualisieren. Danke, dass du meinen Blogbeitrag gelesen hast.
Bleib gesund, Cheers
Jannik
Great job! This was really well explained, keep up the great work!
Many thanks man 🙂
Thanks for a very informative article.