Ich beschäftige mich viel mit Microsoft Intune, Autopilot und auch Pre-Provisioning. Gerade bei letzterem muss ich öfter für meine Kunden auch die Fehler suchen, wenn es mal nicht klappt. Michael Niehaus hat einige Artikel zum Troubleshooting geschrieben, unter anderem:
- Troubleshooting Windows Autopilot, a reference – Out of Office Hours (oofhours.com)
- Windows Autopilot diagnostics: Digging deeper – Out of Office Hours (oofhours.com)
- TPM Attestation: What can possibly go wrong? – Out of Office Hours (oofhours.com)
- Troubleshooting Windows Autopilot Hybrid Azure AD Join – Out of Office Hours (oofhours.com)
Diese Artikel sind für viele die Grundlage zur Autopilot Pre-Provisioning Fehleranalyse. Und es gibt auch noch den Artikel von Microsoft Windows Autopilot troubleshooting overview | Microsoft Docs. Aber wie sammelt man alle Informationen bevor man das Gerät erneut betankt und in Ruhe das Problem löst? Oder wenn das Pre-Provisioning vielleicht an den Partner ausgelagert ist?
Bei mir ist der Ablauf so, Ändern, Pre-Provisioning durch führen, scheitern, Log ziehen, neubetanken und parallel Fehlersuchen, beheben und erneut testen.
Welche Informationen könnten Sinnvoll für die Analyse sein? Neben den offensichtlichen, wie Seriennummer Gerätenamen, Modell, Hersteller, MDMDiagnosticTool Ergebnis, interessierten mich noch mehr. Ich erkläre euch auch gerne warum:
- Netzteilstatus: Auf Akku besteht die Gefahr das der Rechner evtl. mal in den Energiesparmodus gegangen sein könnte.
- Zeit Differenzen: Wenn die Systemzeit zu weit vom Intune Abweicht, gibt es Probleme mit der Authentifizierung. Das kommt auch schon mal bei neuen Geräten direkt vom OEM vor das die Bios Zeit mal ein paar Minuten daneben geht.
- Logdateien von meinen Intune-App Scripten: Wenn ich eine Anwendungsinstallation Troubleshooting machen muss, ist es praktisch auch die Logs des Installers zu haben.
- Logdateien vom PSAppDeployToolkit: Aus denselben Gründen wir bei dem Framework
- Liste der Installierten Software: Welche Software wurde überhaut installiert, wenn es um Probleme mit Anwendungen geht. Einmal über die Unistall-Schlüssel der Registry und einmal über Win32_Produkt.
- Das System und Anwendungs-Eventlog der letzten 10 Tage: Auch dort können Sinnvolle Informationen noch enthalten sein
- Liste der Services: So kann geprüft werden ob ein Agent einer Sicherheitssoftware doch schon läuft und ggf. das Pre-Provisionig stört
- Installierte Appx Pakete: Auch diese werden gerne mal über win32 Anwendungen installiert
- Installierte Windows Pakete: Darin sind nicht nur die ModernUI Apps enthalten, sondern auch die Sprachpakete. Diese werden auch gerne mal mit ein bisschen „DISM“ als Win32 Anwendung verteilt. Außerdem sind hier auch die installierten Updates und Sicherheitsupdates, sowie auch die Features On Demand enthalten.
- Delivery Optimization Status: Was wurde wie runtergeladen, und von wo?
- Liste der Treiber mit Version: Ist nie verkehrt zu haben. Gerade wenn es mit bestimmten Treiberversionen bekannte Probleme gibt.
Ich denke damit kann man viel besser Analysieren wars warum schief gegangen ist. Ich hoffe das hilft euch weiter.
Wenn Ihr das fertige Script haben möchtet, das liegt wie immer auf GitHub: Scipts/get-AutopilotLogs.ps1 at master · InfrastructureHeroes/Scipts (github.com). Eine bitte, wenn Ihr es Kommerziell nutzt, überlegt bitte, ob Ihr mich unterstützen möchtet dafür, dass ich mir die Mühe mache und euch Zeit spare. Das geht auch einfach: nutzt entweder die Amazon Link auf dem Blog wenn ihr was bestellen möchtet, oder nutzt Patreon.
Schreibe einen Kommentar