Modern Workplace17. Februar 20268 Min. Lesezeit

Intune Autopilot – wenn die Enrollment Status Page (ESP) hängt

Die Enrollment Status Page steht seit einer Stunde still, im Intune-Portal sieht alles gut aus. Hier sind die typischen Ursachen, die Logs, die wirklich weiterhelfen, und die passenden Lösungen.

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:

PhaseWas passiertTypische Fehlerquellen
Device preparationEntra-Join, MDM-Enrollment, Installation der Intune Management Extension (IME)Netzwerk, Proxy, TPM-Attestierung, Enrollment-Einschränkungen
Device setupGerätebezogene Richtlinien, Zertifikate, Netzwerkprofile, gerätebezogene AppsWin32-Apps mit fehlerhafter Erkennung, Konflikte zwischen App-Typen, Zertifikatsprofile
Account setupBenutzerbezogene Richtlinien und Apps nach der AnmeldungConditional 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
Nils Lappenbusch

Nils Lappenbusch

Founder & Technology Architect, Lappenbusch

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen

Wo steckt Ihr Projekt gerade fest?

Erzählen Sie uns in 30 Minuten, worum es geht. Sie bekommen eine ehrliche Einschätzung und einen konkreten nächsten Schritt, auch wenn dieser nicht bei uns liegt.