Der ultimative Intune Troubleshooting Guide: Wie es funktioniert und wie ich es behebe

In diesem Blogpost erkläre ich, wie ich Intune Troubleshooting von Anfang bis Ende angehe. Das ist keine Liste von Fehlercodes, die du ohnehin schon in der Doku findest — es ist das vollständige Bild: wie Intune unter der Haube tatsächlich funktioniert, wie ein Gerät beweist, wer es ist, wo die Logs liegen, zu welchen Tools ich greife und eine klare Methode, der ich jedes Mal folge. Wenn du verstehst, wie ein Gerät mit Intune spricht, hören die meisten Probleme auf, ein Rätsel zu sein. Du hörst auf zu raten und fängst an, das richtige Log zu lesen — und genau darum geht es beim echten Intune Troubleshooting.

Das hier wird lang, und zwar mit Absicht. Ich wollte den einen Intune Troubleshooting Guide haben, den ich einem Kollegen schicken und sagen kann: „Lies das, und du kannst die meisten Dinge selbst beheben.” Also gehen wir wirklich bis ganz nach unten — einschließlich der neuen MMP-C– und Declared Configuration-Mechanik, von der kaum ein Admin weiß, dass sie bereits auf seinen Geräten läuft — und dann wieder hoch bis zu den Fehlern, die dich am häufigsten treffen.

Eine Anmerkung zur Ehrlichkeit, bevor wir starten: Viele der tiefsten Details hier stehen nicht in der offiziellen Microsoft-Doku. Sie wurden von Leuten wie Rudy Ooms, Oliver Kieselbach und Michael Niehaus reverse engineered. Ich sage es klar, wenn etwas Community-Wissen statt dokumentiert ist, denn Internas wie diese ändern sich zwischen Windows-Builds. Fangen wir mit dem Teil an, den die meisten Guides überspringen — dem mentalen Modell.

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.

Log-Datei	Wofür sie da ist
IntuneManagementExtension.log	Haupt-IME-Log: Check-ins, Policy-Anfragen, Verarbeitung und Reporting — das große Ganze.
AppWorkload.log	Win32-App-Deployment- und Installationsdetails (Haupt-Log für Win32-Apps auf aktuellen Builds).
AppActionProcessor.log	Detection- und Anwendbarkeits-(Requirement-)Prüfungen.
AgentExecutor.log	Ausführung von PowerShell-Plattform-Skripten und Remediations, mit der Ausgabe.
HealthScripts.log	Details zur Ausführung von Remediations (Proactive Remediation).
Win32AppInventory.log	Win32-App-Inventory-Collector.
Sensor.log	Endpoint-Analytics-Daten-Collector.
ClientHealth.log	Gesundheit des IME-Agents selbst.

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.

Return-Code	Bedeutung in Intune
0	Erfolg.
1707	Erfolg (Legacy-Installer-Erfolgscode).
3010	Soft-Reboot — Erfolg, der Neustart wird gebündelt (bis nach der ESP aufgeschoben). Muss als Erfolg zugeordnet werden.
1641	Hard-Reboot — Erfolg, die IME startet das Gerät sofort neu.
1618	Retry — eine andere Installation läuft bereits (TrustedInstaller ist beschäftigt); die IME versucht es später erneut.

Die Methode, die ich tatsächlich verwende

Tools sind keine Methode. Hier ist die Intune-Troubleshooting-Reihenfolge, der ich jedes Mal folge. Sie hält mich davon ab, mich in Sackgassen zu verrennen.

