Microsoft has just released its latest flavour of Windows Autopilot known as Autopilot Device Preparation, some call it Autopilot V2.

Windows Autopilot device preparation is a re-architecture of Windows Autopilot. While the experience for OEMs, IT admins, and users is similar, the underlying architecture is different. The updated architecture in Windows Autopilot Device preparation gives new capabilities that improve the deployment experience.

Requirements For Intune Autopilot V2

• Windows 11, version 23H2 with KB5035942 or later.
• Windows 11, version 22H2 with KB5035942 or later.
• Microsoft Entra ID – only Microsoft Entra join is supported. This requirement emphasizes the importance of identity and access management in maintaining secure and efficient device management protocols.

The device shouldn’t be registered or added as a Windows Autopilot device – if the device is registered or added as a Windows Autopilot device, the Windows Autopilot profile takes precedence over the Windows Autopilot device preparation policy. If a device needs to be removed as a Windows Autopilot device having robust information protection and governance is crucial to ensure that sensitive data remains secure throughout the transition.

Key Features of Intune Autopilot V2

1. Autopilot registration is not needed Device shouldn’t be registered or added as a Windows Autopilot device, no need to import the hardware hash in Intune streamlining the process for cloud transformations.
2. Scripts in ESP Scripts could be deployed during the ESP
3. Enrollment Time Grouping Automatically adds devices to a static group to assign Script configurations and applications assigned to static groups which results in better performance as the delay involved in evaluating the dynamic query is no longer there. This group is a special group with the “Intune Autopilot ConfidentialClient” enterprise Application as the owner of the group

• Improved Reporting Out of-the-box monitoring and reporting with near real-time status of deployments, including:
• Applications status
• PowerShell scripts status
• Deployment time.
• Single Autopilot Device Preparation Profile, No need of separate deployment profile and Enrolment status profile

• Corporate identifiers for Windows. Windows Autopilot device preparation supports the Intune corporate identifier enrollment feature. Corporate identifiers in Intune allow the pre-uploading of Windows device identifiers (serial number, manufacturer, model) and ensure only trusted devices go through Windows Autopilot device preparation.

Corporate identifiers for Windows are optional for Windows Autopilot device preparation

Serial number, manufacturer, and model are the corporate identifiers for Windows devices.

Refer to this link for how to collect device identifier.

• Only install selected apps during OOBE. With Autopilot v1, you could select what apps were blocking, but that didn’t change when apps were delivered — all the apps targeted to a machine were likely still installing during device ESP, and depending on the order, that could delay the installation of apps that you actually cared about. With Autopilot v2, apps not selected in the device preparation policy will not install until after the provisioning process completes (installing in the background later).

What do we lose as compared to Autopilot V1?

• Self-deploying. Today, this is built around TPM attestation so that the device can get an Entra ID (AAD) device token to join AAD and enroll in Intune; that TPM attestation process requires the hardware hash. Microsoft stated that they are working on a solution for this.
• Pre-provisioning. Pre-provisioning earlier known as White Glove is not supported.
• Hybrid Entra ID Join (HAADJ) Even the Hybrid join functionality available with Autopilot V1 is not supported.
• OOBE shows more pages. With Autopilot v1, most OOBE pages are hidden; with Autopilot v2, some of the pages will “reappear.” That is because when you start OOBE, there is currently no indication that this will be an Autopilot v2 device. So, pages like the Security settings Page EULA and the “Is this a personal or work/school device” questions will be shown. Only after the device has enrolled in Intune can the Autopilot v2 configuration come down to suppress additional OOBE pages.
• Personal vs. Corporate. Devices registered with Autopilot v1 were always considered corporate devices. By default, with Autopilot v2, they will be considered personal devices if they are not registered with the corporate identifier.
• Only 10 apps. You can only select up to 10 apps (MSIs, Win32, and M365/Office) in the device preparation policy.
• No more user ESP. You can target apps to devices and target the Autopilot v2 device preparation policy to users. But Autopilot v2 is only going to track the device-targeted stuff. User-targeted items will install in the background after the user is signed in.
• No policy tracking/blocking. Interestingly, autopilot v2 will not track or block any policies. With Autopilot v1, it blocked on minimal stuff (e.g., cert profiles, network profiles, and a few select kiosk-related settings), so this is not a huge change. For policies, Windows Autopilot device preparation syncs any policies assigned to the device group. However, Windows Autopilot device preparation does not track if the policies are applied during the deployment. The policies might be applied either during the deployment or after the autopilot deployment is complete.
• Device naming. In the provisioning process, the user will also be able to configure the computer name themselves (no more naming template is available, although in theory, you could rename the device later using an Intune policy since this is an AAD-only scenario anyway).