Use Windows Autopilot device preparation for new Windows 11 devices that only need Microsoft Entra join, user-driven setup and a short list of essential apps: it needs no hardware hash registration, can mix line-of-business and Win32 apps, and reports progress in near real time. Use classic Windows Autopilot when you need Microsoft Entra hybrid join, pre-provisioning, self-deploying mode, Windows 10, Autopilot Reset, more than 25 apps during setup, or the Enrollment Status Page's ability to block the desktop until user-targeted configuration is applied. Both can run in the same tenant; each device uses one or the other.
Who this is for and what you will have
This guide is for Intune administrators deciding how to provision Windows devices, either for a new rollout or for a review of an existing classic Autopilot setup. It compares the two solutions using only what Microsoft documents, explains how they coexist, and walks through a pilot of device preparation. At the end you will have:
- A clear rule for which device populations belong on which solution.
- An understanding of how device association (released August 2026) changes the comparison.
- The configuration objects device preparation needs, created in the right order.
- A list of the known conflicts that make device preparation deployments skip apps or misbehave.
How the two solutions work
Both solutions start from the OEM-installed copy of Windows and turn it into a managed, business-ready device. The difference is in how the device is recognized and how configuration is targeted.
Classic Windows Autopilot
Classic Autopilot depends on registration. The device's hardware hash is uploaded to your tenant, ideally by the OEM or reseller, which creates a Microsoft Entra device object. You build a dynamic device group on Autopilot attributes such as ZTDid or the group tag, assign a deployment profile and an Enrollment Status Page (ESP) profile to it, and target apps and policies at the same group. During OOBE the device downloads its profile from the Autopilot service before anyone signs in, which is why the profile can hide pages, name the device and choose a deployment mode.
Windows Autopilot device preparation
Device preparation doesn't require registration. You create a device preparation policy that points at an assigned security device group and assign the policy to a user group. When a user in that group signs in during OOBE, Intune uses enrollment time grouping to add the device to the device group straight away, then installs only the apps and scripts you selected in the policy. Microsoft describes direct membership as faster and more reliable than waiting for a dynamic group to evaluate. Other apps and policies assigned to the group arrive after the deployment completes; policies are synced during the deployment, but their application isn't tracked.
Because the device isn't known to the tenant until the user signs in, classic OOBE customizations such as hiding the license terms or naming the device weren't available. Device association, covered below, closes that gap for associated devices.
Side-by-side comparison
| Capability | Device preparation | Classic Autopilot |
|---|---|---|
| Supported Windows | Windows 11 24H2 or later; 23H2 or 22H2 with KB5035942 or later | Supported Windows 11 and Windows 10 General Availability Channel versions |
| Join types | Microsoft Entra join | Microsoft Entra join, Microsoft Entra hybrid join |
| Modes | User-driven, automatic (Windows 365) | User-driven, pre-provisioned, self-deploying, existing devices |
| Hash registration | Not required | Required |
| Bind device to tenant before enrollment | Optional, through device association | Through registration |
| Admin objects | Device preparation policy; assigned device group owned by Intune Provisioning Client | Deployment profile; ESP profile |
| Configuration during OOBE | Device-based only; up to 25 apps and 10 PowerShell scripts | Device ESP and user ESP; up to 100 blocking apps |
| LOB and Win32 in the same deployment | Supported | Not supported during ESP |
| Reporting | Near real-time deployment report, all device preparation deployments | Autopilot deployment report, registered devices only, not real time |
| GCCH and DoD | Supported | Not supported |
| Autopilot Reset, DFCI, co-management, HoloLens, Teams Rooms | Not supported | Supported |
Two rows are worth reading carefully. The app limit for device preparation was raised from 10 to 25 in January 2026, for both user-driven and automatic modes, and Microsoft advises reviewing the deployment timeout when you add apps. The ESP row matters because device preparation doesn't use the ESP at all, so ESP-only settings such as Install Windows quality updates (might restart the device) don't apply, and Microsoft states that monthly security updates can't be installed during OOBE in a device preparation deployment.
When classic Autopilot is the only option
Stay on classic Autopilot for any device population that needs one of the following, because device preparation doesn't support it:
- Microsoft Entra hybrid join. Device preparation is Microsoft Entra join only.
- Pre-provisioning by IT, a reseller or the OEM, so the device arrives nearly ready.
- Self-deploying mode for kiosks and shared devices with no user sign-in.
- Windows Autopilot for existing devices and Windows Autopilot Reset.
- Windows 10 devices.
- Co-management: enrolling into co-management from Autopilot.
- DFCI management, HoloLens and Microsoft Teams Rooms.
- More than 25 apps or more than 10 scripts that must be present before first use.
- Blocking the desktop until user-targeted configuration is applied, which the ESP account setup phase provides.
If you need several of these, the decision is already made. Classic Autopilot remains fully documented and supported.
When device preparation is the better fit
Device preparation is the simpler choice when all of the following are true: the devices run a supported Windows 11 build, they're Microsoft Entra joined, a user signs in during setup, and a short list of essential apps is enough before the desktop. In that case it gives you:
- No pre-staging. You don't need hashes from the OEM or a CSV upload. If you block personal enrollments, you upload corporate identifiers (manufacturer, model, serial number) or use device association instead.
- Mixed app types. LOB (MSI), Win32, Microsoft Store (WinGet-based), Microsoft 365 and Enterprise App Catalog apps can install in the same deployment. On the ESP, mixing LOB and Win32 apps fails with
Another installation is in progress, please try again laterbecause both use TrustedInstaller. - One policy. Deployment settings, OOBE settings, apps and scripts live in a single policy.
- Better visibility. The deployment report shows app and script status per device in near real time, and logs from failed deployments are collected automatically.
- Sovereign clouds and Cloud PCs. It supports GCCH and DoD, and in automatic mode it provisions Windows 365 Cloud PCs at creation. Automatic mode became generally available on May 11, 2026 for Windows 365 Enterprise, Windows 365 Flex (dedicated and shared) and Windows 365 Cloud Apps.
How device association changes the comparison
Device association was added to device preparation on August 27, 2026. It binds a physical Windows 11 device to your tenant before enrollment by writing a TPM-attested tenant marker into UEFI firmware. For associated devices it adds the following settings to the user-driven policy, which previously only classic profiles offered:
- Language (Region) and Automatically configure keyboard (not hidden when the device uses Wi-Fi during OOBE).
- Hide Microsoft Software License Terms and Hide privacy settings.
- Hide change account options, which requires company branding in Microsoft Entra ID.
- Apply device name template with
%SERIAL%or a random string, up to 63 characters.
Associated devices are automatically marked corporate-owned and can have a policy assigned directly to the device, which takes precedence over a user-targeted policy. These OOBE settings have no effect on devices that aren't associated. Device association has its own requirements, including Windows 11 24H2 or 25H2 with KB5120998 or later and a healthy TPM 2.0, so read Windows Autopilot device association before you plan around it.
Running both side by side
Microsoft supports both solutions in one tenant, but any single device runs only one. The precedence rule for a device that is registered for classic Autopilot is:
| Device state | What runs |
|---|---|
| Registered, not associated | Classic Autopilot profile |
| Registered and associated | Device preparation policy |
| Not registered, user in a device preparation policy assignment | Device preparation policy |
So if you pilot device preparation on hardware that your reseller already registered, either associate the device or deregister it first. Microsoft's deregistration procedure has a fixed order: if the device is enrolled, delete it from Intune first (Devices > Windows, select the device, Delete). Then go to Devices > Windows > Enrollment > Windows Autopilot > Devices, select the device by serial number, choose Unassign user from the ... menu if it's available, and select Delete. Don't delete the Microsoft Entra device object by hand; skipping steps or removing records out of order can leave orphaned or unrecoverable devices.
Microsoft also recommends a dedicated device group for device preparation rather than reusing groups from classic Autopilot.
Prerequisites for a device preparation pilot
- Windows: Windows 11 Pro, Pro Education, Pro for Workstations, Enterprise, Education or Enterprise LTSC on 24H2 or later, or 23H2 or 22H2 with KB5035942 or later. Installation media dated April 2024 or later for 23H2 and 22H2 already includes KB5035942. Confirm the build with your OEM.
- Licensing: the same subscriptions as classic Autopilot, such as Microsoft 365 Business Premium, Microsoft 365 E3 or E5, EMS E3 or E5, or Microsoft Entra ID P1 or P2 with Intune, assigned to the enrolling user.
- Tenant configuration: automatic MDM enrollment, and the first user who signs in must be allowed to join devices to Microsoft Entra ID.
- RBAC: a role with Device configurations Read, Delete, Assign, Create and Update; Enrollment programs > Enrollment time device membership assignment; and Read on Managed apps, Mobile apps and Organization.
- Network: the same endpoints as classic Autopilot, plus
lgmsapeweu.blob.core.windows.netfor automatic diagnostics upload.
Pilot procedure
- Create the assigned device group. In the Intune admin center, select Groups > New group. Set Group type to Security, Microsoft Entra roles can be assigned to the group to No and Membership type to Assigned. Under Owners, add the service principal Intune Provisioning Client with AppId
f1346770-5b25-470b-88bd-d5744ab7952c. In some tenants it appears as Intune Autopilot ConfidentialClient; the AppId is what matters. - Create a user group containing the pilot users.
- Assign apps and scripts to the device group as Required. Apps should install in System context, and scripts should have Run this script using the logged on credentials set to No, because nobody is signed in when they run.
- Create the policy. Go to Devices > Windows > Enrollment and, under Windows Autopilot device preparation, select Device preparation policies > Create > User Driven. Select the device group on the Device group page, configure settings, and assign the policy to the user group on the Assignments page.
- Configure the deployment settings: Deployment mode User-driven, Deployment type Single user, Join type Microsoft Entra joined, and User account type Standard User or Administrator.
- Configure the OOBE settings: Minutes allowed before showing installation error (an integer from 15 to 720 that covers the whole deployment), an optional Custom error message, Allow users to skip setup after multiple attempts and Show link to diagnostics.
- Select up to 25 apps and up to 10 scripts that must finish before the user reaches the desktop.
- Handle personal-device restrictions. If enrollment restrictions block personally owned Windows devices, upload corporate identifiers or associate the devices. You need one or the other, not both.
If the Intune Provisioning Client service principal doesn't exist, create it with Microsoft Graph PowerShell as an administrator who can add service principals:
Install-Module Microsoft.Graph.Authentication
Install-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.ReadWrite.All"
New-MgServicePrincipal -AppID f1346770-5b25-470b-88bd-d5744ab7952cA 409 (Conflict) response with Request_MultipleObjectsWithSameKeyValue means it already exists. A 403 (Forbidden) with Authorization_RequestDenied means the account lacks permission or consent wasn't granted.
Verification
- Open the Monitor tab on the Devices > Enrollment page and select the Windows Autopilot device preparation deployment status report. Each deployment shows the policy name and version, phase, app status and script status.
- Check that the device is a member of the assigned device group and appears as Microsoft Entra joined.
- The device's enrollmentProfileName property is populated with the device preparation policy name, which you can use in dynamic groups and assignment filters after enrollment.
Known conflicts and fixes
Apps are skipped and the user reaches the desktop early. Check the Microsoft Entra Local administrator settings under Devices > Device settings. When the policy's User account type is Standard user and Registering user is added as local administrator on the device during Microsoft Entra join is Selected or None, provisioning is skipped. Microsoft's documented working combinations include setting the Entra option to All with the policy on Standard user, or the Entra option to None with the policy on Administrator; both leave the user as a standard user.
Devices don't land in the device group. Make sure the group is still assigned (not changed to dynamic), still exists, isn't assignable to other groups, and still has the Intune Provisioning Client as owner. Add affected devices to the group by hand.
The device stops at 100% in OOBE. Microsoft lists this as a known issue; the user must restart the device for the deployment to continue.
More than one policy targets a user. The policy with the smallest number in the Priority column wins. A device-targeted assignment through device association beats any user-targeted policy.
Because a device preparation group gets its members at enrollment, you can make device compliance a Conditional Access requirement from the first sign-in, which supports the device side of a Zero Trust access design. For error codes you might meet on either solution, see Windows Autopilot error codes explained.
Decision checklist
- Hybrid join, pre-provisioning, self-deploying, Windows 10, Autopilot Reset, co-management, DFCI, HoloLens or Teams Rooms needed: classic Autopilot.
- More than 25 apps or 10 scripts before first use, or user-targeted config must block the desktop: classic Autopilot.
- Windows 11 on a supported build, Entra join, user-driven, short essential app list: device preparation.
- Need hidden OOBE pages or device naming on device preparation: plan device association.
- Pilot devices already registered: associate them or delete the registration first.
- Assigned device group owned by Intune Provisioning Client; apps in System context; scripts not using logged-on credentials.
- Entra local administrator setting and policy User account type in a supported combination.
References
- Overview of Windows Autopilot device preparation
- Compare Windows Autopilot device preparation and Windows Autopilot
- Windows Autopilot device preparation requirements
- Create an assigned device group
- Create a Windows Autopilot device preparation policy
- What's new in Windows Autopilot device preparation
- Windows Autopilot device preparation known issues
- Overview of Windows Autopilot device association
- What's new in Windows Autopilot
- Set up the Enrollment Status Page