1. Stecke den Geltungsbereich ab, bevor du es anfasst. Gutes Intune Troubleshooting beginnt hier: Ist es ein Gerät oder viele? Ist der Benutzer lizenziert? Sind die benötigten Netzwerk-Endpunkte erreichbar? Meiner Erfahrung nach sind die meisten „Intune-Bugs” überhaupt keine Bugs — es sind Scope, Lizenz oder Netzwerk. Das ist auch der Ansatz, den das Team von OceanLeaf in seinem Troubleshooting-Guide beschreibt, und ich stimme dem zu.
2. Erzwinge einen Sync, dann lies das richtige Log. Das meiste Intune Troubleshooting lebt in diesem Schritt: Profile und CSPs gehen in den Event Viewer (Diagnostics-Provider). Apps und Skripte gehen in die IME-Logs in CMTrace. Lies nicht das App-Log für ein Profilproblem.
3. Übersetze den Code, finde die Grundursache. Konvertiere den Statuscode, schlage ihn nach und prüfe auf einen Konflikt, bevor du der Policy die Schuld gibst. Zwei Profile, die um dieselbe Einstellung streiten, sind eine der häufigsten Ursachen.
4. Setze neu auf, wenn du etwa zwei Stunden überschreitest. Wenn ein einzelnes Gerät dich über zwei Stunden hinaus bekämpft, wipe es und enrolle es neu. Deine Zeit ist mehr wert als eine sture Maschine. (Bei einem flottenweiten Problem gräbst du weiter — neu aufzusetzen ergibt nur bei einem einzelnen Gerät Sinn.)

Die Intune-Troubleshooting-Fehler, die ich am häufigsten treffe — und wie ich sie behebe

Jetzt der praktische Teil. Das sind die Kategorien, die meine Woche füllen, und der Großteil des täglichen Intune Troubleshootings.

Vor den Notizen Kategorie für Kategorie hier das schnelle Nachschlagewerk. Das sind die Codes, die im echten Intune Troubleshooting am häufigsten auftauchen, gruppiert danach, wo sie auslösen, mit dem Fix, zu dem ich zuerst greife.

Code	Bedeutung	Erster Fix
0x80180014	MDM-Enrollment durch eine Enrollment-Restriction blockiert.	Windows (MDM) unter Devices > Enrollment erlauben; das Geräte-Limit prüfen.
0x8018000a	Gerät ist bereits in einem anderen MDM enrolled.	Das veraltete Enrollment und seine EnterpriseMgmt-Scheduled-Tasks bereinigen, dann neu enrollen.
0x80180018	Keine oder ungültige Lizenz.	Eine Intune-Lizenz zuweisen; bestätigen, dass der Benutzer im MDM-User-Scope ist.
0x8018002b	Nicht verifiziertes / nicht routbares UPN-Suffix oder Benutzer außerhalb des MDM-Scopes.	Das UPN-Suffix korrigieren; MDM-User-Scope auf All oder die richtige Gruppe setzen.
0x801c03ea	TPM-Attestierung fehlgeschlagen (Autopilot Self-Deploying / Pre-Provisioning).	TPM-Firmware aktualisieren; tpmtool getdeviceinformation; physisches TPM 2.0 bestätigen.
0x801c0003	Entra-Join nicht autorisiert.	Geräte-Join erlauben; das Geräte-Kontingent prüfen.
0x80070774	Hybrid-Join: Domain-Mismatch / DC nicht erreichbar.	Benutzerzuweisung im Autopilot-Profil entfernen; den ODJ Connector prüfen (30120/30130/30140).
0x87d1041c	Win32-App installiert, aber Detection-Regel hat sie nicht gefunden.	Die Detection-Regel korrigieren (Pfad, Version, MSI-ProductCode); an den GRS-Cooldown denken.
0x87d1fde8	Generischer IME-Install-Fehler / wird wiederholt.	Detection korrigieren, die Installation als SYSTEM testen, AppWorkload.log prüfen.
0x80190190	Sync schlägt fehl — abgelaufenes Intune-MDM-Device-CA-Zertifikat.	Das Zertifikat direkt in certlm.msc prüfen; neu enrollen, falls abgelaufen.

Enrollment schlägt fehl

Fürs Enrollment-Intune-Troubleshooting schau zuerst im Event Viewer ins Diagnostics-Provider-Log und auf das Ergebnis des EnterpriseMgmt-Scheduled-Tasks (Event ID 76). Die Codes, die ich am häufigsten sehe:

