Intune-Verwaltungskanäle: MDM, IME und MMP-C

Diese Referenz erklärt die Windows-Komponenten hinter der Intune-Verwaltung. Für die systematische Fehlersuche und häufige Fehlercodes nutze den Intune-Troubleshooting-Ablauf.

Die technischen Details enthalten Community-Recherchen von Rudy Ooms, Oliver Kieselbach und Michael Niehaus. Prüfe das Verhalten mit deinem Windows-Build und unterscheide die verlinkten Community-Ergebnisse von der Microsoft-Dokumentation.

Intune Troubleshooting beginnt hier: wie Intune unter der Haube tatsächlich funktioniert

Bevor du irgendetwas troubleshootest, musst du wissen, wer was ausliefert. Fast jede Intune-Troubleshooting-Session, die schiefgeht, geht genau hier schief: Unter Windows gibt es zwei getrennte Kanäle, die fast nichts miteinander zu tun haben, und die meiste Verwirrung, die ich sehe, kommt daher, dass Leute nicht wissen, welcher Kanal für ihre Einstellung zuständig ist.

Kanal 1 — der native MDM-Kanal. Dieser ist in Windows eingebaut. Intune spricht mit dem Gerät über das OMA-DM-Protokoll, und die Nachrichten sind SyncML (XML). Das Gerät bekommt keine rohen Registry-Schlüssel. Stattdessen wird jede Einstellung auf einen Configuration Service Provider (CSP) abgebildet — eine kleine Schnittstelle in Windows, die weiß, wie man diese eine Einstellung anwendet. Profile, Compliance, Zertifikate und WLAN kommen alle über diesen Kanal.

Kanal 2 — die Intune Management Extension (IME). Das ist ein echter Agent (der alte Name war der „Sidecar”-Agent). Er wird automatisch installiert, sobald du zum ersten Mal eine Win32-App, ein PowerShell-Skript, eine Remediation oder ein Custom-Compliance-Skript zuweist. Er erledigt die Dinge, die der native MDM-Kanal nicht kann. Er hat seinen eigenen Dienst (IntuneManagementExtension) und seine eigene Uhr, unabhängig vom MDM-Check-in.

Hinweis: Das ist die nützlichste Intune-Troubleshooting-Gewohnheit, die du verinnerlichen solltest. Wenn ein Konfigurationsprofil kaputt ist, schaust du dir den MDM-Kanal und den Event Viewer an. Wenn eine Win32-App oder ein Skript kaputt ist, schaust du dir die IME und ihre Logs an. Zwei Probleme, zwei Orte.

Wie funktionieren CSPs wirklich?

Das lohnt sich, richtig zu verstehen, denn es erklärt die Fehlercodes später und macht Intune Troubleshooting deutlich weniger zu Ratespiel. Ein CSP ist die Brücke zwischen dem SyncML-Befehl, den Intune sendet, und der tatsächlichen Windows-Einstellung. Der Befehl zielt auf eine OMA-URI (auch LocURI genannt) — ein Pfad wie:

./Device/Vendor/MSFT/Policy/Config/<Area>/<PolicyName>

Fürs Intune Troubleshooting entscheidet der allererste Teil über den Geltungsbereich: ./Device für eine Geräteeinstellung, ./User für eine Benutzereinstellung. Gibt es kein Präfix, behandelt Windows es standardmäßig als gerätebezogen.

Der Policy CSP ist das Arbeitspferd für die meisten Einstellungen, und er hat ein Detail, das beim Troubleshooting enorm hilft: Er hat einen Config-Pfad (lesen/schreiben — wo Intune den Wert setzt) und einen Result-Pfad (nur lesen — wo du den konfliktaufgelösten Wert ausliest, den das Gerät tatsächlich angewendet hat). Wenn also zwei Quellen um eine Einstellung streiten, sagt dir der Result-Pfad, wer gewonnen hat.

Wenn Intune ein Settings-Catalog-Profil sendet, wird jede Einstellung zu einem SyncML-Befehl — meist einem Replace (einen Wert setzen), einem Add (einen Knoten erstellen) oder einem Delete (ihn entfernen). „Not configured” ist buchstäblich ein Delete. Microsoft empfiehlt, jede Einstellung in einen Atomic-Block zu verpacken, damit sie als eine einzige Transaktion angewendet wird. Der Befehl sieht auf der Leitung so aus:

<Replace>
  <CmdID>2</CmdID>
  <Item>
    <Meta><Format>chr</Format><Type>text/plain</Type></Meta>
    <Target><LocURI>./Device/Vendor/MSFT/Policy/Config/AppVirtualization/AllowAppVClient</LocURI></Target>
    <Data><Enabled/></Data>
  </Item>
</Replace>

Tipp: Du kannst diese Befehle live mitverfolgen mit Oliver Kieselbachs SyncML Viewer. Er traced die MDM-Session und zeigt dir das exakte XML, das der Client gesendet und empfangen hat. Es ist der schnellste Weg, zu beweisen, ob eine Einstellung tatsächlich ausgeliefert oder stillschweigend verworfen wurde.

Wie oft checkt ein Gerät ein?

Microsoft gibt an, dass der Wartungs-Check-in etwa alle 8 Stunden passiert, und die IME checkt zusätzlich nach ihrem eigenen Zeitplan ein. Aber so lange wartest du selten. Wenn du etwas zuweist oder auf Sync drückst, sendet Intune eine Windows-Push-Notification-Service(WNS)-Benachrichtigung, die einen nahezu sofortigen Check-in auslöst. Der berühmte „8-Stunden-Sync” ist also irreführend — gezielte Änderungen werden fast sofort gepusht, und das ist das Erste, was ich in jedem Intune-Troubleshooting-Fall bestätige, bevor ich annehme, dass etwas kaputt ist.

Fürs Intune Troubleshooting ist der Auslöser auf dem Gerät ein Satz geplanter Tasks, die beim Enrollment unter Task Scheduler Library > Microsoft > Windows > EnterpriseMgmt > \{EnrollmentGUID\} erstellt werden. Der wichtigste ist PushLaunch, der auf den WNS-Push reagiert und eine OMA-DM-Session startet.

Tipp: Ein LastTaskResult von 0x82AC0204 beim PushLaunch-Task ist kein Fehler. Es bedeutet nur „in der Warteschlange, wird später ausgeführt”. Ich habe Leute gesehen, die das eine Stunde lang gejagt haben.

MMP-C und Declared Configuration: das zweite Gehirn, das Intune Troubleshooting jetzt abdecken muss

Hier ist der Teil, der die meisten Admins überrascht und Intune Troubleshooting zunehmend ins Stolpern bringt: Auf einem modernen, vollständig gepatchten Windows-Gerät läuft jetzt ein zweites Enrollment leise neben dem klassischen. Falls du noch nichts von MMP-C gehört hast, wirst du es bald — es ist bereits auf deinen Geräten.

MMP-C steht für Microsoft Management Platform – Cloud. Es ist eine neue Cloud-Management-Ebene, die neben — nicht anstelle von — dem klassischen Intune/OMA-DM-Kanal läuft. Sie existiert, um Windows Declared Configuration (WinDC) zu transportieren, eine neue Art, Policy auszuliefern.

Der Unterschied zwischen den beiden Modellen ist der ganze Punkt:

• Der klassische OMA-DM-Kanal ist imperativ. Der Server erteilt Befehle einen nach dem anderen — get, set, get — und prüft das Ergebnis erst beim nächsten Sync. Wenn die Einstellung dazwischen abdriftet, passiert nichts, bis das Gerät erneut eincheckt.
• Declared Configuration ist deklarativ und idempotent (denk an Windows DSC). Der Server sendet den gesamten gewünschten Zustand in einem Batch pro Szenario, der Client validiert ihn synchron, und das Gerät selbst ist dafür verantwortlich, ihn so zu halten. Wenn eine Einstellung abdriftet, wendet das Gerät sie eigenständig erneut an — nicht-destruktiv. Das ist dieselbe Desired-State-Idee, die Apple für sein deklaratives Device Management nutzt.

Microsoft sagt klar, dass WinDC ein separates OMA-DM-Enrollment erfordert, das davon abhängt, dass das Gerät bereits bei einem primären MDM-Server enrolled ist. Ein verwaltetes Gerät hat jetzt also zwei Enrollments: das klassische (den „MS DM Server”, über *.manage.microsoft.com) und ein verknüpftes zweites für Declared Configuration (über die *.dm.microsoft.com-Endpunkte).

Was löst es aus, und was läuft darauf?

