Ein perfekt konfigurierter Windows Autopilot-Prozess ist der heilige Gral des modernen Device-Managements: Der Nutzer packt den Laptop aus, meldet sich mit seinen Firmencredentials an und im Hintergrund werden Profile, Apps und Einstellungen vollautomatisch ausgerollt. Doch die Realität in der IT-Administration sieht oft anders aus. Ein hängender Enrollment-Screen, eine App, die den ESP (Enrollment Status Page) blockiert, oder Geräte, die einfach nicht im Portal auftauchen, können den Projektsupport in den Wahnsinn treiben. Ein systematisches Intune autopilot troubleshooting ist daher unerlässlich, um die Zeitspanne zwischen „Out of Box“ und „Ready to Work“ zu minimieren.
Grundlagen: Wie Autopilot eigentlich funktioniert
Bevor wir in die Fehlerbehebung einsteigen, müssen wir verstehen, an welchen Punkten der Prozess scheitern kann. Autopilot ist kein einzelnes Tool, sondern ein Orchestrierungsprozess aus mehreren Komponenten: dem Hardware-Hash (Device ID), dem Autopilot-Profil in Intune, dem Entra ID Join und dem MDM-Enrollment.
Der kritische Pfad sieht so aus: Hardware-Hash upload → Zuweisung des Profils → OOBE (Out-of-Box Experience) → Device-Join → ESP (Enrollment Status Page) → App- und Policy-Installation.
Wenn ein Fehler auftritt, ist die erste Frage immer: An welchem dieser Punkte stehen wir? Ein Fehler beim ersten Booten deutet auf ein Profil- oder Netzwerkproblem hin; ein Fehler nach dem Login meist auf die App-Bereitstellung oder Conditional Access Policies.
Schritt-für-Schritt Praxis: Den Fehler lokalisieren
Wenn ein Gerät hängen bleibt, ist Raten Zeitverschwendung. Wir nutzen die im System integrierten Diagnose-Tools.
1. Die Shift+F10 Konsole
Sobald das Gerät im OOBE-Screen hängen bleibt, drücke Shift + F10. Damit öffnest du eine administrative CMD-Konsole. Von hier aus haben wir vollen Zugriff auf das System, bevor der Nutzer überhaupt angemeldet ist.
2. Die Autopilot-Diagnose-Logs
Der schnellste Weg, um zu sehen, was gerade passiert, ist das Auslesen der MDM-Logs. Wir nutzen hierfür PowerShell. Gib in der Konsole powershell ein und führe folgenden Befehl aus, um die neuesten Ereignisse zu prüfen:
Get-WinEvent -LogName Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin | Select-Object -First 20 | Format-Table -AutoSizeHier suchen wir nach Event-IDs, die auf Timeouts oder fehlgeschlagene Zertifikatsabrufe hindeuten.
3. Prüfung des Enrollment-Status
Um zu prüfen, ob das Gerät überhaupt weiß, dass es ein Autopilot-Gerät ist, nutzen wir den Befehl:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Provisioning\Autopilot"Wenn dieser Registry-Key leer ist, hat das Gerät das Profil beim ersten Check-in nicht abgerufen. Die Lösung ist hier meist ein einfacher Neustart oder die Prüfung der Internetverbindung (Proxy/Firewall).
Best Practices für ein stabiles Deployment
Um Intune autopilot troubleshooting gar nicht erst nötig zu machen, sollten folgende Architektur-Regeln gelten:
- Minimierung der ESP-Apps: Weise nur die absolut kritischen Apps (z. B. VPN, Security Agent, Browser) als „Required“ für die ESP zu. Alles andere sollte im Hintergrund nach dem Desktop-Login installiert werden.
- Benennungskonventionen: Nutze die Autopilot-Namensvorlagen (z. B.
CN-%SERIAL%), um Identifikationsprobleme im Portal zu vermeiden. - Conditional Access: Stelle sicher, dass die CA-Policies den Enrollment-Prozess nicht blockieren. Ein häufiger Fehler ist die Forderung nach MFA, bevor das Gerät überhaupt registriert ist.
- Netzwerk-Whitelisting: Prüfe, ob alle Microsoft-Endpoints (insbesondere
*.manage.microsoft.comund*.login.microsoftonline.com) über Port 443 offen sind.
Intune autopilot troubleshooting: Die 10 häufigsten Fehler und ihre Lösungen
1. Gerät wird nicht als Autopilot-Gerät erkannt
Symptom: Das Gerät startet normal in die private OOBE (Sprachauswahl, privates Konto) statt in die Firmen-OOBE.
Ursache: Der Hardware-Hash wurde nicht hochgeladen oder das Profil wurde dem Gerät nicht zugewiesen.
Lösung: Überprüfe im Intune Portal unter Geräte → Windows → Windows enrollment → Devices, ob die Seriennummer gelistet ist und der Status „Assigned“ zeigt. Falls nicht: Hash manuell via PowerShell exportieren und importieren.
2. ESP-Timeout: „Wir bereiten Ihren PC vor“ hängt ewig
Symptom: Die Enrollment Status Page bleibt bei einem bestimmten Prozentsatz hängen und wirft nach 60-120 Minuten einen Timeout-Fehler.
Ursache: Eine als „kritisch“ markierte App schlägt fehl oder dauert zu lange in der Installation.
Lösung: Identifiziere die App über die Logs (siehe unten). Teste die App manuell in der Shift+F10 Konsole. Wenn die App ein Interaktionsfenster öffnet, schlägt Autopilot fehl, da im System-Kontext keine UI möglich ist.
3. Fehler 0x800705B4 (Timeout beim Netzwerk)
Symptom: Fehlermeldung während der Phase „Geräteeinrichtung“.
Ursache: Das Gerät kann die Intune-Server nicht erreichen oder die DNS-Auflösung schlägt fehl.
Lösung: Prüfe die Verbindung mit ping google.com. In Firmennetzwerken ist oft ein SSL-Inspecting-Proxy die Ursache. Deaktiviere SSL-Inspection für die Microsoft-URLs.
4. App-Installationsfehler: 0x87D1041C
Symptom: App wird im Portal als „Failed“ angezeigt, ESP wird blockiert.
Ursache: Die Detection Method (Erkennungsmethode) schlägt fehl, obwohl die App installiert wurde.
Lösung: Überprüfe den Pfad der Detection Method. Wenn du auf eine Datei prüfst, stelle sicher, dass der Pfad absolut ist und nicht auf %username% verweist, da die App im SYSTEM Kontext installiert wird.
5. Tpm-Probleme (Trusted Platform Module)
Symptom: Fehlermeldungen bezüglich der Identität oder Fehlers beim Entra ID Join.
Ursache: Veraltete TPM-Firmware oder ein „gehängtes“ TPM-State.
Lösung: TPM im BIOS löschen (Clear TPM) und sicherstellen, dass TPM 2.0 aktiviert ist. In extremen Fällen hilft ein BIOS-Update.
6. Konflikt zwischen User- und Device-Zuweisung
Symptom: Apps werden doppelt installiert oder gar nicht.
Ursache: Die gleiche App ist sowohl dem Benutzer als auch dem Gerät zugewiesen.
Lösung: Entscheide dich für eine Strategie. Für Autopilot ist die Zuweisung an die Gerätegruppe (Device Group) vorzuziehen, damit die Software bereits vorhanden ist, wenn der User sich anmeldet.
7. Conditional Access blockiert Enrollment
Symptom: „Your organization requires you to sign in with a different method“ oder MFA-Loops.
Ursache: Eine CA-Policy fordert MFA für „All Cloud Apps“, aber das Gerät ist noch nicht compliant.
Lösung: Erstelle eine Ausnahme in der CA-Policy für die App „Microsoft Intune Enrollment“ für eine begrenzte Zeit oder nutze Trusted Locations.
8. Win32-App Installations-Loop
Symptom: Die App wird ständig neu installiert und deinstalliert.
Ursache: Die Installationsdatei gibt einen Exit-Code zurück, den Intune als „Reboot erforderlich“ interpretiert, aber der Reboot wird durch die ESP unterdrückt.
Lösung: Passe die Return Codes in der App-Konfiguration in Intune an. Markiere den spezifischen Code als „Success“ statt „Soft Reboot“.
9. Falscher User-Typ (Standard vs. Administrator)
Symptom: Installationsfehler bei Apps, die lokale Admin-Rechte benötigen, obwohl das Profil auf „Standard“ steht.
Ursache: Die App wird im User-Kontext statt im System-Kontext installiert.
Lösung: Stelle sicher, dass im App-Deployment „Install behavior: System“ ausgewählt ist. Autopilot nutzt das lokale Systemkonto, um Admin-Rechte zu simulieren.
10. „No profile available“ während der OOBE
Symptom: Das Gerät meldet, dass kein Profil gefunden wurde, obwohl es zugewiesen ist.
Ursache: Synchronisationsverzögerung zwischen Entra ID und Intune oder falsche Gruppenmitgliedschaft.
Lösung: Im Intune Portal die manuelle Synchronisation des Geräts triggern. Prüfe, ob das Gerät tatsächlich Mitglied der Gruppe ist, der das Profil zugewiesen wurde.
Pro-Tipp: Die Intune Management Extension (IME) Logs
Wenn Win32-Apps Probleme machen, ist der Event Viewer oft zu ungenau. Gehe direkt zu den IME-Logs. Diese befinden sich unter:
C:\ProgramData\Microsoft\IntuneManagementExtension\LogsNutze das Tool CMTrace (aus dem SCCM Toolkit), um die Datei IntuneManagementExtension.log zu lesen. Suche nach den Keywords [Win32App]. Dort siehst du exakt, welcher Befehl ausgeführt wurde und welchen Exit-Code die App zurückgegeben hat. Dies ist der einzige Weg, um „Black-Box“-Fehler bei komplexen Installern wirklich zu lösen.
Fazit
Intune autopilot troubleshooting ist zu 80 Prozent Detektivarbeit. Die meisten Fehler liegen nicht am Autopilot-Prozess selbst, sondern an den Abhängigkeiten: instabiles Netzwerk, zu strikte Conditional Access Policies oder fehlerhafte Detection Methods bei Win32-Apps. Wer die Shift+F10 Konsole beherrscht und die IME-Logs lesen kann, verwandelt den frustrierenden Enrollment-Screen in eine kontrollierte Umgebung. Der Schlüssel zum Erfolg liegt in der Einfachheit: Weniger kritische Apps im ESP bedeuten eine höhere Erfolgsquote und glücklichere Nutzer.