• 0x8018002b — der Klassiker. Meist nutzt das UPN des Benutzers eine Domain, die nicht verifiziert oder nicht routbar ist (wie .local), oder der MDM-User-Scope in Entra ist nicht so gesetzt, dass er den Benutzer einschließt. Korrigiere das UPN-Suffix und setze Entra > Mobility (MDM and MAM) > Microsoft Intune > MDM user scope auf All oder die richtige Gruppe.
• 0x80180014 — das Windows-(MDM-)Enrollment ist durch eine Enrollment-Restriction blockiert. Devices > Enrollment > Windows (MDM) auf Allow setzen.
• DeviceCapReached — der Benutzer hat das Geräte-Enrollment-Limit erreicht. Veraltete Geräteeinträge entfernen oder das Limit anheben.
• 0x8007064c / 0x8018000a — das Gerät ist bereits enrolled (oft ein geklontes Image oder ein übrig gebliebenes Arbeitskonto). Entferne die alte Verbindung oder bereinige das veraltete Enrollment-Zertifikat, dann neu enrollen.

Rudy Ooms hat einen tiefen Beitrag zu diesen Enrollment-Codes bei call4cloud, wenn du die Internas auf Registry-Ebene willst.

Eine Win32-App sagt „installiert”, wird aber als fehlgeschlagen angezeigt

Das ist die 0x87D1041C– / GRS-Situation, die ich im Reise-Abschnitt oben behandelt habe — öffne AppWorkload.log, bestätige, dass die Installation erfolgreich war und die Detection fehlgeschlagen ist, korrigiere die Detection-Regel und denk an den Cooldown.

Ein Konfigurationsprofil zeigt „Error”

Beim Profil-Intune-Troubleshooting tauchen Fehler als langer dezimaler Statuscode im Portal auf. Es sind SyncML-Status mit einem zugrunde liegenden Win32-Code. Das Muster:

• Ein Code im Stil SyncML(404) bedeutet, dass der CSP-Knoten nicht gefunden wurde oder auf dieser Plattform nicht anwendbar ist.
• Ein SyncML(405) bedeutet, dass du in einen Read-Only-Knoten geschrieben hast, und 418 bedeutet, dass der Knoten bereits existiert.
• Ein SyncML(500) auf der Firewall-Compliance-Einstellung ist sehr oft harmlos und vorübergehend — der MDM-Agent startet, bevor der Firewall-Dienst beim Boot fertig initialisiert ist. Es klärt sich beim nächsten Sync.

Bevor du irgendetwas änderst, prüfe den Conflict-Status — zwei Profile, die denselben Wert unterschiedlich setzen, sind die Ursache häufiger, als Leute denken.

Wie dekodiere ich einen Fehlercode schnell?

Die meisten dieser Zahlen sind nicht zufällig — und sie zu dekodieren ist Kern-Intune-Troubleshooting. Sie folgen einem Muster, und sobald du es siehst, kannst du die kryptischen Dezimalzahlen des Portals im Kopf dekodieren.

Für Konfigurationsprofile lautet die Regel 0x87D10000 + der SyncML-Statuscode. Ein Portal-Wert von -2016345708 ist also 0x87D10194 in Hex, was 0x87D10000 + 0x194 ist — und 0x194 ist 404. Die Einstellung ist fehlgeschlagen, weil der CSP-Knoten nicht gefunden wurde. Das ist ein echtes Beispiel aus dem Intune-Portal.

Fürs Intune Troubleshooting hilft es außerdem, die Familie eines Codes zu lesen und direkt zum Bereich zu springen:

• 0x8018xxxx — Enrollment / MDM (die MENROLL-Familie). Schau auf Event 76.
• 0x87D1xxxx — eine Win32-App (z. B. 0x87D1041C, nach der Installation nicht erkannt).
• 0x80072Fxx — WinHTTP / Zertifikat / TLS. Sync- und Check-in-Probleme.
• 0x800705b4 — ein Timeout, meist TPM-Attestierung oder die ESP, die ihr Limit überschreitet.

