Sektion 46: Intune Management Extension (IME): Was im Hintergrund passiert

Mit Sektion 45 haben wir den Block App-Management abgeschlossen. Jetzt schauen wir unter die Haube. Fast alles, was wir bisher an Win32-Apps verteilt haben, läuft auf dem Gerät nicht über den klassischen Windows-MDM-Client, sondern über einen eigenen Agenten: die Intune Management Extension, kurz IME.

Wer die IME versteht, findet Fehler deutlich schneller. Sie entscheidet, wann ein Gerät nach neuen Apps und Skripts fragt, wo Installationsdateien landen und welche Logdatei Ihnen bei welchem Problem weiterhilft. In dieser Sektion sehen wir uns an, was die IME tut, wann sie eincheckt, wie Sie einen Sync auslösen und wie Sie mit PowerShell schnell an die wichtigsten Informationen kommen. Damit legen wir auch die Grundlage für die nächsten Sektionen rund um PowerShell-Skripts und Remediations.

Grundlagen: Was die IME eigentlich ist

Ein Agent, der Windows-MDM ergänzt

Microsoft beschreibt die IME als Installationsprogramm-Agent, der die Windows-Geräteverwaltung (MDM) erweitert. Sie ergänzt das eingebaute MDM von Windows um Funktionen wie Win32-Apps, PowerShell-Skripts und Remediations. Sie läuft auf dem Gerät als Windows-Dienst mit dem Namen IntuneManagementExtension (Anzeigename „Microsoft Intune Management Extension“) und taucht nicht im Startmenü auf.

Wann die IME auf ein Gerät kommt

Sie installieren die IME nicht selbst. Intune bringt sie automatisch auf das Gerät, sobald dem Benutzer oder Gerät eine Funktion zugewiesen wird, die sie braucht. Laut Microsoft Learn sind das unter anderem:

• PowerShell-Skripts (Plattformskripts)
• Win32-Apps
• Korrekturen (Remediations), siehe auch Intune Remediations
• Ermittlungsskripts für benutzerdefinierte Compliance
• Endpunktanalyse und Remotehilfe
• Verwaltete Installationsprogramme in Intune
• BIOS-Konfiguration über die MDM-Konfigurationsrichtlinie

Microsoft weist ausdrücklich darauf hin, dass die automatische Installation durch Intune der einzige unterstützte Weg ist. Eine manuelle Installation, ein eigenes Skript oder ein umgepacktes IME-Paket sind nicht vorgesehen.

Voraussetzungen

• Eine unterstützte Windows-Version. Windows Home und Windows im S-Modus werden nicht unterstützt. Beim S-Modus liegt das daran, dass er keine Nicht-Store-Apps zulässt.
• Das Gerät ist in Intune registriert und mit Microsoft Entra ID verbunden (Entra Join, Entra Hybrid Join oder Entra-registriert).
• Bei Co-Management mit Configuration Manager muss der Workload „Apps“ für Win32-Apps auf „Pilot Intune“ oder „Intune“ stehen. PowerShell-Skripts laufen auch, wenn der Workload beim Configuration Manager liegt.
• Hinter Firewall oder Proxy müssen die Intune-Endpunkte für PowerShell-Skripts und Win32-Apps erreichbar sein.
• Wichtig ist die Mindestversion: Auf den Geräten muss IME 1.58.103.0 oder höher laufen. Ältere Versionen bekommen keine Win32-Apps, PowerShell-Skripts oder Korrekturen mehr. Da sich die IME selbst aktualisiert, ist das meist kein Thema, solange die Geräte regelmäßig synchronisieren.

Was im Hintergrund passiert

Der Check-in-Zyklus

Der wichtigste Punkt zuerst: Die IME hat einen eigenen Check-in, unabhängig vom MDM-Check-in von Windows. Laut Microsoft läuft er so ab:

• Die IME authentifiziert sich bei den Intune-Diensten und fragt dann die zugewiesenen Installationen ab.
• Sie prüft alle 8 Stunden auf neue oder geänderte Zuweisungen.
• Nach einem Neustart des Geräts oder des IME-Dienstes sucht sie ebenfalls nach neuen Skripts.
• Direkt nach Abschluss der Registrierungsstatusseite (ESP) oder von Autopilot Device Preparation prüft sie sofort auf neue App-Zuweisungen. So kommen Required-Apps, die während der Bereitstellung nicht installiert wurden, schneller aufs Gerät.
• Zusätzlich führt sie regelmäßig Integritätsprüfungen durch, um die Verbindung zu Intune zu kontrollieren.

Für Korrekturen nennt Microsoft eigene Abrufzeitpunkte: nach einem Neustart des Geräts oder des IME-Dienstes, nach einer Benutzeranmeldung und einmal alle 8 Stunden. Der 8-Stunden-Takt richtet sich danach, wann der IME-Dienst gestartet wurde. Benutzeranmeldungen verschieben ihn nicht.

