Intune Troubleshooting: Logs, Fehler und Lösungen

Intune Troubleshooting beginnt mit dem Verwaltungskanal, der Geräteidentität und den passenden Logs. Mit dem folgenden Ablauf grenzt du den Fehler ein, bevor du ein Gerät veränderst. Die Referenz zu den Verwaltungskanälen erklärt MDM, IME, MMP-C, Zertifikate und die Win32-Verteilung im Detail.

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.

Häufige Intune-Fehlercodes — Enrollment, Autopilot/TPM und Win32.

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