Um den Klartext jedes Win32-Codes schnell zu bekommen, nutze Microsofts Err.exe oder in PowerShell:

# Decode any Win32 / HRESULT to its message text
[ComponentModel.Win32Exception]0x80070005   # -> Access is denied

Tipp: Noch schneller: Füge den Code direkt in ErrorHunter ein — ein kostenloses Fehlercode-Nachschlagewerk, das Florian und ich gebaut haben, das Win32-, HRESULT- und MDM/SyncML-Codes im Browser in Klartext übersetzt. Es ist das, das ich in einem Tab offen halte, während ich Logs lese.

Ein Gerät ist ohne ersichtlichen Grund non-compliant

Beim Compliance-Intune-Troubleshooting beißen hier ein paar Dinge:

• Jede Compliance-Policy hat eine eingebaute „Mark device noncompliant”-Aktion, die auf 0 Tage gesetzt ist. Schlägt eine Einstellung fehl, ist das Gerät sofort non-compliant. Füge eine Grace Period hinzu.
• Die Tenant-Einstellung „Mark devices with no compliance policy assigned as” — wenn diese auf Not compliant steht und eine Conditional-Access-Policy Compliance verlangt, wird ein Gerät, dem schlicht keine Policy zugewiesen ist, ausgesperrt.
• Ein Gerät, das seit ~30 Tagen nicht eingecheckt hat, driftet auf non-compliant — der klassische „zurück aus dem Urlaub”-Fall.

Achte auf die Conditional-Access-Compliance-Schleife: Ein Gerät wird blockiert, weil es non-compliant ist, aber weil es blockiert ist, kann es den Dienst nicht erreichen, um zu syncen und sich als compliant zu melden — also bleibt es blockiert. Der Fix ist, Compliance-Policies an Geräte zu targeten (damit Compliance ausgewertet werden kann, bevor sich der Benutzer anmeldet) und offline-lizenzierte Store-Apps zu verwenden.

Autopilot oder die Enrollment Status Page hängt

Autopilot- und ESP-Intune-Troubleshooting beginnt mit den drei Phasen: Device preparation (TPM-Attestierung, MDM-Enrollment, die IME wird installiert), Device setup (Apps im Gerätekontext, Policies, Zertifikate) und Account setup (Benutzeranmeldung und Apps im Benutzerkontext). Drücke Shift+F10 während der OOBE für eine Eingabeaufforderung und sammle dort Logs.

Wie die ESP weiß, worauf sie warten muss, lohnt sich zu verstehen: Der DMClient CSP sendet dem Gerät einen Satz Expected-Listen (erwartete Apps, Policies, Zertifikate), und die ESP blockiert, bis jede einzelne zurückmeldet. Michael Niehaus fand heraus — und Microsofts eigene Doku bestätigt das jetzt —, dass der „security policies”-Schritt überhaupt keine echten Policies trackt; er trackt einen einzigen Dummy-Eintrag namens EntDMID. Wenn dieser Schritt also seltsam aussieht, ist das so gewollt.

Die Fehler, die ich am häufigsten sehe:

• 0x800705b4 — ein Timeout. Entweder kann die TPM-Attestierung nicht abgeschlossen werden (ein virtuelles TPM oder TPM 1.2 erfüllt nicht die Anforderungen für Self-Deploying oder Pre-Provisioning — du brauchst ein physisches TPM 2.0), oder die ESP hat einfach ihr Timeout überschritten, weil zu viele oder zu große Apps installiert wurden. Die TPM-Attestierungskette greift auf den EK-Zertifikatsdienst des Herstellers und dann auf Microsofts Attestierungsdienst unter *.microsoftaik.azure.net zu; wenn ein Proxy diesen Traffic inspiziert und kaputtmacht, scheitert die Attestierung. Erhöhe das Timeout, reduziere die Required Apps, bestätige TPM 2.0 und nimm diese URLs von der Inspektion aus.
• 0x80070774 — fast immer hybrider Entra-Join mit der „Assign user”-Option im Autopilot-Profil. Entferne die Benutzerzuweisung. Prüfe außerdem das ODJ Connector-Log auf dem Connector-Server auf den Event-Flow 30120 → 30130 → 30140; wenn das Blob nie ankommt, läuft das Gerät in ein Timeout.
• Bleibt bei „Identifying” hängen — Intune berechnet noch die ESP-Policies. Es wird nie fertig, wenn der Benutzer keine Intune-Lizenz hat.
• „Another installation is in progress” — du hast eine Line-of-Business-MSI-App und eine Win32-App gemischt, und beide nutzen TrustedInstaller, der nicht zwei Installationen gleichzeitig ausführen kann. Mische sie nicht, oder wechsle zu Autopilot Device Preparation.

