Die Enrollment Status Page (ESP) ist gleichzeitig die nützlichste und die frustrierendste Komponente von Autopilot. Sie zeigt den Benutzern, was beim Setup passiert – und bleibt dann plötzlich bei «Apps werden installiert» stehen, während im Intune-Portal alles nach Erfolg aussieht.
Der Grund: Die ESP wartet nicht einfach, sie verfolgt aktiv Richtlinien, Zertifikate und Apps. Scheitert eine dieser Komponenten oder dauert sie zu lange, blockiert das gesamte Setup. Dieser Artikel zeigt die typischen Ursachen, die Logs, die wirklich weiterhelfen, und die passenden Lösungen.
Was die ESP eigentlich tut
Die ESP arbeitet drei Phasen nacheinander ab:
| Phase | Was passiert | Typische Fehlerquellen |
|---|---|---|
| Device preparation | Entra-Join, MDM-Enrollment, Installation der Intune Management Extension (IME) | Netzwerk, Proxy, TPM-Attestierung, Enrollment-Einschränkungen |
| Device setup | Gerätebezogene Richtlinien, Zertifikate, Netzwerkprofile, gerätebezogene Apps | Win32-Apps mit fehlerhafter Erkennung, Konflikte zwischen App-Typen, Zertifikatsprofile |
| Account setup | Benutzerbezogene Richtlinien und Apps nach der Anmeldung | Conditional Access, benutzerbezogene Apps, lange Installationen |
Ob die ESP bei einem Fehler blockiert oder den Benutzer weiterarbeiten lässt, bestimmt das ESP-Profil. Die Standard-Zeitüberschreitung liegt bei 60 Minuten – danach zeigt die ESP einen Fehler, sofern so konfiguriert.
Tipp: Die wichtigste Einstellung im ESP-Profil ist die Liste der Apps, auf die gewartet wird. «Alle zugewiesenen Apps» klingt sicher, macht die ESP aber zur Geisel jeder einzelnen App. Blockieren Sie nur für die wirklich kritischen Apps – den Rest installiert Intune danach im Hintergrund.
Die häufigsten Ursachen
1. Win32-Apps ohne funktionierende Erkennungsregel
Der Klassiker: Der Installer läuft durch, aber die Erkennungsregel findet die App nicht. Die IME wertet das als Fehler – und die ESP wartet. Häufige Gründe:
- Registry- oder Dateipfad prüft die 32-Bit-Ansicht, die App liegt aber in der 64-Bit-Ansicht (oder umgekehrt)
- Der geprüfte Wert entsteht erst bei der Benutzeranmeldung, die App ist aber dem Gerät zugewiesen
- Die Erkennung prüft eine exakte Versionsnummer, die nach einem Update nicht mehr stimmt
- Ein Erkennungsskript gibt zwar Exit-Code 0 zurück, schreibt aber nichts auf STDOUT – dann gilt die App als nicht erkannt
2. Konflikte zwischen App-Typen
Werden während der ESP gleichzeitig MSI-Line-of-Business-Apps und Win32-Apps installiert, können sich die Installationen gegenseitig blockieren. Microsoft rät davon ab, beide Typen im Autopilot-Setup zu mischen. Setzen Sie konsequent auf Win32-Apps.
3. Grosse Apps und Updates sprengen das Zeitlimit
Microsoft 365 Apps, Teams oder grosse Fachapplikationen brauchen bei langsamer Leitung länger als die Zeitüberschreitung erlaubt. Neuere ESP-Profile können zudem während des Setups Windows-Qualitätsupdates installieren, was zusätzliche Zeit und Neustarts kostet.
4. Gruppenzuweisung kommt zu spät
Apps und Richtlinien werden häufig über dynamische Gruppen auf Basis des Group Tags zugewiesen. Dynamische Gruppen werden nicht sofort neu berechnet. Wird ein Gerät importiert und direkt gestartet, ist es eventuell noch nicht Mitglied der Gruppe – dann fehlen Profile und Apps, oder es greift das falsche Profil. Ebenso häufig: ein Tippfehler im Group Tag oder in der Regel der dynamischen Gruppe.
5. Netzwerk und Proxy
Selten ist es ein Totalausfall, meist sind es selektive Probleme: ein Proxy, der bestimmte Microsoft-Endpunkte blockiert oder TLS aufbricht, eine Firewall, die Downloads aus dem Content Delivery Network drosselt, langsame DNS-Auflösung oder ein Gäste-WLAN mit Captive Portal.
6. Conditional Access während des Setups
Richtlinien, die ein konformes Gerät, einen bestimmten Standort oder MFA verlangen, können Anmeldungen während der ESP blockieren – das Gerät ist zu diesem Zeitpunkt noch nicht konform. Die Anmeldeprotokolle in Entra ID zeigen solche Blockaden direkt an.
7. Skripte und Richtlinien, die das Setup stören
Plattformskripte oder Konfigurationen, die während der Device-Phase Dienste beenden, Neustarts auslösen oder Netzwerkeinstellungen ändern, können die IME oder das Enrollment selbst unterbrechen.
Diagnose: Logs am Gerät lesen
Wenn die ESP hängt, ist die erste Anlaufstelle das Gerät, nicht das Portal. Mit Shift+F10 öffnen Sie während der OOBE eine Eingabeaufforderung, aus der Sie PowerShell starten können.
Diagnosedaten sammeln
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -cab C:\Temp\autopilot.cab
# Das CAB-Archiv entpacken
mkdir C:\Temp\autopilot
expand.exe C:\Temp\autopilot.cab -F:* C:\Temp\autopilot
Im Archiv finden Sie unter anderem den MDMDiagReport.html mit allen angewendeten Richtlinien sowie die relevanten Ereignisprotokolle. Ist im ESP-Profil die Protokollsammlung für Benutzer aktiviert, kann auch der Benutzer bei einem Fehler die Logs auf einen USB-Stick speichern.
Ereignisanzeige
Anwendungs- und Dienstprotokolle
→ Microsoft → Windows
→ DeviceManagement-Enterprise-Diagnostics-Provider → Admin
→ ModernDeployment-Diagnostics-Provider → Autopilot
Filtern Sie nach Fehlern und Warnungen der letzten Minuten. Hier stehen die meisten aussagekräftigen Fehlercodes.
Intune Management Extension
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
IntuneManagementExtension.log Hauptprotokoll der IME
AppWorkload.log Download, Installation und Erkennung von Win32-Apps
AgentExecutor.log Ausführung von PowerShell-Skripten
Suchen Sie nach dem App-Namen, nach «error» oder nach dem Erkennungsergebnis. Am angenehmsten lesen sich die Logs mit CMTrace.
Was die ESP gerade verfolgt
Unter HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking sehen Sie, welche Apps und Richtlinien die ESP verfolgt und welchen Status sie haben. Damit finden Sie die eine App, auf die gewartet wird. Eine bequeme Zusammenfassung liefert das Community-Skript Get-AutopilotDiagnostics aus der PowerShell Gallery.
Tipp: Gehen Sie immer in derselben Reihenfolge vor: Registry-Tracking (worauf wird gewartet?), dann das passende Log (warum?), dann das Portal (welche Zuweisung, welche Konfiguration?). Das spart viel Raten.
Konkrete Lösungen
Win32-App wird nicht erkannt
Testen Sie die Erkennung lokal, bevor Sie die App erneut ausrollen. Ein Erkennungsskript muss bei Erfolg Exit-Code 0 liefern und etwas ausgeben:
$paths = @(
'HKLM:\SOFTWARE\MyCompany\MyApp',
'HKLM:\SOFTWARE\WOW6432Node\MyCompany\MyApp'
)
foreach ($p in $paths) {
$item = Get-ItemProperty -Path $p -ErrorAction SilentlyContinue
if ($item -and $item.Version) {
Write-Output "Erkannt: Version $($item.Version)"
exit 0
}
}
exit 1
Bei Registry-Regeln im Portal achten Sie auf die Option für 32-Bit-Apps auf 64-Bit-Clients; bei Skripten auf die Einstellung, ob sie als 32-Bit-Prozess ausgeführt werden.
Zeitüberschreitung durch grosse Apps
- Nur kritische Apps in die Blockierliste des ESP-Profils aufnehmen
- Zeitlimit bei Bedarf moderat erhöhen, statt die Ursache zu verdecken
- Delivery Optimization und Netzwerkbandbreite am Standort prüfen
- Bewusst entscheiden, ob Qualitätsupdates während des Setups installiert werden sollen
Gruppen und Group Tags
Prüfen Sie im Portal unter Autopilot-Geräte den Group Tag, die Profilzuweisung und die Mitgliedschaft des Geräts in der dynamischen Gruppe. Starten Sie das Setup erst, wenn das Profil als zugewiesen angezeigt wird. Für Apps, die zwingend während der ESP installiert werden müssen, sind statische oder schnell berechnete Zuweisungen robuster.
Netzwerk
Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName enterpriseregistration.windows.net -Port 443
Test-NetConnection -ComputerName manage.microsoft.com -Port 443
netsh winhttp show proxy
Funktioniert das Setup über einen Mobile-Hotspot, aber nicht im Firmennetz, liegt die Ursache fast sicher bei Proxy, Firewall oder Content-Filter.
Conditional Access
Werten Sie die Entra-Anmeldeprotokolle des Benutzers zum Zeitpunkt des Setups aus. Blockiert eine Richtlinie, passen Sie deren Bedingungen gezielt an – nicht durch pauschale Ausnahmen für alle Benutzer.
Account-Phase überspringen
Werden benutzerbezogene Apps ohnehin nicht während der ESP benötigt, kann die Account-Phase per Custom-OMA-URI ausgelassen werden:
OMA-URI: ./Device/Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
Datentyp: Boolean
Wert: True
ESP abschalten? Meist keine gute Idee
Die schnelle Lösung vieler Teams: ESP deaktivieren, dann hängt nichts mehr. Damit verschwindet das Symptom, nicht das Problem. Die ESP stellt sicher, dass Sicherheitsrichtlinien, Zertifikate und kritische Apps vorhanden sind, bevor jemand mit dem Gerät arbeitet. Ohne ESP meldet sich der Benutzer an, VPN oder WLAN-Zertifikat fehlen noch, Apps installieren im Hintergrund, und der Support weiss nicht, was schiefging.
Sinnvolle Ausnahmen gibt es: Kiosk- oder Shared-Geräte mit sehr schlanker Konfiguration, oder Szenarien, in denen bewusst nur die Device-Phase blockieren soll.
Achtung: Wer die ESP deaktiviert, deaktiviert nicht die Zuweisungen. Richtlinien und Apps werden weiterhin ausgerollt – nur unsichtbar und ohne Garantie, dass sie vor der ersten Nutzung fertig sind.
Fazit: Es ist selten die ESP
Die ESP hängt nicht ohne Grund. Fast immer steckt eine konkrete Ursache dahinter: eine fehlerhafte Erkennungsregel, eine zu spät berechnete Gruppe, ein Proxy oder ein zu breit gefasstes ESP-Profil. Mit den richtigen Logs und einer festen Diagnose-Reihenfolge lässt sich die Ursache meist eingrenzen.
Checkliste
- ESP blockiert nur für wirklich kritische Apps
- Alle Apps im Setup als Win32 paketiert, keine MSI-LOB-Mischung
- Erkennungsregeln lokal getestet, Skripte geben Exit-Code 0 und Ausgabe zurück
- Group Tags und dynamische Gruppen geprüft, Profil zugewiesen vor dem Start
- Netzwerkzugang zu den Microsoft-Endpunkten ohne TLS-Inspection
- Conditional Access im Setup-Kontext getestet
- Protokollsammlung für Benutzer im ESP-Profil aktiviert