While the official name is “Windows Autopilot Device Preparation,” it’s a bit of a mouthful and doesn’t quite capture its essence. Essentially, it’s useful to think of it in terms of “v1” versus “v2”:
With Autopilot v1, devices were registered with the Autopilot service by you or your OEMs/resellers, creating a “big database of devices in the cloud.” Profiles were assigned to groups of these devices, often using dynamic groups, although static groups could also be used if you were registering the devices yourself. During deployment, devices retrieved their Autopilot profile details from the service to complete OOBE, AAD or AD join, MDM enrollment, and the remaining provisioning steps. Autopilot v2, however, does away with this “big database of devices in the cloud” (to some extent — more on this later). When a Windows device starts up, it follows the usual OOBE screens, such as accepting the EULA and choosing between personal or work/school accounts, until you enter your Entra ID (AAD) credentials. This triggers the Entra ID Join (AAD Join) and MDM enrollment processes, with the Autopilot device preparation details (formerly known as the Autopilot profile and ESP profile) being sent to the device as part of the enrollment payload. Initially, it might have seemed, from my “reading the tea leaves” post, that there was a “new ESP page” and a “new profile type” (Autopilot Device Preparation) that would apply to all Autopilot scenarios, v1 and v2. However, it’s now clear that these changes are exclusive to v2; v1 won’t receive these updates.
Lets start creating a Device Preparation Policy
Step 1: Create a security group and add users who will add their device to Autopilot V2 enrollment
Begin by logging into the Microsoft Endpoint Manager admin center and navigating to the “Groups” section. Create a new security group, ensuring to assign a meaningful name that reflects its purpose. Once the group is created, add the users who will be responsible for adding their devices to the Autopilot V2 enrollment. This setup ensures that only authorized users can enroll devices, enhancing security and manageability.
Step 2: Create a security group for devices and add Intune Provisioning Client as owner
Create a group for Devices, this group will be used to manage devices enrolled through Autopilot V2. After creating the group, assign the Intune Provisioning Client as the owner. This step ensures that the provisioning client has the necessary permissions to manage device enrollment and configuration, streamlining the Autopilot V2 process.
Step 3: Create a Device Preparation Policy for Autopilot V2 in the Microsoft Intune Portal
Access the Microsoft Intune Portal and navigate to the “Devices” section. From there, select “Windows” and then “Windows enrollment.” Choose the “Device Preparation Policy” tab and click on “Create profile.” Configure the necessary settings for the Device Preparation Policy.
Starting Creating the policy.
Step 4: Follow the steps to create the Device Preparation Policy.
Provide a valid Name and Description.
Add the Device Group that we created earlier.
In Configuration Settings, configure the Deployment Settings, OOBE Settings, Apps and Scripts.
We can add up to 10 apps and scripts for our Autopilot Deployment.
Note : Apps should be Assigned the Autopilot Device Group
Under Assignment add the Autopilot Users Group.
Out-Of-Box-Experience for Windows Autopilot V2
Select Country or Region
Connect to Internet
Provide a Device Name or skip the step.
Select work or school account and sign up with your organizational credentials.
Autopilot V2 Device Registration and Configuration
When using Microsoft Autopilot V2, the initial setup process involves registering the device by without its hash values, this makes Intune to recognize and manage the device with Autopilot configurations only after the sign-in process .The actual Autopilot configuration, which includes applying profiles and policies, occurs only after the user signs in for the first time. This means that users might see the standard Windows out-of-box experience (OOBE) screens initially, as Autopilot V2 does not allow customization or control over these pages.
Additionally, it’s important to note that Autopilot V2 currently does not support Hybrid Azure AD joined devices, which are devices that are joined to both Azure Active Directory and on-premises Active Directory.
To ensure that devices are correctly identified as either corporate-owned or personal, administrators need to add device identifiers in the Intune Admin Portal. This differentiation is crucial for applying the appropriate policies and security measures, as corporate devices often require stricter controls compared to personal devices. By accurately categorizing devices, organizations can maintain a secure and efficient IT environment.