Hybrider Entra-Join ist wirklich fragil, und es lohnt sich zu wissen, warum, bevor du ihn versprichst: Der Join ist asynchron und passiert im Hintergrund, das Gerät muss zweimal einen Domain Controller erreichen, der On-Prem-zu-Cloud-Geräte-Sync kann eine halbe Stunde oder mehr dauern, und wenn sich der Benutzer anmeldet, bevor dieser Sync abgeschlossen ist, hat er noch kein Entra-Benutzer-Token — also bricht die Benutzerphase der ESP. Microsoft und Michael Niehaus raten beide inzwischen davon ab, neue Geräte als hybrid zu deployen, wo du es vermeiden kannst. Rudy Ooms’ Autopilot-Pre-Provisioning-Deep-Dive ist die beste Lektüre dazu, was hinter diesem Fortschrittsbalken passiert.

Ein Gerät hört auf zu syncen

Das ist Brot-und-Butter-Intune-Troubleshooting: Wenn ein Gerät seit über einem Tag nicht eingecheckt hat, kann es keine Policy bekommen. Erzwinge einen Sync über Settings > Accounts > Access work or school > Info > Sync oder über das Geräte-Blade im Portal.

Die Grundursache, an der ich mir schon die Finger verbrannt habe: Der dmwappushservice („Device Management WAP Push Message Routing Service”) ist deaktiviert. Dieser Dienst orchestriert die MDM-Sync-Sessions. Wenn eine Hardening-Baseline ihn vor dem Enrollment deaktiviert hat, werden die PushLaunch- und PushRenewal-Scheduled-Tasks nie erstellt, und das Gerät hört stillschweigend auf zu syncen — mit keinem geloggten Fehler. Setze den Dienst auf Automatic (Delayed Start), starte ihn und triggere das Enrollment erneut. Call4Cloud dokumentiert diesen Fehlerfall hier im Detail.

Wenn der Sync mit einem Zertifikatsfehler wie 0x80190190 fehlschlägt, ist das das Intune-MDM-Device-CA-Zertifikat (aus dem Identitäts-Abschnitt weiter oben), nicht das Entra-Gerätezertifikat. Die „Last check-in”-Zeit kann aktuell aussehen, während das Zertifikat bereits abgelaufen ist, also verifiziere das Zertifikat direkt im Store, statt dem Zeitstempel zu trauen.

Ein PowerShell-Skript oder eine Remediation läuft nicht

Fürs Skript-Intune-Troubleshooting öffne AgentExecutor.log. Die Fakten, die die meisten „es lief nicht”-Fälle erklären:

• Plattform-Skripte laufen einmal — nur bei der ersten Zuweisung oder wenn sich das Skript ändert. Sie laufen nicht bei jeder Anmeldung erneut.
• Skripte laufen nur auf Entra-joined- oder hybrid-joined-Geräten, nicht auf Workplace-Registered-Geräten.
• Eine stark falsch eingestellte Systemuhr blockiert die Ausführung stillschweigend.
• Der Große: Standardmäßig laufen Skripte in einem 32-Bit-PowerShell-Host. Der IME-Agent selbst ist ein 32-Bit-Prozess (er liegt unter Program Files (x86)), also landen auf 64-Bit-Windows deine HKLM\SOFTWARE\...-Schreibvorgänge in WOW6432Node, und 64-Bit-Pfade werden umgeleitet. Setze entweder „Run script in 64-bit PowerShell host” = Yes, oder rufe %SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe aus dem Skript heraus auf. Nur Sysnative erreicht aus einem 32-Bit-Prozess das echte System32.

