Windows Autopilot is Microsoft’s modern Windows deployment solution. Rather than applying a customized Windows image, Windows Autopilot configures and customizes an existing Windows 10 or 11 installation via the out-of-box experience.
Over the last several years, I have had the opportunity to implement Windows Autopilot for many customers. Below are a few of recommended practices and configurations I’ve implemented to improve the Windows Autopilot provisioning experience.
Autopilot Profiles
Windows Autopilot profiles allow the administrator to configure the Windows out-of-box experience. They require a basic level of initial configuration with options to control deployment mode, how the device is joined to Entra ID, user account types and what options are visible to the end user.
A key setting I often see disabled is “Allow pre-provisioned deployment”.
Pre-provisioning allows a technician, either in-house or an OEM, to apply device level configurations prior to the end-user receiving the device. Configurations can include configuration profiles, policies, applications and any other items assigned to the device. Once pre-provisioning is complete, the device is “resealed”, powered off and ready for the end-user. When the device is next powered on, Windows Autopilot will continue the provisioning process and apply any assigned user level configurations.
This capability reduces the time required for an end-user to complete provisioning and can be valuable where Windows PCs are shipped directly to end-users, where available bandwidth is limited, or in larger scale device replacement scenarios.
Be mindful, however, that any changes made to device assigned configurations after pre-provisioning will need to be applied during Windows Autopilot. If you modify a device configuration profile after the Windows PC has been sealed, this will be applied to the device after Autopilot provisioning.
Due to this, pre-provisioned Windows PCs should have a short shelf-life and be distributed to end-users as soon as practical.
Enrollment Status Page
The Enrollment Status Page (ESP) provides the end-user with a visual representation of the provisioning process and works in conjunction with a Windows Autopilot profile. Settings within the ESP provide the opportunity to curate and tailor the end-user experience to your organizations requirements. The two settings I see commonly misconfigured are:
- Turn on log collection and diagnostics page for end users
- Block device use until required apps are installed if they are assigned to the user/device
The “Turn on log collection and diagnostics page for end users” option can be a no-brainer. This allows diagnostic data to be uploaded to Microsoft Intune in the event of a failure and allows for the diagnostics screen to be visible during provisioning. It is unlikely that end-users will see much value in this option, however, it can be incredibly useful to technicians and administrators when troubleshooting an issue.
The “Block device use until required apps are installed” setting can be configured with “All” or “Selected” and is used to control which applications must be installed before the end-user is presented with the desktop.
While “All” may appear the best choice, “Selected” is my recommendation. In organizations with many applications deployed, using “All” is likely to extend the Autopilot provisioning process beyond the configured timeout window, ultimately leading to provisioning failures and a poor user experience. When using ‘Selected“, ensure you limit the applications in this list to only those that are truly required before the end-user reaches the desktop. Applications I would typically include here include:
- Microsoft 365 Apps
- Anti-virus, EDR, and other security applications
- Core line-of-business applications
- Applications which perform customisation or configuration actions
Any other applications that are deployed to the user or device will be installed once the end-user is presented with the desktop.
Applications
Windows Autopilot will determine what applications should be installed during Autopilot based on two criteria:
- Which applications are configured in the Enrollment Status Page
- Which applications are assigned to the device and user
Microsoft Intune can deploy several different application types to Windows PCs: Store apps, Web links, MSIs and Win32 apps. MSIs and Win32 apps are the most common across the different Intune tenants I have seen.
In Windows Autopilot scenarios, Win32 and MSI-based applications are executed simultaneously. When Win32 and MSI applications are mixed both applications may attempt to use the Trusted Installer service at the same time, resulting in a conflict, and a failure to install the application.
Microsoft recommends that using the Win32 application type exclusively, even for MSI based applications. This approach ensures that each application is installed in sequence, rather than concurrently. However, any MSI-based applications will need to be wrapped as a Win32 application with the Microsoft Win32 Content Prep Tool.
Assignments
The applications and configurations applied during Windows Autopilot are governed by the assignments within Intune. Device configurations assigned to device-based groups are applied during the “Device preparation” phase. Likewise, user assigned configurations are applied during the “User preparation” phase.
Where this is relevant is how certain configuration profiles interact with Windows during Autopilot provisioning. Some configurations will require a reboot to enable, interrupting provisioning and requiring the user to reauthenticate between Autopilot phases.
Thankfully, configurations which require a reboot are recorded during Windows Autopilot and can be reviewed for tuning. To review reboots, you’ll need to review the below Event Viewer logs filtering on Event ID 2800.
- DeviceManagement-Enterprise-Diagnostics-Provider
- Shell-Core
A common culprit that causes reboot is Device Guard. Deployment of this feature requires the configuration of several virtualization settings, each necessitating a reboot to completely enable. When applied during reboot, the Windows PC will restart at the end of the ‘Device preparation’ phase.
While not ideal, you can work around this issue by assigning Device Guard settings to a user group, causing the settings to apply during the “User preparation” phase. Windows Update Rings have notoriously caused reboots when assigned to device-based groups in the past.
Fine-Tune Your Windows Autopilot Settings
It’s worthwhile spending time reviewing and fine-tuning your Windows Autopilot configuration to ensure your end-users have a seamless and smooth provisioning experience. A few simple changes to your existing experience could resolve headaches your users are currently experiencing.
If you want to know any further information about adopting Windows Autopilot, Microsoft Intune and how Insentra can help, our Managed Intune services may be exactly what you are looking for! You may also download our eBook “Taming the Device Zoo: The Ultimate Guide to Microsoft Intune” or contact us.