Das verknüpfte Enrollment tauchte erstmals mit Endpoint Privilege Management (EPM) auf, das nach wie vor der Flaggschiff-Workload ist. Aber die große Änderung ist Windows Advanced Device Inventory (der Properties Catalog) — weil dieses Feature auf MMP-C läuft, wird das Dual Enrollment jetzt praktisch auf alle verwalteten Geräte ausgerollt, ohne dass du irgendetwas tust. Resource-Access-Policies (WLAN, VPN und Zertifikate) ziehen ebenfalls um.

Microsoft hat signalisiert, dass Security Baselines, Defender-Einstellungen und Account Protection auf derselben Pipeline liegen — aber zum Zeitpunkt des Schreibens ist keines davon auf dem Declared-Configuration-Kanal als generell verfügbar bestätigt, also behandle ich sie als „kommt, ist aber noch nicht da”. Diese Unterscheidung ist fürs Intune Troubleshooting wichtig: Wenn sich eine Baseline heute danebenbenimmt, reist sie immer noch über den klassischen OMA-DM-Kanal, nicht über WinDC. Das ist die Marschrichtung für Windows-Management, aber lies den Kanal, bevor du das Log liest.

Hinweis: Das Akronym, die Enrollment-„Type”-Nummern, die *.dm.microsoft.com-Hostnamen und die unten genannte 4-Stunden-Frequenz wurden von Rudy Ooms (call4cloud) reverse engineered, nicht von Microsoft veröffentlicht. Das Desired-State-Modell, die Anforderung eines dedizierten Enrollments und das Refresh-Intervall sind dokumentiert. Ich trenne die beiden, damit du weißt, worauf du dich verlassen kannst.

Wie funktioniert es, und wie sehe ich es auf einem Gerät?

Das zweite Enrollment wird über neue LinkedEnrollment-Knoten am DMClient CSP eingerichtet — du setzt einen DiscoveryEndpoint und führst dann ein Exec auf einem Enroll aus. Auf dem Gerät heißt das verknüpfte OMA-DM-Enrollment MicrosoftManagementPlatformCloud, dieser String in der Registry oder in einem Log ist also deine Bestätigung, dass MMP-C aktiv ist. Die Engine, die Declared-Configuration-Dokumente verarbeitet, läuft als Windows-Dienst dcsvc (gestützt auf dcsvc.dll), und ein geplanter Task führt deviceenroller.exe /DeclaredConfigurationRefresh aus, um Drift abzugleichen — standardmäßig etwa alle 4 Stunden (der klassische MDM-Kanal alle 8). Das Refresh-Intervall ist über DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval konfigurierbar. MMP-C ist also nicht nur ein anderes Modell, es checkt auch doppelt so oft ein.

Der erste Intune-Troubleshooting-Schritt für MMP-C ist, es auf einem Gerät zu bestätigen, indem du die Registry öffnest:

HKLM\SOFTWARE\Microsoft\Enrollments

Du wirst nun zwei Enrollment-GUIDs sehen. Unter dem klassischen Intune-Enrollment gibt es einen LinkedEnrollment-Unterschlüssel mit Werten wie EnrollStatus, LastError und MMPCLocked. Die zweite GUID ist das MMP-C-Enrollment selbst, mit seinem eigenen Ordner unter EnterpriseMgmt im Task Scheduler.

Tipp: Declared Configuration bekommt kein eigenes Event-Viewer-Log. Seine Events reisen innerhalb der normalen DeviceManagement-Enterprise-Diagnostics-Provider-Kanäle — achte auf Zeilen, die MDM Declared Configuration: oder Provider Name: (DeclaredConfiguration) sagen. Auf die MMP-C-Fehler, die ich am häufigsten sehe, komme ich später im Guide zurück.

Identität und Intune Troubleshooting: wie ein Gerät beweist, wer es ist

Ein riesiger Anteil der „Intune ist kaputt”-Tickets sind in Wirklichkeit Identitätsprobleme, deshalb endet viel Intune Troubleshooting tatsächlich bei der Identität — das Gerät kann nicht beweisen, wer es ist, also scheitern Sync, Enrollment oder Conditional Access. Es lohnt sich also, die Identitätsschicht zu verstehen. Dein erster Befehl, immer, ist:

dsregcmd /status

Lies drei Abschnitte (Microsoft dokumentiert jedes Feld in der dsregcmd-Troubleshooting-Referenz):