Tipp: Es gibt einen üblen org-weiten Fehler, den man kennen sollte: Der Entra-Service-Principal, gegen den sich die IME authentifiziert — „Microsoft Intune Windows Agent” — kann fortlaufend deaktiviert werden, und wenn er es ist, hören alle benutzerbezogenen Skripte und Apps auf zu funktionieren. Ihn wieder zu aktivieren bleibt oft nicht haften; Microsofts aktueller Fix ist, den Service Principal über Graph zu löschen, sodass Entra einen sauberen neuen erstellt.

MMP-C oder Declared Configuration funktioniert nicht

Jetzt, da du weißt, dass MMP-C existiert, hier, wie du das Intune Troubleshooting dafür angehst. Bestätige zuerst, dass das zweite Enrollment tatsächlich da ist: Suche nach der zweiten GUID unter HKLM\SOFTWARE\Microsoft\Enrollments und einem gefüllten LinkedEnrollment\EnrollStatus mit MMPCLocked unter dem primären Enrollment. Wenn EPM funktioniert und sein Agent innerhalb von Minuten installiert wurde, hat sich MMP-C sauber enrolled.

Die Probleme, die Rudy Ooms dokumentiert hat:

• Das zweite Enrollment startet nie — fast immer, weil der DiscoveryEndpoint nie gesetzt wurde, sodass das Enroll ohne Ziel läuft und du 0x80070002 (file not found) siehst und nie ein Dual-Enrollment-Scheduled-Task erstellt wird.
• 400 Invalid Request — der Tenant ist nicht für MMP-C onboarded.
• EPM schlägt fehl mit 2147749902 — eine Device-Health-Monitoring-Policy ist fehlgeschlagen (oft ein Windows-Build vor Oktober 2022 oder fehlende DeviceHealthMonitoring-Registry-Schlüssel), was das Ganze blockiert.
• Ein Declared-Configuration-Dokument lässt sich nicht anwenden — im Diagnostics-Provider-Log siehst du eine MDM Declared Configuration:-Zeile mit einem Ergebnis wie 0x8000FFFF (ein Document-ID-Mismatch) oder 0x86000002 (ein Tippfehler in der OMA-URI innerhalb des Dokuments) und dem Szenario-Namen (zum Beispiel MSFTVPN).

Hinweis: Alle MMP-C-Fehlerspezifika oben stammen aus dem Reverse Engineering von call4cloud, nicht aus der Microsoft-Dokumentation. Dieser Bereich ändert sich schnell, also verifiziere gegen deinen Build, bevor du breitflächig handelst.

Intune-Troubleshooting-Fallstricke, die ich inzwischen vermeide

• Das falsche Log lesen. Der häufigste Intune-Troubleshooting-Fehler überhaupt — ein Profilproblem ist nie im App-Log. Wähle zuerst den Kanal.
• Die beiden Zertifikate verwechseln. MS-Organization-Access ist die Entra-Identität; die Intune MDM Device CA ist der Management-Kanal. Sie scheitern unabhängig voneinander.
• „Last check-in” vertrauen. Es kann gesund aussehen, während ein Zertifikat bereits abgelaufen ist. Verifiziere das Zertifikat, nicht den Zeitstempel.
• Eine Win32-App reparieren und einen sofortigen Retry erwarten. Der GRS-Cooldown bedeutet, dass nichts passiert, bis das Fenster vorbei ist. Lösche den State auf einem Testgerät oder warte einfach.
• Den 32-Bit-Kontext vergessen. Das hat mich früher Stunden gekostet. Frage immer, in welcher Architektur das Skript lief.
• Mit einer Hardening-Baseline Dienste deaktivieren, ohne zu prüfen. dmwappushservice ist das berühmte Opfer. Hardening, das das Management kaputtmacht, ist kein Hardening.
• Vergessen, dass MMP-C existiert. Wenn EPM, Device Inventory oder WLAN/VPN-Policies sich danebenbenehmen, denk daran, dass es jetzt ein zweites Enrollment gibt, mit eigenen Logs und seiner eigenen 4-Stunden-Uhr.
• Ein Gerät ewig jagen. Nach zwei Stunden an einer einzelnen Maschine: neu aufsetzen.

