Support tip: Troubleshooting unexpected reboots during new PC setup with Windows Autopilot

[Guest Intune_Support_Team]

By: Juanita Baptiste – Sr Product Manager | Microsoft Intune

 

 

 

When a user powers on their PC for the first time, the ideal scenario for Windows Autopilot deployments is that it connects it to their network to log in and automatically provisions itself while the user has little to do to complete the setup. It may take some time to download and install all the programs and settings, but the user only needs to sit back and let the magic happen.

 

 

 

If you’re not getting this "ideal experience", especially if the user must enter their credentials repeatedly, there's a good chance it's because the device is unexpectedly rebooting at some point during start up and the provisioning has to be nudged along. When a device reboots during Windows Autopilot, cached credentials are cleared and the autologin functionality is disabled.

In this post, we've put together a list of scenarios that might be causing these unexpected reboots, and what can be done about them.

 

 

 

Understanding the Windows Autopilot deployment process

 

 

During an Autopilot deployment, configurations, scripts, and applications are automatically applied throughout the device setup with little interaction required from the user.

 

 

 

An overview of the Windows Autopilot provisioning sequence when setting up a new device.

 

 

 

The Enrollment Status Page (ESP) displays the setup progress status for Device preparation, Device setup, and (user) Account setup.

 

 

 

• Device Preparation starts the configuration and app installation tracking to determine when the next stages are complete.
  
• Device setup applies configuration policies, scripts, and applications assigned to the device.
  
• Account setup applies configuration policies, scripts, and applications assigned to the user.
  

 

 

 

Reboots are only supported within a narrow period during Windows Autopilot to provide a smooth user experience. Specifically, a reboot can occur only during the Device phase of the ESP and only when the reboot is triggered by Intune. This means that Intune must be conducting the reboot based on return codes that come from the completed app package install or the completion of a running script.

 

 

 

Unexpected reboots

 

 

Scripts or App Installers that explicitly execute a reboot (rather than cleanly exiting with a return code) will cause an "unexpected reboot" and interrupt the user experience.

 

 

 

Most unexpected reboots tend to happen during the Configuration, Scripts, or App Install phases of the Autopilot provisioning sequence, as depicted above. If the ESP is turned off, the device still goes through those phases to apply policies and applications assigned to the device and user. The only difference is, if the ESP is turned off, the user is not restricted from accessing the desktop while the settings are being applied and installed.

 

 

 

Note, unexpected reboots aren’t the same as being "stuck" on the ESP. If you’re experiencing issues during the ESP phase, see Troubleshooting the Enrollment Status Page for more information.

 

 

 

Investigating causes of reboots

 

 

The admin will need to identify where rebooting issues are occurring during Autopilot. Check for conflicting policies, review the Event Viewer on the device, run MDM diagnostics, or check your applications.

 

 

 

Check for conflicting policies

 

 

There are configuration policies that are intentionally designed to cause a "coalesced reboot" of the system. Most of these policies fundamentally change or affect the behavior of Windows and, therefore, forcibly reboot the machine when applied. Since Windows is executing this reboot on its own (not invoked by Intune), it interrupts the Autopilot process.

 

 

 

A possible workaround is to change the policy assignment from the Device to the User. This still applies the policy and a reboot may still be required for the change to take effect. However, applying the setting after the device phase prevents the coalesced reboot from happening.

 

 

 

A coalesced reboot may be caused by any of the following:

 

• Windows Quality Updates
  
• Device Lock
  
• Password Polices (configuration profile and compliance)
  
• Security Baseline
  
• Credential guard policies
  
• Application Control policies
  

 

 

 

If none of the above policies are applied to your deployment, then it's time to dig into the logs. We also have a list of known policy conflicts outlined in Windows Autopilot policy conflicts.

 

 

 

Check Event Viewer

 

 

On the affected device, open Event Viewer then navigate to Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Search for "Reboot" or “Event ID 2800,” which is an informational event. A coalesced reboot will appear as a reboot and an Event ID 2800 event in the log.

 

 

 

A screenshot of the Event Viewer open to the DeviceManagement-Enterprise-Diagnostic Admin pane with the details for the informational event highlighted.

 

 

 

In the example above, the device rebooted because of the "ManagePreviewBuilds" URI. This means there was a Windows Update policy that applied a setting that required a reboot. Identifying the reboot this way allows you to see where the coalesced reboot occurred to help you make needed changes to the policy or app.

 

 

 

Check Your Apps

 

 

If you have an app that requires a reboot, we recommend that you package it with the Win32 Content Prep Tool and configure the appropriate return codes so the Intune Management Extension (IME) service can perform the reboot. Also, you can add the appropriate switch or property for the application's installation command line to suppress the reboot altogether, if not truly necessary.

 

 

 

If you’re still unable to track down what caused the reboot, go through your build and see which policies or apps were recently introduced and isolate them during the build to determine the root cause.

 

 

 

We hope this helps troubleshoot any unexpected reboots you run into! Let us know if you have any questions by replying to this post or reaching out to @IntuneSuppTeam on Twitter.

 

Continue reading...