Windows Autopilot deployments often accumulate profiles, Enrollment Status Page settings, group tags, dynamic groups, and support workarounds. Microsoft’s September 16, 2026 Intune guidance says Windows Autopilot device preparation is now the recommended solution for eligible user-driven scenarios—but it also makes clear that this is a phased redesign, not a tenant-wide switch.
The practical opportunity is to simplify how a device gets its deployment policy, applications, scripts, naming, and enrollment-time targeting while preserving Autopilot for scenarios that still need it.
What Microsoft changed in the recommended path
Device preparation brings OOBE settings and deployment configuration into a single device preparation policy. Enrollment time grouping (ETG) places the device into the appropriate static Microsoft Entra security group during enrollment, while the device preparation report provides more granular, near-real-time status for applications and PowerShell scripts.
| Current Autopilot concept | Device preparation model | Administrator implication |
|---|---|---|
| Deployment profile and ESP profile | Device preparation policy | Redesign the desired outcome instead of copying every historical object. |
| Group tags and dynamic targeting | ETG with assigned static security groups | Make population boundaries explicit by location, role, device type, or required configuration. |
| Autopilot registration | Optional device association | Use pre-enrollment tenant affinity only where device targeting or corporate ownership requires it. |
| Autopilot deployment report | Device preparation deployment report | Use more detailed status to troubleshoot the pilot before expanding. |
Choose what moves—and what stays
Start with corporate-owned Windows 11 devices using user-driven Microsoft Entra join. Microsoft identifies that population, along with Windows 365, as a fit for device preparation. Continue using Windows Autopilot for pre-provisioning, self-deploying mode, hybrid Microsoft Entra join, and Autopilot into co-management unless your requirements change.
This boundary matters. A migration that treats every deployment as equivalent will either break a supported workflow or preserve unnecessary complexity. Record the reason each exception stays on Autopilot so the decision can be revisited deliberately.
A controlled eight-step transition
- Define the eligible population: choose one user-driven Entra join population and document exclusions.
- Design ETG: create only the static groups that represent genuinely different configurations.
- Map outcomes: inventory OOBE behavior, naming, apps, scripts, blocking requirements, and dependencies.
- Decide on device association: use it where pre-enrollment affinity, device targeting, or corporate ownership adds value.
- Pre-associate the pilot: collect the DeviceLink CSV from diagnostics, upload it in Intune, and confirm the Pre-associated state.
- Test the full OOBE: validate policy selection, ETG placement, apps, scripts, naming, progress, and support runbooks.
- Expand in waves: pre-associate additional populations and let natural or planned resets move devices without forcing a mass reset.
- Retire legacy flows: remove old profiles, groups, registrations, and processes only after dependency checks are clean.
Pre-association does not reset a device or interrupt its current use. Keep the existing Windows Autopilot registration in place until the approved reset or refresh window; removing it early can change Autopilot properties and dynamic-group membership.
Build the pilot around evidence
| Checkpoint | Evidence to retain | Hold the rollout when |
|---|---|---|
| Population boundary | Device list, ownership, join type, Windows version, and explicit exceptions. | A device requires a mode that device preparation does not support. |
| Policy translation | Mapping of each required setting, app, script, name, and group outcome. | The new policy merely reproduces an unknown legacy dependency. |
| OOBE validation | Screenshots, deployment report, ETG membership, app/script status, and help-desk notes. | A required app, script, naming rule, or support path is unreliable. |
| Expansion decision | Pilot acceptance, rollback plan, and next-wave criteria. | Reporting cannot show which population is safe to move next. |
Licensing, OS, and network gates
Before the pilot, verify the Windows and service prerequisites in Microsoft Learn. Device preparation supports Windows 11, has specific OS and hardware requirements, and depends on Entra ID and an MDM service such as Intune. The requirements page also calls out DNS, HTTPS, NTP, Windows Update, Delivery Optimization, diagnostics, and Intune endpoints. Treat those checks as part of the deployment design, not as troubleshooting after a failed enrollment.
Device association adds a TPM-backed tenant relationship and can enable device-targeted policy, corporate marking, and OOBE customization. It is useful when those outcomes matter; it is not a mandatory step for every user-targeted deployment.
Frequently asked questions
Does every Windows Autopilot deployment need to move? No. Move eligible user-driven Entra join populations and keep Autopilot for pre-provisioning, self-deploying, hybrid join, and co-management scenarios that still require it.
Will pre-association disrupt a device in use? No. Microsoft says the device remains enrolled and productive until its next natural or required reset.
What should a first pilot measure? Policy selection, ETG placement, apps, scripts, naming, deployment reporting, and the complete reset-to-desktop experience.
When can old objects be retired? Only after reporting and dependency checks show that no active or planned population still relies on them.
Need a safer endpoint transition?
Accred Consulting can inventory Autopilot dependencies, design the ETG model, and run an evidence-led device preparation pilot without a forced cutover.
Plan an Endpoint Modernization Review