One of the challenges with Windows Autopilot that I’ve talked about at various events is troubleshooting – if everything goes well, you’re happy, but if something goes wrong, figuring out what that “something” was can be challenging.  That’s something that we’re working on improving for future Windows 10 releases, but until then I’ll keep blogging about additional ways to make troubleshooting easier.

For this particular post, the focus is on ESP:  If you see an error (whether it’s a timeout, a failure processing a policy, or something else), you might want to know what was being tracked and the status of each of those items.  The policy-specific details aren’t displayed on the ESP page itself because the end user wouldn’t understand them anyway, but it is at least stored on the device so that you can get to it after the fact.  That information is dumped as part of the CAB file generated by the standard “MDMDiagnosticsTool.exe -area Autopilot -cab C:\Autopilot.cab” command that we recommend running to gather logs.  But reading it from that log is still kind of challenging.

But since the information is still in the registry even after ESP and the whole Windows Autopilot process has completed, it is possible to look at it there.  The primary location for this (on Windows 10 1903 and above at least, haven’t checked earlier versions) is:

HKLM:\Software\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\ESPTrackingInfo\Diagnostics

To help translate that information, I published a new PowerShell script called Get-AutopilotESPStatus.ps1 to the PowerShell Gallery.  You can install and run that script on any device using these simple commands:

Set-ExecutionPolicy bypass
Install-Script Get-AutopilotESPStatus
Get-AutopilotESPStatus

Here’s an example execution:

The green lines are successfully-processed policies (installed apps, enrolled certs, applied settings, etc.).  The yellow lines require a little more attention.  You might notice that there are also multiple sets of information, each with a different date/time stamp.  That’s because this information is tracking multiple executions of the ESP at the device level (e.g. across reboots) and at the user level (one per user, plus possible reboots).  The most recent info is generally the most important, but it’s still useful to see these “snapshots” across time.

So, looking at the above information, what problem did I have on this device?  Pretty simple, one of the Win32 apps failed to install.  It won’t tell you the name of the app, just its ID, but at least from there you can look it up via the Intune Graph API, check the IntuneManagementExtension.log for more details, etc.

This is definitely a “version 1.0” script, so give it a try and let me know if something looks off.