Häufig gestellte Fragen

Die Intune-Troubleshooting-Fragen, die mir am häufigsten gestellt werden, mit kurzen, präzisen Antworten, mit denen du etwas anfangen kannst.

Wo werden Intune-Logs unter Windows gespeichert?

App- und Skript-Logs (die Intune Management Extension) liegen in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\ — IntuneManagementExtension.log, AppWorkload.log und AgentExecutor.log sind die, die du am häufigsten liest. Lies sie mit CMTrace oder cmtrace.dev.

Profil-, CSP- und Enrollment-Events sind keine Dateien — sie liegen im Event Viewer unter Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin.

Wie erzwinge ich einen Intune-Sync?

Geh auf dem Gerät zu Settings > Accounts > Access work or school > Info > Sync oder nutze Company Portal > Settings > Sync. Die Sync-Aktion des Admin Centers triggert nur den MDM-(OMA-DM-)Kanal — sie erzwingt nicht die IME.

Um die IME (Apps und Skripte) zu erzwingen, starte den IntuneManagementExtension-Dienst neu. Company Portal > Sync triggert beide Kanäle, weshalb ich Benutzer dorthin schicke.

Wie lösche ich den Win32-App-Retry (GRS)?

Nur auf einem Testgerät: Stoppe den IntuneManagementExtension-Dienst, lösche den App-State unter HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\<SID> — einschließlich seines GRS\<hash>-Schlüssels — und starte den Dienst dann wieder. Das Skript weiter oben in diesem Guide macht genau das.

Denk daran: GRS zu löschen setzt nur den ~24-Stunden-Retry-Timer zurück. Es behebt nicht die zugrunde liegende Fehlerursache, also korrigiere zuerst die Detection-Regel oder die Installation.

Warum zeigt mein Gerät non-compliant, obwohl es das nicht ist?

Meist eines von drei Dingen: Auswertungs-Timing (Compliance prüft sich etwa alle 8 Stunden neu, ein frisches Gerät kann also hinterherhinken), eine einzelne fehlschlagende Einstellung mit der eingebauten „Mark device noncompliant”-Aktion auf 0 Tage, oder ein PRT-Problem, das einen schlechten Compliance-Claim in Conditional Access einspeist.

Füge eine Grace Period hinzu, prüfe, ob das Gerät nicht ~30 Tage offline war, und bestätige den PRT mit dsregcmd /status. „InGracePeriod” zählt für Conditional Access weiterhin als compliant.

Was ist MMP-C in Intune?

MMP-C (Microsoft Management Platform – Cloud) ist ein zweiter Cloud-Management-Dienst, der neben dem klassischen Intune-MDM läuft. Auf dem Gerät erscheint es als separates OMA-DM-Enrollment namens MicrosoftManagementPlatformCloud, das erst erstellt wird, nachdem das Gerät bereits MDM-enrolled ist.

Es transportiert Windows Declared Configuration (Desired-State-Policy) und treibt derzeit Endpoint Privilege Management, Windows Advanced Device Inventory und Resource Access an. Der dcsvc-Dienst erzwingt es und refresht etwa alle 4 Stunden.

Wie behebe ich den Fehler 0x8018000a?

0x8018000a bedeutet, dass das Gerät bereits in einem anderen MDM enrolled ist — ein übrig gebliebenes Arbeitskonto, ein geklontes Image oder ein veraltetes Enrollment. Entferne die bestehende Verbindung unter Access work or school, bereinige das veraltete Enrollment-Zertifikat und lösche die verwaisten EnterpriseMgmt-Scheduled-Tasks.