• Device State — das Erste, was ich beim Identitäts-Intune-Troubleshooting prüfe: AzureAdJoined, DomainJoined, EnterpriseJoined. Die Kombination verrät dir den Join-Typ. AzureAdJoined: YES allein ist cloud-native (Entra joined); YES + DomainJoined: YES ist hybrid. (Entra registered taucht weiter unten auf, als WorkplaceJoined im User State.)
• Device Details — der Thumbprint des Gerätezertifikats und TpmProtected: YES (der private Schlüssel liegt im TPM).
• SSO State — AzureAdPrt: YES/NO, AzureAdPrtUpdateTime (wenn er älter als ~4 Stunden ist, scheitert der PRT-Refresh) und AcquirePrtDiagnostics. Das ist der Primary Refresh Token, und er ist wichtiger, als Leute denken. Tipp: Das Gerät zu sperren und wieder zu entsperren erzwingt einen PRT-Refresh-Versuch — einer der schnellsten Intune-Troubleshooting-Griffe, die es gibt.

Die zwei Zertifikate, die du nicht verwechseln darfst

Ein verwaltetes, Entra-joined-Gerät hat zwei Zertifikate, die ganz unterschiedliche Aufgaben erfüllen, und sie zu verwechseln verschwendet Stunden:

• MS-Organization-Access — das ist die Geräteidentität für Entra. Es wird ausgestellt, wenn das Gerät sich registriert, hält etwa 10 Jahre, und seine Existenz ist der Azure-AD-Join. Dieses Zertifikat verschafft dem Gerät einen PRT. Entferne es, und das Gerät ist faktisch unjoined.
• Microsoft Intune MDM Device CA — dieses authentifiziert den OMA-DM-Management-Kanal gegenüber Intune. Das ist das Zertifikat, das kaputtgeht, wenn der Sync mit 0x80190190 stirbt.

Sie scheitern unabhängig voneinander, und die beiden zu verwechseln ist einer der häufigsten Intune-Troubleshooting-Fehler. Ein Gerät kann perfekt Entra-joined mit einem gesunden PRT sein und trotzdem ein abgelaufenes MDM-Zertifikat haben, das jeden Sync blockiert. (Das Zusammenspiel dieser beiden Zertifikate und ihre OID-Details sind am besten von Rudy Ooms dokumentiert; die Entra-Geräteidentitäts-Hälfte steht auch in Microsofts eigenem Geräte-FAQ.)

Was ist der PRT, und warum macht er Dinge kaputt?

Der Primary Refresh Token (PRT) ist das zentrale Artefakt hinter Single Sign-On und eine wiederkehrende Grundursache beim Intune Troubleshooting. Microsoft beschreibt ihn als ein undurchsichtiges Blob, das an die Token-Broker auf dem Gerät ausgestellt wird. Der wichtige Teil fürs Troubleshooting ist, wie er geschützt ist:

• Bei der Registrierung erzeugt das Gerät einen Device Key und einen Transport Key, beide an das TPM gebunden.
• Entra stellt den PRT plus einen Session Key aus, der mit dem Transport Key verschlüsselt ist — sodass nur das TPM dieses Geräts ihn entschlüsseln kann. Dieser Session Key wird dann verwendet, um jede spätere Token-Anfrage zu signieren.
• CloudAP (der Cloud Authentication Provider, geladen in die LSASS) cached und erneuert den PRT alle 4 Stunden. Genau das spiegelt AzureAdPrtUpdateTime wider.

Wenn das TPM also ein Problem hat oder das Geräteobjekt gelöscht oder deaktiviert wird, kann der PRT sich nicht erneuern — und weil Geräte-Compliance-Claims für Conditional Access im PRT mitreisen, kann ein kaputter PRT in Anmelde-Prompts, CA-Blocks und Sync-Fehler gleichzeitig kaskadieren. Um tiefer zu graben, lies den SSO State in dsregcmd /status, dann den Event Viewer unter Microsoft > Windows > AAD > Operational (der PRT-Flow wird von Event 1006 Start und 1007 Ende eingerahmt).

Hinweis: Microsoft sagt ausdrücklich, dass man nicht Fiddler verwenden soll, um PRT-Traffic mitzuschneiden — nutze stattdessen netsh trace. Fiddler ist großartig für den OMA-DM-Kanal (dazu unten mehr), aber es zerstört den PRT-Flow.