Was die IME mit den Zuweisungen macht

• Win32-Apps: Die IME prüft Anforderungen und Erkennungsregeln, lädt den Inhalt herunter, führt Ihren Installationsbefehl aus und meldet das Ergebnis. Wie Erkennungsregeln funktionieren, steht in Sektion 33: Detection Methods.
• PowerShell-Skripts: Ein Skript wird nach der Ausführung nicht wieder gestartet, außer Sie ändern das Skript oder die Richtlinie. Gerätebezogen zugewiesene Skripts laufen zusätzlich für jeden neuen Benutzer, der sich anmeldet, aber nicht bei jeder Anmeldung desselben Benutzers. Schlägt es fehl, versucht die IME es bei den nächsten drei Check-ins erneut. Nach 30 Minuten bricht die IME ein Skript mit Timeout ab.
• Reihenfolge: Beim Start verarbeitet die IME zuerst PowerShell-Skripts und beginnt danach mit den Win32-Apps. Das ist aber keine Garantie: Ein Skript muss nicht fertig sein, bevor eine App startet, und andere Auslöser können Apps unabhängig anstoßen. Braucht eine App eine Voraussetzung, gehört die in die Win32-App-Bereitstellung, nicht in ein separates Plattformskript.
• Benutzerdefinierte Compliance: Die IME lädt die Ermittlungsskripts herunter, führt sie alle acht Stunden aus und lädt die Ergebnisse in Intune hoch.
• Remediations: Der IME-Dienst holt die Skriptpakete aus Intune und führt sie nach dem konfigurierten Zeitplan aus (einmal, stündlich oder täglich).

Wichtige Ordner auf dem Gerät

• C:\Program Files (x86)\Microsoft Intune Management Extension: Programmdateien der IME auf x64-Geräten, inklusive AgentExecutor.exe.
• C:\Program Files (x86)\Microsoft Intune Management Extension\Content und C:\Windows\IMECache: Arbeitsordner für Win32-App-Inhalte. Microsoft empfiehlt, diese Ordner vom Virenscan auszuschließen (auf x86-Geräten liegt der Content-Ordner unter C:\Program Files).
• C:\ProgramData\Microsoft\IntuneManagementExtension\Logs: alle IME-Logdateien.

Die Logdateien der IME

Microsoft empfiehlt, die Logs mit CMTrace.exe zu lesen. Für einen schnellen Blick reicht aber auch PowerShell. Die wichtigsten Dateien laut Microsoft Learn:

• IntuneManagementExtension.log: das Hauptlog mit Check-ins, Richtlinienabfragen, Verarbeitung und Berichterstattung. Nach einem Rollover liegt die alte Version als _IntuneManagementExtension.log daneben.
• AppWorkload.log: das zentrale Log für Win32-Apps: App-Check-in, Installation, Anwendbarkeit und Erkennung. Für App-Probleme ist das Ihre erste Anlaufstelle.
• AppActionProcessor.log: Erkennung und Anwendbarkeitsprüfung der zugewiesenen Apps.
• AgentExecutor.log: Ausführung der PowerShell-Skripts aus Intune.
• HealthScripts.log: Remediations und alle Funktionen, die darauf aufbauen, etwa benutzerdefinierte Compliance-Skripts.
• ClientHealth.log: Integrität der IME selbst.
• ClientCertCheck.log, DeviceHealthMonitoring.log, NotificationInfra.log, Sensor.log, Win32AppInventory.log: Zertifikatsprüfung, Datensammler, Benachrichtigungen, Endpunktanalyse und App-Inventar.

Wenn Sie nicht direkt am Gerät sitzen, können Sie bei einer fehlgeschlagenen Win32-App im Intune Admin Center in den Installationsdetails auch Protokolle sammeln wählen.

Praxis: Die IME mit PowerShell prüfen

Die folgenden Befehle ändern nichts am Gerät, außer dem Neustart des Dienstes in Schritt 4. Öffnen Sie für alle Beispiele eine PowerShell als Administrator.

1. Läuft der Dienst?

Get-Service -Name IntuneManagementExtension |
    Select-Object Name, DisplayName, Status, StartType

Erwartet wird Status Running. Microsoft weist darauf hin: Steht der Dienst auf Manual, startet er nach einem Neustart des Geräts unter Umständen nicht wieder, und neue Skripts kommen dann nicht an. Liefert der Befehl einen Fehler, ist die IME gar nicht installiert. Dann prüfen Sie die Voraussetzungen von oben und ob dem Gerät oder Benutzer überhaupt eine Win32-App oder ein Skript zugewiesen ist.

2. Welche IME-Version ist installiert?

