Posted in

This is the way: Windows Autopilot device preparation

by ailona•

Microsoft now recommends Windows Autopilot device preparation for eligible user-driven Microsoft Entra join deployments, and says future engineering investment goes there. Neither the September post nor Microsoft’s device preparation documentation gives a retirement or last-supported date for classic Autopilot, but the direction is explicit enough that the open question is no longer whether to move. It is which populations move first, and how soon you start, because the cost of the transition starts accruing long before any deadline appears.

What is changing

The Intune Customer Success post on moving from Windows Autopilot to device preparation states the direction plainly: device preparation is the recommended path for corporate-owned Windows 11 and Windows 365 user-driven Entra join, and future engineering investment goes there. Classic Autopilot is not going away for the scenarios device preparation cannot serve, and both can run side by side in the same tenant.

What gets replaced is the configuration surface. A single device preparation policy takes over from the pairing of a deployment profile and an Enrollment Status Page, and it carries the OOBE settings, device naming, required applications, PowerShell scripts and blocking behaviour in one place. During OOBE users see a device preparation page instead of the ESP, and administrators get near real-time deployment reporting that covers every device preparation deployment rather than only registered devices.

The comparison documentation sets the limits that decide eligibility: Windows 11 only (24H2 or later, or 23H2 and 22H2 with KB5035942), Microsoft Entra join only, device-based configuration only during OOBE, and a ceiling of 25 essential applications and 10 PowerShell scripts per deployment. Device association, the optional second capability, is the part with hardware conditions of its own: a physical device, TPM 2.0 present and enabled and not sitting in Reduced Functionality Mode, and no virtual machines. It is worth inventorying that before promising an association-based migration, because the general device preparation requirements page lists no hardware requirement beyond what Windows needs, so an admin checking the obvious page will not find the TPM condition there.

No end date, but a clear direction

It is worth being precise about what Microsoft did and did not say, because the difference matters when you take this to a change board. The September post states that device preparation is the recommended solution for user-driven scenarios and that future engineering investments will focus there. It does not announce retirement, a support deadline, or a last-supported date, and nothing in the documentation reviewed for this post carries one. The device preparation FAQ still answers the obvious question with “Not at all”, noting that Windows Autopilot is developed in parallel, that both solutions are expected to exist in parallel for a while, and that there is no requirement to migrate existing profiles.

What that combination supports is an argument to start planning now, not an argument that classic Autopilot stops working. Three things make an earlier start cheaper. Every new Windows 11 device provisioned through classic Autopilot today is another device to migrate later, so new deployments are the cheapest place to adopt the new model. Pre-association converts a device the next time it enters OOBE, which spreads the work across resets you were going to run anyway instead of a scheduled re-imaging project. And Windows 10 and hybrid-joined populations have no device preparation path at all, with Microsoft naming only pre-provisioning and self-deploying as future additions, so while they exist you are running two provisioning models, two sets of documentation, and two support paths. None of that gets cheaper by waiting for a date Microsoft has not given.

Why operators should care

The populations that cannot move are the first planning constraint. Pre-provisioning, self-deploying mode, hybrid Microsoft Entra join, Autopilot into co-management, Autopilot Reset, DFCI management, HoloLens and Teams Meeting Rooms have no device preparation path, and neither does any Windows 10 device. A managed estate that mixes those with corporate Windows 11 laptops therefore runs both solutions for a long time, and the service desk needs to know which device follows which flow.

The 25-app and 10-script caps change image design. Device preparation delivers device-based policy during OOBE and stops there, so anything that assumes user-based configuration applies before the desktop appears needs rethinking, and heavy application payloads move to post-provisioning. There is also a precedence rule to test rather than assume, which the sources spell out and which is easy to overlook in an existing rollout plan.

Two smaller constraints bite mid-rollout. Device association uploads are currently only supported through Intune, so OEM and partner pre-association is not an option yet, and smart card or certificate-based authentication is not supported during OOBE.

If a device is both registered with Windows Autopilot and associated, association takes precedence and the device preparation deployment runs. There is no automatic fallback to the classic flow. A registered device that is not associated still runs its Autopilot profile, which is why an unexpected Enrollment Status Page during OOBE means the device is on the classic path.

The missed signal

The design work sits in the transition, not in the policy. The guidance maps group-tag targeting onto enrollment time grouping, which places devices into assigned Entra static security groups during enrollment, and warns against rebuilding the new design around the group tags and device objects that exist today. Lifting the old targeting model into static groups preserves exactly the complexity the move was meant to remove.

The second non-obvious part is that you do not have to schedule a re-imaging project to convert. Existing registered or enrolled devices can be pre-associated while they stay in use: collect the diagnostics logs in OOBE, export the DeviceLink CSV, upload it in the Associated devices blade, assign the device preparation policy, and confirm the device reaches the Pre-associated state. The device keeps working and takes the device preparation path the next time it enters OOBE at a natural reset or refresh. What you must not do is remove the Windows Autopilot registration early, because that strips Autopilot properties and can break dynamic group membership the device still depends on.

What to do next

  • Pick the eligible population, not the whole estate. Start with corporate-owned Windows 11 devices on user-driven Entra join, and write the exceptions list first (Windows 10, hybrid join, pre-provisioning, self-deploying, co-management, Autopilot Reset, DFCI, HoloLens, Teams Meeting Rooms).
  • Design enrollment time grouping before policy. Create assigned Entra security groups only where location, role, device type or required configuration genuinely differs, then point each device preparation policy at its group.
  • Map profile and ESP pairings onto device preparation policies. Inventory every deployment profile and Enrollment Status Page combination, then carry forward the outcome each population needs rather than every legacy object.
  • Decide where device association earns its place. User-targeted deployments that do not need pre-enrolment tenant affinity, automatic corporate-owned marking or per-device policy selection can run on the policy alone, which keeps onboarding simpler.
  • Pilot, then pre-associate in waves. Validate policy selection, group placement, naming, applications, scripts and reporting on representative devices, confirm the Pre-associated state before a planned reset, and retire the old profiles, groups and registrations only after reporting shows nothing still depends on them.

Sources