Some time back, I wrote about Windows 11 best practices for onboarding. as we fast forward a few months, Microsoft has now introduced Windows Autopilot device preparation as a potential successor to Autopilot. Today, we’re going to discuss:
- What is Windows Autopilot Device Preparation?
- Setting up Windows Autopilot Device Preparation
- Reporting in Windows Autopilot Device Preparation
- My Thoughts on Device Preparation
What is Windows Autopilot Device Preparation
Today, many of us use Windows Autopilot as a gateway into Intune and the beginning of the user experience on Windows devices. Most people have seen this image which shows the flow within Autopilot today:

One of the big breakages in Autopilot is dealing with OEMs and getting devices onboarded. On occasion they make it really easy, but most times they don’t. You end up trying to get hardware hashes imported after the fact, they behave ridiculous, or it’s just incredibly painful.
With device preparation, a potential next generation solution that eliminates much of the administrative pain has been introduced. Some of the benefits in Windows Autopilot device preparation are:
- Reducing the IT time investment on deployments.
- Simplifying infrastructure.
- Enhancing the simplicity for your users.
- Better troubleshooting
- Near real-time deployment status and monitoring capabilities.
Device preparation improves on the building blocks of Autopilot by simplifying the profile experience with a device group that automatically adds devices to it. The entire AP process shifts to post-authentication allowing the user to name their PC, login, and then the flow begins.
Device preparation will apply apps and scripts you specify prior to letting them into the operating system and still operating in a similar flow. This improves reliability along with strong reporting near real-time reporting of apps, scripts, and deployment time. They amazingly have GCCH and DoD support already (which surprised me).
Some of the other aspects to device preparation are:
- It’s a user-driven flow (no pre-provisioning aka white glove support).
- only supports Entra joined devices.
- sets up users as admin or basic users based on the policy.
- more transparent experience with progress bars for the user.
- LOB and Win32 apps can be deployed in the same deployment.
- Shift from confusing hardware hashes to corporate identifiers (which are still confusing, but slightly less so).
Setting up Windows Autopilot Device Preparation
When setting up Windows Autopilot Device Preparation, we should start with discussing the requirements.
OS requirements:
- Windows 11 22H2/23H2 with patches from April or later (KB5035942).
- Windows 11 Pro/Enterprise/Edu
Network requirements:
- HTTPs access to the device preparation deployment service (ztd.dds.microsoft.com, cs.dds.microsoft.com, and login.live.com)
- Access to Windows Activation services
- Same network connectivity as any other service connecting to Intune and Entra ID
- Connectivity to the diagnostic service (lgmsapeweu.blob.core.windows.net) over HTTPs
- Windows Update
- Other requirements can be seen here, but I wanted to mention the non-obvious ones.
RBAC:
- Device Configurations (Read, Delete, Assign, Create, Update)
- Enrollment Programs (Enrollment time device membership assignment)
- Managed Apps (Read)
- Mobile Apps (Read)
- Organization (Read)
Other requirements match other Autopilot requirements around automatic enrollment/licensing etc.
Now, we will move onto configuration for device preparation.
Configuring Windows Autopilot Device Preparation Device Groups
We will presume you already have Entra join and automatic enrollment setup already.
The first part is creating the device group. Basically, you need to create a regular device-based group with the following:
- Membership Type: Assigned
- Entra roles can be assigned to the group: No
- Owners: Set the owner to the service principal that matches this AppID: f1346770-5b25-470b-88bd-d5744ab7952c which for me was “Intune Autopilot ConfidentialClient” but could also be Intune Provisioning Client”
Literally all you need to do and save! Do not try to use dynamic because it will NOT work. Ignore my bad spelling, I didn’t care.


Once you finish creating the group, MAKE SURE you assign any apps or scripts you plan to deploy to the preparation policy to ensure it installs them.
Configuring Windows Autopilot Device Preparation Policies
Now, we go here to create our Device preparation policies.
The steps are pretty easy. You name the policy:

You set the device group you just created:

Set your configuration settings: (note that it only does user-driven)

You set your apps and scripts:

Once that is done, it’s just the typical scope tags and assignments and you’re done! You want to make sure it looks good (because if you did the device group wrong it will not be pretty):

Importing Corporate Identifiers
You will be going here to import the corporate identifier. I’ll share the code, which I got from another great MVP Peter’s article.
Basically, the corporate identifier is a CSV with the manufacturer, model, and serial number, which you will import. You will grab that CSV and do an import. CSV import is the only supported way of doing it today.
$objBIOSInfo = Get-Ciminstance -Class Win32_BIOS
$objComputerInfo = Get-Ciminstance -Class Win32_ComputerSystem
$strManufacturer = $objComputerInfo.Manufacturer
$strModel = $objComputerInfo.Model
$strSerialNumber = $objBIOSInfo.SerialNumber
$strDeviceIdentifier = "$strManufacturer,$strModel,$strSerialNumber"
Set-Content -Path "C:\Temp\DeviceIdentifier.csv" -Value $strDeviceIdentifier
You can also do this via the API with this command here:
POST against: https://graph.microsoft.com/beta/deviceManagement/importedDeviceIdentities/importDeviceIdentityList
Body:
{
"importedDeviceIdentities": [
{
"@odata.type": "#microsoft.graph.importedDeviceIdentity",
"importedDeviceIdentifier": "ALIENWARE,ALIENWAREAURORARYZENEDITIONR14,9XXXXXX",
"importedDeviceIdentityType": "manufacturerModelSerial"
}
],
"overwriteImportedDeviceIdentities": "true"
}
This demo below will walk through setting up the device preparation profile and importing corporate identifiers:
Reporting in Windows Autopilot Device Preparation
The reporting is really easy to work with. You can access the reports here.
This is what it looks like below. You can see that it shows one device was successful and the other one failed:

You can drill into Apps or Scripts and it shows you some really nice info. Basically, skipped apps are ones that weren’t assigned to the device group you created, or they weren’t applicable to the device.

Initial Thoughts
It’s important to point out that pre-provisioning and self-deploying mode will come in the future. That would likely make many of my clients wait at this point.
Overall, I think the improvements on troubleshooting and user experience are excellent. You can check out my video demo below to see what it looks like end-to-end even with timing. Some of the things that I really like:
- You’re limited to 10 Apps and 10 Scripts (this helps protecting people from themselves).
- It’s way simpler and probably easier to comprehend for admins who may have struggled with Autopilot.
- User experience is a major step-up.
I do really like Autopilot v2, but I wouldn’t call it a “v2” but more like a “different flavor of Autopilot” or more so not Autopilot at all. I will be calling it just Device Prep because I think they’re so different, but it does enable people to use these technologies with very little expertise. By simplifying things and escaping the stranglehold of your OEMs, everyone wins!