$ime = Join-Path ${env:ProgramFiles(x86)} 'Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe'
if (Test-Path $ime) {
    $version = [version](Get-Item $ime).VersionInfo.FileVersion
    "IME-Version: $version"
    if ($version -lt [version]'1.58.103.0') { 'Achtung: älter als 1.58.103.0' }
} else {
    'IME nicht gefunden'
}

Der Befehl liest die Dateiversion des IME-Agenten aus und vergleicht sie mit der von Microsoft genannten Mindestversion. Der Cast auf [version] sorgt dafür, dass PowerShell Versionsnummern korrekt vergleicht und nicht als Text.

3. Logs live mitlesen

$logs = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'

# Welche Logs wurden zuletzt geschrieben?
Get-ChildItem -Path $logs -Filter *.log |
    Sort-Object LastWriteTime -Descending |
    Select-Object Name, Length, LastWriteTime

# AppWorkload.log live verfolgen (Strg+C beendet)
Get-Content -Path "$logs\AppWorkload.log" -Tail 30 -Wait

-Tail 30 zeigt die letzten 30 Zeilen, -Wait hält die Datei offen und gibt neue Zeilen aus, sobald die IME sie schreibt. Das ist ideal, während Sie parallel einen Sync auslösen. Wollen Sie nur Fehlermeldungen sehen, hängen Sie einen Filter an:

Get-Content -Path 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log' -Tail 200 -Wait |
    Select-String -Pattern 'error|fail'

Select-String arbeitet hier mit einem regulären Ausdruck und ignoriert Groß- und Kleinschreibung. Suchen Sie eine bestimmte App, ersetzen Sie das Muster durch ihren Namen oder ihre App-ID. So finden Sie alle Zeilen zu genau dieser Zuweisung.

4. Check-in auslösen

Microsoft nennt zwei Wege, einen IME-Check-in direkt am Gerät anzustoßen:

• Im Unternehmensportal unter Einstellungen > Synchronisierung. Das löst einen MDM-Check-in und einen IME-Check-in aus. Dasselbe gilt für Synchronisieren in der Einstellungen-App oder für die Geräteaktion im Intune Admin Center.
• Den Dienst IntuneManagementExtension neu starten. Er startet sofort neu und checkt danach bei Intune ein.

Restart-Service -Name IntuneManagementExtension -Force
Get-Service -Name IntuneManagementExtension | Select-Object Name, Status

Der Neustart des Dienstes ist der schnellste Weg, wenn Sie gerade eine neue Zuweisung testen. Lassen Sie in einem zweiten Fenster Get-Content -Wait auf IntuneManagementExtension.log laufen, dann sehen Sie den Check-in direkt. Beachten Sie: Der Dienstneustart betrifft nur die IME. Geht es auch um Konfigurationsprofile, nutzen Sie den normalen Sync, der laut Microsoft MDM- und IME-Check-in gemeinsam auslöst.

5. Lokalen Win32-App-Status in der Registry ansehen

Die IME speichert den Verarbeitungsstand der Win32-Apps unter HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps. Dieser Schlüssel ist nicht in der regulären Produktdokumentation beschrieben, wird aber in einer Antwort auf Microsoft Q&A als Teil eines Reset-Vorgehens genannt. Die Unterschlüssel sind nach Benutzer- bzw. App-IDs benannt. Zum reinen Lesen reicht:

$base = 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps'
Get-ChildItem -Path $base | Select-Object PSChildName

# Unterschlüssel eines Eintrags anzeigen (ID aus der Liste oben einsetzen)
Get-ChildItem -Path "$base\<ID>" | Select-Object PSChildName

Nutzen Sie die Registry hier nur zur Diagnose. Das Löschen von Schlüsseln, um eine Neuinstallation zu erzwingen, ist kein offiziell dokumentierter Weg. Das gehört höchstens auf ein Testgerät, nie in einen Massen-Rollout.

Troubleshooting: Typische Probleme

Die IME wird gar nicht installiert

• Das Gerät ist nicht mit Entra ID verbunden oder nicht in Intune registriert.
• Dem Benutzer oder Gerät ist keine Funktion zugewiesen, die die IME braucht, zum Beispiel keine Win32-App und kein Skript.
• Das Gerät kann nicht einchecken, etwa ohne Internetzugang oder ohne Zugriff auf den Windows-Pushbenachrichtigungsdienst (WNS).
• Windows läuft im S-Modus.
• Ist der Proxy nur pro Benutzer gesetzt, muss ein Benutzer angemeldet sein. Alternativ setzen Sie den Proxy für BITS mit bitsadmin /util /setieproxy.
• Die Konfigurationsdatei Microsoft.Management.Services.IntuneWindowsAgent.exe.config im IME-Programmordner wurde manuell geändert oder ist beschädigt.

Win32-App kommt nicht an