Wo die Logs liegen: die Intune-Troubleshooting-Log-Map

Sobald du die Kanäle und die Identitätsschicht kennst, ergeben die Log-Speicherorte Sinn. Hier ist die Map, die ich im Kopf habe.

Vor den ausführlichen Notizen hier die Schnellreferenz, die ich angepinnt habe. Wenn jemand fragt „Wo werden Intune-Logs unter Windows gespeichert?“, ist diese Tabelle die Antwort. Alles für Apps und Skripte liegt unter C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs\\ und liest sich am besten mit CMTrace.

Die Intune-Troubleshooting-Log-Map — alles unter dem IntuneManagementExtension\Logs-Ordner.

Für Apps und Skripte (die IME): alles liegt in
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.

• IntuneManagementExtension.log — das Haupt-Log. IME-Check-ins, Policy-Anfragen, das große Ganze.
• AppWorkload.log — Win32-App-Installationsdetails. Auf neueren Builds (Service Release 2408 und später) sind die echten App-Details hierhin gewandert, also prüfe sowohl dieses als auch das Haupt-Log.
• AgentExecutor.log — die tatsächliche Ausführung von PowerShell-Skripten und Remediations, mit der Ausgabe.
• ClientHealth.log — die Gesundheit des IME-Agents selbst.

Für Profile, CSPs und Enrollment (der MDM-Kanal): öffne den Event Viewer und gehe zu
Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin.
Aktiviere den Debug-Kanal (View > Show Analytic and Debug Logs), wenn du mehr Detail brauchst. Ein paar Event-IDs, die man hier kennen sollte:

• 75 = Enrollment erfolgreich, 76 = Enrollment fehlgeschlagen (mit dem 0x8018xxxx-Code).
• 208 / 813 / 814 = OMA-DM-Session und Policy angewendet.
• 809 = eine Policy ist mit einem „Unknown Win32 error code” fehlgeschlagen — ein häufiger Intune-Troubleshooting-Hinweis — die Zeile gibt den dekodierten Fehler meist direkt mit aus.

Für Autopilot: Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot.

Wie lese ich ein IME-Log wie ein Profi?

Das IntuneManagementExtension.log roh zu lesen ist mühsam — es ist voller GUIDs, und an dieser Reibung bleibt viel Intune Troubleshooting hängen. So arbeiten die Leute, die das den ganzen Tag machen, tatsächlich:

1. Verwandle GUIDs zuerst in Namen. Nutze Petri Paavolas Get-IntuneManagementExtensionDiagnostics mit -ConvertAllKnownGuidsToClearText. Es verwandelt das Log in eine lesbare Timeline jeder App, jedes Skripts und jeder ESP-Phase, mit echten Namen statt der GUIDs. Es macht das Log ehrlich gesagt tausendmal leichter lesbar.
2. Kenne die Lifecycle-Marker, nach denen du suchst. Für Win32-Apps greppe nach [Win32App] und besonders nach GRSManager und ReevaluationScheduleManager — die verraten dir etwas über den Retry-Cooldown (dazu unten mehr). Eine Zeile, die sagt, eine App „is not expired”, bedeutet, dass sie noch in ihrem Cooldown-Fenster steckt.
3. Öffne es in einem richtigen Viewer. Nutze CMTrace oder, auf jeder Maschine ohne ConfigMgr, cmtrace.dev — die kostenlose Browser-Version, die Florian Salzmann und ich gebaut haben. Sie färbt Fehler rot, folgt der Datei live und hat eine eingebaute Fehlercode-Suche.

Tipp: Bei aktiviertem verbose IME-Logging enthält das Log sogar die Download-URL, den AES-Key und den IV, die nötig sind, um das .intunewin-Paket zu entschlüsseln — Oliver Kieselbach hat das dokumentiert. Nützlich, aber es schreibt Secrets auf die Platte, also schalte verbose Logging danach wieder aus und räume auf.

Die Intune-Troubleshooting-Tools, die ich nutze

Ich starte mein Intune Troubleshooting immer mit dem, was bereits auf dem Gerät oder im Portal vorhanden ist, und greife erst dann zu Community-Tools. Hier ist mein Werkzeugkasten.

MdmDiagnosticsTool.exe — der eingebaute Collector