Dann neu enrollen. Wenn es bei Image-Geräten wiederkehrt, repariere das Image, sodass es ohne ein bestehendes Enrollment ausgeliefert wird.

Warum sagt meine Win32-App installiert, aber fehlgeschlagen?

Weil die Detection-Regel — nicht der Installer-Exit-Code — die Wahrheitsquelle ist. Der Installer hat Erfolg zurückgegeben, aber die Detection-Regel hat die App danach nicht gefunden, also meldet Intune 0x87D1041C. Fast immer ist die Detection-Regel falsch: falscher Pfad, falscher Versionsoperator, falscher Registry-Wert oder ein nicht passender MSI-Product-Code.

Korrigiere die Detection-Regel so, dass sie zum tatsächlich installierten Artefakt passt, dann lösche GRS oder warte den Cooldown ab.

Wie lese ich das IME-Log?

Öffne IntuneManagementExtension.log (und AppWorkload.log für Win32-Apps) in CMTrace oder cmtrace.dev, sodass Fehler rot erscheinen und die Datei live mitläuft. Suche nach [Win32App], GRSManager und ReevaluationScheduleManager, um dem Lebenszyklus einer App zu folgen.

Um die GUIDs in echte Namen zu verwandeln, führe Petri Paavolas Get-IntuneManagementExtensionDiagnostics mit -ConvertAllKnownGuidsToClearText aus — es baut eine lesbare Timeline jeder App, jedes Skripts und jeder ESP-Phase.

Was ist der Unterschied zwischen den beiden Intune-Gerätezertifikaten?

MS-Organization-Access ist die Entra-Geräteidentität — es beweist die Entra-(Azure-AD-)Registrierung und untermauert den PRT. Verlierst du es, fällt das Gerät faktisch aus Entra heraus.

Microsoft Intune MDM Device CA authentifiziert den OMA-DM-Management-Kanal. Wenn es abläuft, stirbt der Sync mit 0x80190190, obwohl der Entra-Join noch in Ordnung ist. Sie scheitern unabhängig voneinander — eine zentrale Intune-Troubleshooting-Unterscheidung.

Wohin das Ganze steuert

Das klarste Signal in all dem ist der Wechsel vom imperativen OMA-DM-Modell zum deklarativen MMP-C-/Declared-Configuration-Modell. Microsoft verschiebt stetig Workloads auf MMP-C — EPM zuerst, dann Device Inventory, jetzt Resource Access, mit Baselines und Defender auf dem Weg. Desired-State-Management, das das Gerät selbst erzwingt, ist schlicht zuverlässiger, als Befehle einmal abzufeuern und zu hoffen, dass sie haften. Wenn du dieses Jahr eine neue Sache lernst, lerne MMP-C.

Auch Intune Troubleshooting verschiebt sich — vom händischen Lesen von Logs hin dazu, Tools sie für dich lesen zu lassen. Die Fehlercode-Suche in cmtrace.dev, die Timeline in Petris Tool und die KI-Log-Zusammenfasser, mit denen ich experimentiert habe, weisen alle in dieselbe Richtung: weniger Scrollen, mehr Grundursache. Ich habe mehr darüber geschrieben, wohin Device Management geht, in AI-driven endpoint management: the future with Intune.

Für die offiziellen Referenzen, die ich offen halte, sind die Seiten Understand the Intune Management Extension, Collect MDM logs und Windows Declared Configuration auf Microsoft Learn die drei, die ich für präzises Intune Troubleshooting am häufigsten nutze.

Ich hoffe, dieser Intune Troubleshooting Guide ist eine echte Hilfe, wenn dich das nächste Mal ein Gerät bekämpft. Speichere ihn als Lesezeichen, schicke ihn einem Kollegen, und denk an die Kernidee: Verstehe den Kanal, beweise die Identität, lies das richtige Log, finde die Grundursache.

Bleib gesund, Cheers Jannik