1. Dienststatus und IME-Version prüfen (Befehle 1 und 2).
2. Check-in per Dienstneustart auslösen und AppWorkload.log live mitlesen.
3. Im Log nach der App-ID suchen: Wird die App überhaupt empfangen? Scheitert sie an Anforderungen, an der Erkennung oder an der Installation selbst? Mehr dazu in Sektion 41: App Deployment Troubleshooting.
4. Zuweisung und Assignment Filter im Admin Center prüfen, wie in Sektion 45 beschrieben.
5. Bei benutzerbezogenen Zuweisungen bedenken: Braucht die App Administratorrechte, schlägt die Installation im Benutzerkontext fehl.

PowerShell-Skript läuft nicht oder meldet falschen Status

• Ein Skript läuft nicht bei jeder Anmeldung: nach dem ersten Lauf erst wieder nach einer Änderung, bei gerätebezogener Zuweisung zusätzlich einmal für jeden neuen Benutzer. Nach drei Fehlversuchen probiert die IME es ohne Änderung nicht mehr.
• Geräte, die nur Entra-registriert sind (Workplace Join), bekommen Skripts nur über Gerätegruppen. Benutzerzuweisungen werden dort ignoriert.
• Ist die Systemuhr des Geräts um Monate oder Jahre falsch, laufen Skripts nicht.
• Meldet ein Skript Erfolg, hat aber nichts getan, kann eine Antivirenlösung den AgentExecutor einschränken. Prüfen Sie dann AgentExecutor.log.
• Achten Sie auf den 64-Bit-Schalter: Standardmäßig startet die IME Skripts im 32-Bit-PowerShell-Host. Zugriffe auf HKLM:\SOFTWARE können dann durch die 32-Bit-Umleitung von Windows im Zweig WOW6432Node landen. Brauchen Sie 64-Bit, aktivieren Sie die Option „Skript im 64-Bit-PowerShell-Host ausführen“.

Gerät nicht mehr verwaltet, Skripts laufen trotzdem

Das ist erwartetes Verhalten. Die IME merkt erst beim nächsten eigenen Check-in, in der Regel alle 8 Stunden, dass das Gerät nicht mehr verwaltet wird. Bis dahin können lokal gespeicherte Skripts noch laufen. Kann die IME nicht einchecken, versucht sie es bis zu 24 Stunden (Wachzeit des Geräts) und entfernt sich dann selbst.

Best Practices

• Beim Testen neuer Apps oder Skripts den IME-Dienst neu starten, statt auf den 8-Stunden-Zyklus zu warten.
• Für Win32-Apps immer zuerst AppWorkload.log öffnen, für Skripts AgentExecutor.log, für Remediations HealthScripts.log.
• Den Starttyp des Dienstes nicht verändern und die IME nie manuell installieren oder umpacken.
• Die Ordner Content und IMECache in der Antivirenlösung ausschließen, wie Microsoft es empfiehlt.
• Keine Kennwörter oder personenbezogenen Daten in Skripts ablegen. Die IME lädt sie auf jedes Zielgerät.

Fazit

Die Intune Management Extension ist der Motor hinter Win32-Apps, PowerShell-Skripts, Remediations und benutzerdefinierter Compliance. Sie arbeitet mit einem eigenen Check-in, unabhängig vom MDM-Sync, und schreibt sehr ausführliche Logs. Wer weiß, welches Log zu welcher Funktion gehört und wie man einen Check-in auslöst, löst die meisten Client-Probleme in wenigen Minuten.

Zusammenfassend für Ihren Workflow:

• Dienst IntuneManagementExtension prüfen: läuft er, und ist die Version aktuell?
• Check-in per Unternehmensportal oder Dienstneustart auslösen.
• Passendes Log live mitlesen und nach der App- oder Skript-ID suchen.
• Registry nur lesen, nicht manipulieren.

In der nächsten Sektion geht es um PowerShell-Skripts in Intune: Bereitstellung, Ausführungskontext und Ergebnisse. Einen Überblick über alle Sektionen finden Sie auf der Seite Intune-Kurs.

Quellen

• Microsoft Learn: Grundlegendes zur Microsoft Intune Management Extension
• Microsoft Learn: Hinzufügen von PowerShell-Skripts zu Windows-Geräten in Microsoft Intune
• Microsoft Learn: Problembehandlung bei Win32-Apps in Microsoft Intune
• Microsoft Learn: Win32-App-Verwaltung in Microsoft Intune
• Microsoft Learn: Verwenden von Korrekturmaßnahmen (Remediations)
• Microsoft Learn: Benutzerdefinierte Complianceeinstellungen in Microsoft Intune
• Microsoft Q&A: Win32-App-Status nach Änderung der Erkennungsmethode neu prüfen

↑ Zur Kursübersicht: Intune-Kurs (alle Sektionen)