Table of Contents
The Dawn of Autopilot
Since its inception in 2017, Windows Autopilot has been a groundbreaking technological invention in device deployment. It simplified the process of setting up and pre-configuring new devices, making them ready for productive use with minimal IT effort.
Windows Autopilot allowed IT professionals to:
- Deploy Windows PCs or HoloLens 2 devices efficiently.
- Transform existing Windows installations into a “business-ready” state.
- Apply settings, and policies, and install apps without the need for custom images and drivers for each device model.
This approach significantly reduced the time IT spent on deploying, managing, and retiring devices, while also minimizing the infrastructure required to maintain them.
The Next Generation: Autopilot Device Preparation
Fast forward to the present, and we witness the introduction of the next generation of Windows Autopilot or Autopilot Device Preparation as Microsoft calls it now.
This new iteration is built on a completely new re-engineered architecture that promises to
- More Devices, More Efficiency: Accommodates a broader range of devices and delivers results more efficiently.
- Cloud Instance Provisioning: Supports provisioning for cloud instances like Windows 365 and Azure Virtual Desktops.
- Government Cloud Service: Expands service to government cloud customers for the first time.
The new Autopilot device preparation offers a plethora of enhancements, including:
- Streamlined Deployment: The entire deployment experience is now more efficient, with profiles configured from a single screen.
- Enhanced Reporting: IT admins can access real-time reporting with detailed insights into the deployment process.
- Improved Troubleshooting: Granular information about individual devices, policies, and scripts makes troubleshooting easier.
- Efficient App Installation: Admins can define apps to be installed during the out-of-box experience (OOBE), ensuring critical apps like Microsoft Defender are installed before users start working.
Comparing the Old vs New
The transition from the old Autopilot to the new Autopilot device preparation experience is not just an upgrade; it’s a complete evolution.
Microsoft has built this new next-gen iteration of Autopilot alongside the old Autopilot or maybe we should term it now as the “classic” or “legacy” Autopilot. Nevertheless, both the services, the old/original/classic/legacy Autopilot (or even Autopilot v1) and the new Autopilot Device Preparation (or Autopilot v2), can co-exist in the same tenant (at least for now, for the unforeseen future), thus ensuring service continuity for customers of the existing solution.
Let’s now quickly compare and contrast the 2 generations of Autopilot service that we currently have.
The old/original/classic/legacy Windows Autopilot was built with a device-centric approach, requiring devices to be pre-registered to the Autopilot service to be eligible for Autopilot provisioning.
The new Autopilot Device Preparation or Autopilot v2 takes a user-centric approach instead. As a result, you no longer need to pre-register the device (upload the hardware hash) to the Windows Autopilot service before you can start provisioning the device.
With the old/original/classic/legacy Windows Autopilot, from the IT admin configuration workflow perspective, the experience was not that cohesive, in the sense that you have your Autopilot deployment profile separately and then you have your ESP profile configuration separately.
But with the new Autopilot device preparation, you get the ability to configure deployments using only a single Device preparation policy that references your policies, scripts, and apps for provisioning time tracking purposes.
Thus with Autopilot v2, Microsoft essentially combined the Autopilot deployment profile with the ESP configuration in a single policy pane.
The old/original/classic/legacy Windows Autopilot used to kick-in at the early stages of OOBE thus making it possible to hide certain OOBE pages. The new Autopilot Device Preparation, however, takes effect late during OOBE, post user sign-in to Entra ID.
As such, there are some consequential effects of the same on the user experience during OOBE.
For example, with the new Autopilot v2, there's no possibility, at least for now, to bypass EULA acceptance in OOBE. The user must accept EULA explicitly.
Further, with the new Autopilot, if the device in provisioning context is running Windows 11 Pro and not Windows 11 Ent (which should mostly be the case, since OEMs don’t ship devices with ENT SKU preinstalled unless paid extra otherwise), because of the same reason as explained above, the user will be presented with the OOBE screen to decide device setup - personal vs. work/school.
Note: With the new Autopilot device preparation or Autopilot v2, as we are calling it, devices first enroll as a personal device and later the ownership attribute is flipped by the service to Corporate.
Thus for a device to be able to successfully go through Autopilot v2 provisioning, the tenant must allow BYOD Windows enrolment. If not, Autopilot v2 does have support for another form of device pre-registration, via the Intune Corporate Device Identifier, to help in such scenarios. But then, moving from Autopilot v1 to Autopilot v2, we move from one form of device registration to another. Check this Michael Niehaus post on the same.
Further with the new Autopilot device preparation, MS has added a new completion page in OOBE to help users know when the device setup is complete.
With the old/original/classic/legacy Windows Autopilot, the IT admin can configure in ESP, as many apps to track during the device provisioning before the user gets to the desktop. Now for sure, having to track a large number of apps increases the time required for ESP to complete, but it is doable. However, with the new Autopilot device preparation, Microsoft limited the number of applications that can be applied during OOBE to 10.
MS says that this new limit introduced for apps that can be applied during the OOBE is done after reviewing the Autopilot deployment telemetry to increase stability and achieve a higher success rate.
The old/original/classic/legacy Windows Autopilot, though efficient, lacked the real-time reporting and granular control, which the new Autopilot device preparation can take in its stride.
While the old/original/classic/legacy Windows Autopilot has support for both cloud-native AAD Join and Hybrid AAD Join deployments, the new Autopilot Device Preparation a.k.a Autopilot v2 has support for cloud-native AAD Join (Entra ID join) deployments only.
Further, there is no support for pre-provisioning or self-deployment modes in Autopilot v2 at this moment, as is present with the old/original/classic/legacy Autopilot a.k.a Autopilot v1.
However, with the new Autopilot v2, you finally get the freedom to have both win32 and MSI (LOB) app deployment together during device provisioning.
And unlike the old/original/classic/legacy Windows Autopilot, the new Autopilot v2 comes with the added ability to provision cloud instances and also expands the service to government cloud customers.
Conclusion
The evolution of Autopilot from its original features to the new device preparation experience is a clear indicator of the technological advancements in device deployment. As we embrace these changes, we look forward to a future where efficiency, convenience, control, and better user experience are at the forefront.