Das wird mit Windows ausgeliefert und ist mein bevorzugter First-Line-Intune-Troubleshooting-Collector. Es sammelt die Logs, Registry-Exporte und Event-Logs in einem Paket, plus eine HTML-Zusammenfassung:

:: Collect enrollment, provisioning and Autopilot data into one zip
MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Temp\MDMDiag.zip"

Speichere die Ausgabe in einen Ordner, in den du schreiben kannst (wie C:\Temp). Das ist auch das, was die Collect diagnostics-Aktion des Portals unter der Haube ausführt.

Collect diagnostics — dasselbe, aber remote

Für Remote-Intune-Troubleshooting öffnest du ein Windows-Gerät im Admin Center und klickst auf Collect diagnostics. Es zieht den vollständigen Log-Satz, ohne den Benutzer zu stören, und du kannst es auf bis zu 25 Geräten gleichzeitig ausführen. Die Sammlung bleibt 28 Tage erhalten. Das ist mein erster Schritt, wenn das Gerät nicht vor mir steht.

Die Community-Tools, die ich griffbereit halte

• IntuneDeviceTroubleshooter — ein Tool, das ich gebaut habe. Es zieht den Compliance-, Konfigurations- und App-Status eines Geräts aus Microsoft Graph in eine einzige Ansicht, sodass du nicht durch fünf Blades klicken musst, um zu sehen, warum ein Gerät unglücklich ist. Es macht außerdem One-Click-Aktionen wie Sync und Neustart.
• Error Hunter — mein kostenloses MSNugget-Nachschlagewerk für Intune- und Windows-Fehlercodes: 350+ Codes mit Bedeutung, Ursache, Fix und einem Microsoft-Learn-Link, alles clientseitig.
• Get-IntuneManagementExtensionDiagnostics von Petri Paavola — das IME-Log-Timeline-Tool, das ich oben erwähnt habe. Unverzichtbar.
• Intune Debug Toolkit von MSEndpointMgr — eine Windows-GUI mit einem Win32-App-Redeploy-Button, einem SyncML-Viewer, einem Registry-Change-Monitor und mitgeliefertem CMTrace. Viele von uns aus der Community haben dazu beigetragen.
• SyncML Viewer von Oliver Kieselbach — Live-Tracing des OMA-DM-Protokolls, und neuere Versionen können sogar einen MMP-C-Sync auslösen und einen Autopilot-Hardware-Hash dekodieren.
• Speziell für Autopilot: Get-AutopilotDiagnostics (Michael Niehaus) baut eine saubere OOBE/ESP-Timeline, und OA3Tool.exe aus dem Windows ADK dekodiert einen Hardware-Hash (es ist überhaupt kein Hash — es ist eine base64-Liste von Hardware-Attributen).

Tipp: Für schnelle, fokussierte Tipps schreibe ich mit Florian auch kurze „Nuggets” drüben bei MSNugget, und die Leute, die mir die meisten Internas in diesem Post beigebracht haben, lohnt es sich, direkt zu folgen: Rudy Ooms, Oliver Kieselbach und Michael Niehaus.

Wie erreicht eine Win32-App wirklich das Gerät?

Win32-Apps verursachen mehr Intune Troubleshooting als alles andere, deshalb lohnt es sich, genau zu wissen, was passiert. Hier ist die vollständige Reise einer .intunewin-Datei. Wenn du noch mehr über den Agent willst, der das antreibt, habe ich einen separaten Deep Dive geschrieben: Intune Management Extension Deep Dive: How IME Works.

Die .intunewin ist einfach eine ZIP, die verschlüsselt wurde. Das Content Prep Tool verschlüsselt deine Payload mit AES-256 im CBC-Modus und speichert die Schlüssel in Detection.xml innerhalb des Pakets (den EncryptionKey, den MacKey, den InitializationVector und einen MAC). Die verschlüsselte .bin hat ein festes Layout: Die ersten 32 Bytes sind ein HMAC, die nächsten 16 Bytes sind der IV, und der Rest ist der Ciphertext — ein Decoder überspringt also buchstäblich die ersten 48 Bytes, bevor er entschlüsselt. Oliver Kieselbach und Stephan van Rooij haben all das reverse engineered; Microsoft dokumentiert nur, dass es verschlüsselt ist, nicht wie.

Hinweis: Die Schlüssel werden nicht innerhalb des Pakets an den Client ausgeliefert — die IME erhält sie per Policy vom Intune-Dienst, wenn sie die App anfordert. Deshalb kannst du eine .intunewin nicht einfach entpacken und lesen.

