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.
I was having the extra login happen to me when deploying the default Windows 10 security baseline settings to a group of devices. Once I changed this to a group of users instead then the user only needed to login once and it took them straight to the their desktop.
During ESP – Device Preparation, device is rebooted and then asking for user credentials. Once user enter his credentials it give error that “We are unable to connect right now. Please check your network and try again.”
Tried with azuread\userupn and direct userupn but still the same.
This is the only user facing it. Machine is only AAD joined.
Can you suggest what is going wrong here.
In addition to the list of the apps, Data Collection policy triggers system reboot as well.