I work a lot with Microsoft Intune, Autopilot and also Pre-Provisioning. Especially with the latter, I often have to troubleshoot for my customers when things don’t work out. Michael Niehaus has written several articles on troubleshooting, including:Read more
- 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)
These articles are the basis for Autopilot Pre-Provisioning troubleshooting. And there is also the article from Microsoft Windows Autopilot troubleshooting overview | Microsoft Docs. But how do you gather all the information before re-provisioning the device and troubleshooting at ease? Or if maybe the pre-provisioning is outsourced to the partner?
For me the process is like this, change, run pre-provisioning, fail, pull log, reinstall and troubleshoot in parallel, fix and retest.
What information could be useful for Autopilot Pre-Provisioning troubleshooting? Besides the obvious ones, like serial number device name, model, manufacturer, MDMDiagnosticTool result, I was interested in more. I’ll be happy to explain why:
- Power supply status: On battery there is a risk that the computer may have gone into power saving mode.
- Time differences: If the system time deviates too far from the Intune, there are problems with the authentication. This also happens with new devices directly from the OEM that the bios time is off by a few minutes.
- Log files from my Intune app scripts: If I need to troubleshoot an application installation, it’s handy to have the installer logs as well.
- Log files from the PSAppDeployToolkit: For the same reasons as for the framework.
- List of installed software: Which software was installed at all when it comes to problems with applications. Once via the Unistall keys of the registry and once via Win32_Product.
- The system and application Eventlog of the last 10 days: Also there meaningful information can be still contained
- List of services: So can be checked whether an agent of a security software but already runs and possibly interferes with the Pre-Provisionig
- Installed Appx packages: These are also often installed via win32 applications.
- Installed Windows packages: These include not only the ModernUI apps, but also the language packages. These are also often distributed with a bit of “DISM” as a Win32 application. In addition, the installed updates and security updates, as well as the features on demand are also included here.
- Delivery Optimization Status: What was downloaded and from where?
- List of drivers with version: Is never wrong to have. Especially if there are known problems with certain driver versions.
I think that you can analyze much better why it went wrong. I hope this helps you.
If you want to have the finished script, it is as always on GitHub: Scipts/get-AutopilotLogs.ps1 at master – InfrastructureHeroes/Scipts (github.com). One request, if you use it commercially, please consider supporting me for taking the trouble and saving you time. This is also easy: either use the Amazon link on the blog if you want to order something, or use Patreon.