Fürs Intune Troubleshooting ist das die Kette, die du dir vorstellen musst: Auf dem Gerät lädt die IME die .bin nach Content\Incoming, verifiziert den Hash, entschlüsselt sie und entpackt das Ergebnis nach C:\Windows\IMECache\<AppId>. Dann führt sie deinen Install-Befehl aus und erfasst den Exit-Code. Nach der Installation führt sie die Detection-Regel erneut aus, um zu bestätigen, dass die App da ist.

Hier leben die beiden klassischen Fehler — und Microsofts App-Install-Error-Codes-Referenz ist die kanonische Liste, die du neben diesem Abschnitt griffbereit halten solltest:

• „Installiert, aber als fehlgeschlagen gemeldet” (0x87D1041C) — der Installer hat Erfolg zurückgegeben, aber die Detection-Regel hat die App danach nicht gefunden. Fast immer ist die Detection-Regel falsch: falscher Pfad, falsche Version, falscher Registry-Wert oder ein nicht passender MSI-Product-Code.
• Die IME räumt den IMECache-Ordner ein paar Sekunden nach der Detection auf. Wenn dein Installer ein Wrapper ist, der Dateien aus diesem Ordner nach dem Detection-Ergebnis aufruft, scheitert er mit einem „source not found”-Fehler. Behebe es, indem du all deine Dateien zippst und sie zuerst selbst entpackst.

Die Retry-Falle: GRS

Hier ist die, die jeden erwischt. Nach einer fehlgeschlagenen Installation versucht es die IME nicht bei jedem Check-in weiter. Sie wiederholt eine fehlgeschlagene App dreimal im Abstand von fünf Minuten und sperrt sie dann in den Global Retry Schedule (GRS) — einen rund 24-stündigen Cooldown, während dessen sie die App bei jedem Sync überspringt. Wenn du also die Detection-Regel reparierst und nichts passiert, ist die App nicht kaputt — sie steckt nur in ihrem Cooldown. Diese eine Tatsache zu kennen verhindert mehr verschwendete Intune-Troubleshooting-Zeit als fast alles andere in diesem Guide.

Um einen sofortigen Retry auf einem Testgerät zu erzwingen, löschst du den IME-State und startest den Dienst neu:

# Force the IME to re-evaluate Win32 apps on a TEST device.
Stop-Service -Name IntuneManagementExtension
Remove-Item "HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\*" -Recurse -Force -ErrorAction SilentlyContinue
Start-Service -Name IntuneManagementExtension
# Watch C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log

Hinweis: Der App-State liegt unter HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\<SID>\<AppGUID> — die SID ist S-0-0-00... für eine gerätebezogene App oder die echte Benutzer-SID für eine benutzerbezogene. Der Retry-Cooldown selbst ist ein separater GRS-Hash-Schlüssel unter ...\Win32Apps\<SID>\GRS\<hash>. Um den Cooldown sauber zu löschen, löschst du beides — den <AppGUID>-Schlüssel und seinen passenden GRS\<hash>-Schlüssel — und startest dann den IntuneManagementExtension-Dienst neu. Deshalb lösche ich im Skript oben einfach den ganzen Win32Apps-Zweig und starte neu. GRS ist Community-dokumentiert (Rudy Ooms, MSEndpointMgr) und das genaue Layout verschiebt sich zwischen Versionen, also mach das auf einem Testgerät, nicht in der Produktion. Und denk daran: GRS zu löschen setzt nur den Retry-Timer zurück — es behebt nicht die zugrunde liegende Fehlerursache.

Win32-App-Return-Codes, die du korrekt zuordnen musst

Die Detection-Regel ist die Wahrheitsquelle für „installiert oder fehlgeschlagen”, aber der Exit-Code des Installers muss trotzdem korrekt in der Return-Code-Liste der App zugeordnet sein, sonst wird eine vollkommen gute Installation als Fehler gemeldet. Das ist die Tabelle, die ich prüfe, wann immer ein Win32-App-Ergebnis falsch aussieht. Jeder Code, der nicht in der Return-Code-Liste steht, wird als Failed behandelt — die klassische Falle ist ein 3010 Soft-Reboot, den niemand als Erfolg zugeordnet hat.

Win32-App-Return-Codes und wie Intune sie interpretiert.