Windows Autopilot soll Windows-Geräte ohne direkten IT-Handkontakt bereitstellen. Das Gerät wird dem Anwender zugeschickt, der Anwender meldet sich an, und Intune übernimmt die Einrichtung über Autopilot, ESP, Richtlinien und Anwendungen.
In der Praxis zeigt sich aber gerade beim Troubleshooting eine Schwäche: Wenn während der Enrollment Status Page eine Anwendung fehlschlägt, ist im Intune Portal nicht immer sofort ersichtlich, welche Anwendung tatsächlich das Problem verursacht.
Der eigentliche Punkt ist dabei nicht der konkrete Fehler selbst, sondern der Weg zur Ursache.
Ausgangslage
In meinem Testfall wurde ein Gerät per Autopilot bereitgestellt. In Intune habe ich das Gerät unter Devices > All devices > Gerät > Monitor > All apps geprüft.
Dort waren die zugewiesenen Anwendungen sichtbar. Der Status lautete jedoch nur Waiting for install status.
Das Problem: Diese Ansicht beantwortet nicht die entscheidende Frage:
Welche App blockiert gerade den Autopilot-Prozess?
Gerade bei Autopilot ist das kritisch, weil ein direkter Zugriff auf das Gerät normalerweise nicht vorgesehen ist. Das Gerät steht beim Endanwender, nicht auf dem Tisch der IT.
Typische Ursachen bei App-Fehlern
Aus meiner Sicht gibt es bei App-Installationen über Intune normalerweise diese Fehlerbilder:
- Die Anwendungsinstallation schlägt tatsächlich fehl
Der Installer läuft nicht erfolgreich durch, z. B. wegen falschem Installationsbefehl, fehlender Abhängigkeit, Netzwerkproblem, Berechtigungsproblem oder falschem Exit Code. - Die Detection Methode passt nicht
Die Installation kann technisch erfolgreich sein, aber Intune erkennt die Anwendung danach nicht korrekt. Das passiert z. B. bei falschem MSI ProductCode, falschem Registry-Key, falschem Dateipfad oder Unterschieden zwischen 32-bit/64-bit, Sprache oder Version.
Für den Admin ist in beiden Fällen aber zuerst dieselbe Frage entscheidend:
Welche Anwendung ist betroffen?
Die Ursache war erst über Logs erkennbar
In meinem Beispiel war die betroffene App nicht direkt in der Geräteübersicht erkennbar. Erst über das AppWorkload.log der Intune Management Extension wurde klar, welche Anwendung während der ESP auf Fehler gelaufen ist:
Updating ESP tracked install status from InProgress to Error
for application … with name: AcroRdrDC2600121431_de_DE.exe
Erst nachdem die App über das Log identifiziert war, konnte ich gezielt im Portal in die App-Detailansicht wechseln.
Unter Apps > Windows > App > Monitor > Device install status war der konkrete Fehler dann sichtbar:
The application was not detected after installation completed successfully
0x87D1041C
Die Information war also vorhanden, aber nicht dort sichtbar, wo man sie im Troubleshooting intuitiv zuerst erwartet.
Warum ich das problematisch finde
Autopilot ist auf Zero Touch ausgelegt. Das Troubleshooting wirkt aber an vielen Stellen noch wie ein klassisches Client-Troubleshooting, bzw. funktioniert nicht korrekt.
Statt zentral direkt zu sehen:
App X blockiert, Fehler Y
muss man häufig mehrere Stellen prüfen:
| Stelle | Nutzen | Problem |
| Device > All apps | zeigt zugewiesene Apps | Status oft zu grob |
| App > Device install status | zeigt konkrete Fehler | man muss die App bereits kennen |
| Device diagnostics | remote sammelbar | Auswertung bleibt manuell |
| IME Logs | sehr detailliert | meist nur über Client oder Diagnosepaket |
| EnrollmentStatusTracking Registry | ESP-Status intern | technisch und wenig intuitiv |
Das ist vor allem dann unpraktisch, wenn das Gerät bereits beim Endanwender steht.
Was in diesem Fall hilft
Ein pragmatischer Ablauf ist:
- Gerät in Intune prüfen.
- Falls möglich Device Diagnostics sammeln.
- IME-Logs auswerten, insbesondere:
- AppWorkload.log
- AppActionProcessor.log
- IntuneManagementExtension.log
- Nach Begriffen suchen wie:
- ESP tracked install status
- Error
- Failed
- NotDetected
- Detection
- Gefundene App anschließend gezielt im Portal unter App > Device install status prüfen.
- Danach entscheiden: Installationsfehler oder Detection-Problem?
Was ich mir im Portal wünschen würde
Die Daten liegen im Portal bereits vor, wurden in dem Fall aber nicht weitergereicht. Auch nach Stunden nicht. Die Installation erfolgte am Abend, die Auswertung erst am Morgen. Microsoft sollte an der Stelle nochmal dringend Hand anlegen.
Fazit
Autopilot ist ein starkes Werkzeug für moderne Windows-Bereitstellung. Beim Troubleshooting fehlt mir aber oft die direkte Transparenz im Portal.
Gerade bei Geräten, die direkt an Endanwender geliefert werden, sollte die zentrale Konsole schnell beantworten:
Welche App oder welcher Schritt blockiert Autopilot gerade?
Solange diese Information erst über Logs, Diagnosepakete oder App-Detailansichten herausgearbeitet werden muss, bleibt Autopilot-Troubleshooting unnötig aufwendig.