Autopilot, ESP and extra login/reboots

Windows Autopilot is a great feature and together with the Enrollment Status Page (ESP) it becomes even more powerful as we can make sure for example configuration, applications, certificates and much more is applied before the end-user logs on for the first time so we can optimize their experience.  

During our latest projects we have run into the issue that is discussed in many forums and social media. The dreaded extra login caused by an extra reboot that breaks the amazing experience that the ESP provides for the end-user. The purpose of this blog post is to highlight the learnings we made during multiple projects and which settings generated an extra login/reboot. Hopefully this will save time for the community not having to find this out yourself. I am counting on the community to provide feedback as I haven´t tested every setting out there, I will update the post with all comments and hopefully make it more complete. 

It is a challenge to troubleshoot this issue as the only entry in the event-log that can be found is like the sample below.  

And in the Microsoft-Windows-Shell-Core-Operational we find this as well.  

The tests were made on Windows 10 1903 and 1909 and a first conclusion is that if you deploy Security Baselines, Configuration Profiles, Update rings etc. to users and not devices you are in a much happier place! 

Settings that will cause extra reboot/login when deployed to device are: 

-Update Rings 

-Device Lock 

-Password Polices (configuration Profile and Compliance) 

-Security Baseline 

-Credential guard policies 

-Application Control policies 

Why do we deploy some settings to devices instead of users? Well many customers have a percentage of shared devices and for those many need to deploy a different level of security.  

How can we troubleshoot it then? If we collect the log files from the client for example using the following command. 

mdmdiagnosticstool.exe -area Autopilot -cab C:\Temp\autopilot.cab 

Then we get all the useful logs in one single .cab file. If we extract the file we get the following log files for troubleshooting. 

This is great to send all the log files in to IT so someone can troubleshoot the issue, but it is still not that easy to troubleshoot and in the case of the unexpected reboot not really much there to see.