If a device is registered for classic Autopilot, the Autopilot profile wins and device preparation never runs.
That precedence rule comes straight from Microsoft's documentation, and it explains most of the device preparation pilots that seem to do nothing. The two mechanisms do not stack. Each device follows exactly one of them, and a leftover registration silently picks the old one.
- Entra join onlyHybrid join is not supported
- Windows 1124H2, or 23H2 and 22H2 with the March 2024 update
- Enrollment timeWhen the device joins its security group
- Near real timeDeployment status per device
A device already registered for Windows Autopilot will ignore the device preparation policy.
This behavior is documented, and it quietly explains a large share of pilots that appear to test nothing.
- Microsoft's wording leaves no room for interpretation: the device should not be registered or added as a Windows Autopilot device, and if it is, the Windows Autopilot profile takes precedence over the Windows Autopilot device preparation policy.
- The resulting pilot is maddening precisely because nothing is misconfigured. Policy correct, enrollment correct, and yet the machine walks through the classic Autopilot flow, which reads as the new mechanism failing when it is actually the old registration winning.
- One minute spent checking registration state before the first test removes the ambiguity, and it forces the right design conversation: which device populations follow which provisioning path, decided deliberately instead of colliding machine by machine.
- The second early check is identity. Only Microsoft Entra join is supported, so a fleet that is hybrid joined by default needs to understand that constraint before anyone sketches a rollout plan around device preparation.
Eight things that determine whether it works as expected.
It cannot coexist with classic Autopilot on the same device
Microsoft is explicit: when a device is registered or added as a Windows Autopilot device, the Autopilot profile takes precedence and the device preparation policy is ignored. Any machine you intend to pilot must be free of Autopilot registration, and a previously registered one has to be deregistered before it will follow the new path.
Microsoft Entra join only
Hybrid Entra join is not supported; Entra join is the only option. That single constraint disqualifies estates that still depend on on-premises domain join for line-of-business apps, and conversely makes device preparation an easy fit for organizations that finished their move to cloud-native identity.
Enrollment time grouping is the mechanism
At enrollment, the authenticating device lands in a pre-defined device security group, and whatever is assigned to that group is what deploys. The documentation notes that direct assignment to that group deploys faster and more efficiently than a dynamic device group, which is where the speed improvement over classic Autopilot comes from.
Only what you selected runs during setup
The out-of-box experience runs exclusively the applications and PowerShell scripts selected inside the device preparation profile. Everything else that happens to be assigned to the same group arrives after deployment finishes. If an app must be there at first sign-in, profile selection is the only guarantee; group assignment alone is not.
Policies sync but are not tracked
Policies assigned to the device group are synced during device preparation, but whether they finished applying is not tracked. Microsoft says they may land during the deployment or after it completes. Building an acceptance test on the assumption that a given policy is enforced the moment the desktop appears is a mistake the documentation warns you against.
No custom images to maintain
Device preparation works from the OEM-optimized Windows build already on the machine, transforming that installation into a business-ready state instead of replacing it. Custom images and per-model driver maintenance disappear, along with the infrastructure that supported them.
A better experience at the machine
User-driven flows get a percentage progress indicator and a clear completion message, logs export easily when something fails, and users come out as standard non-administrator accounts by default rather than through a setting an admin has to remember to configure.
Reporting that actually helps
Per-device status arrives in near real time: device details, profile name and version, deployment status, and, crucially, each application and each script with its own status. When a deployment stalls, that granularity converts "something went wrong" into "this specific item failed".
Documented behaviors that look like faults until you know the design.
Each of these produces a confusing symptom in a pilot, and each is working exactly as the documentation says it should.
- A device with a prior Autopilot registration follows the Autopilot profile, full stop. The pilot machine that "ignores" device preparation is almost always this, and nothing in the flow announces why.
- Apps and scripts run during the out-of-box experience only if they were selected in the device preparation profile. Anything merely assigned to the device security group arrives later, so first-sign-in essentials must be in the profile itself.
- Policy application is synced but untracked: a given policy may enforce during deployment or some time after completion. Any acceptance criterion phrased as "policy X is active when the desktop appears" will pass on some machines and fail on others.
- Eligibility is narrower than assumed: Windows 11 24H2 or later, or 23H2 and 22H2 carrying the March 2024 update. In a mixed fleet, establish version coverage before the pilot, because devices below that line are simply not candidates.
Four things that make a device preparation pilot succeed first time.
We check for existing Autopilot registrations first
Because a registered device follows the Autopilot profile no matter what else is configured, a pilot on previously registered hardware ends up testing classic Autopilot while the whole room believes it is testing device preparation. We pull the registration state before any device is touched.
We separate profile content from group assignment
During the out-of-box experience, only profile-selected apps and scripts run; group-assigned items follow later. The design question that actually matters is which applications a person genuinely cannot start their first day without, and we make that list explicit rather than implied.
We set expectations about policy timing
Policy sync happens, policy tracking does not, and enforcement may complete during or after the deployment. So we write acceptance criteria that respect that window, because a test asserting a policy is live at desktop arrival is the worst kind of test: intermittently green.
We confirm the join type before anything else
Entra join is the sole supported identity model. If your line-of-business estate still requires hybrid join, device preparation is not your tool yet, and hearing that in the first conversation costs nothing, while discovering it after a failed pilot costs weeks.
Four phases across roughly four weeks.
- 01Week 1
Confirm eligibility and clear prior registrations
Fleet checked against the Windows version requirement, Entra join confirmed as the identity target rather than hybrid, and every device with a classic Autopilot registration flagged, because on those machines the Autopilot profile wins and the device preparation policy never fires.
- Windows version coverage established across the fleet
- Entra join confirmed as the target join type
- Devices registered for classic Autopilot identified
- Deregistration decisions recorded per device group
- 02Week 2
Design the device group and decide what goes in the profile
The device security group is defined, then the decision that shapes the user experience: which apps and scripts are first-sign-in essentials that belong in the profile, and which can trail in afterwards through plain group assignment.
- Device security group created for enrollment time grouping
- Applications selected in the profile versus assigned to the group
- PowerShell scripts selected and ordered
- Policies assigned to the group with expectations set
- 03Week 3
Build the profile and pilot on real hardware
One profile carries both the deployment and out-of-box experience settings, then gets piloted on the actual models you buy. Watch the progress indicator and completion message with your own eyes rather than assuming they behave.
- Device preparation profile built and assigned
- Pilot completed on representative hardware
- Deployment time measured end to end
- Log export path tested from a pilot device
- 04Week 4
Add enrollment controls and hand over
Corporate identifiers uploaded where enrollment restrictions block personal device enrollment, the near real-time monitoring put in front of the people who will use it, and the service desk shown the per-device view with app and script status.
- Corporate identifiers uploaded where required
- Enrollment restrictions aligned with the approach
- Monitoring demonstrated to the service desk
- Runbook covering the documented behaviors
Six situations where device preparation is the right choice.
An organization already on Entra join
This is the deciding prerequisite. Estates that completed the departure from domain join get a simpler profile model, faster deployments through direct group assignment, and reporting that classic Autopilot never offered.
A business tired of maintaining images
Because provisioning works from the OEM-optimized Windows already on the device, transforming it into a business-ready state, there is no image library and no per-model driver curation. The imaging infrastructure simply has nothing left to do.
A team that cannot see why deployments fail
Troubleshooting classic Autopilot often amounts to educated guessing. With near real-time per-device status including profile name and version and per-app, per-script results, a stalled deployment names its own failing component, which changes the support conversation entirely.
An operator shipping devices directly to sites
No registration pipeline and no technician touch means supplier-to-site shipping with the box opened by whoever works there. The progress percentage and explicit completion message earn their keep here, because the nearest IT person may be three states away.
A regulated firm that wants standard users by default
Device preparation produces standard non-administrator users as its default output rather than as a configuration someone remembers to apply. When local admin sprawl has appeared as an audit finding, a cyber insurance question, or a NIST CSF gap, a correct default beats a documented procedure.
A government contractor or restricted environment
Government Community Cloud High and Department of Defense environments are supported, which matters to defense contractors provisioning in GCC High tenants on the road to CMMC. Corporate identifiers add a gate on top: pre-upload serial, manufacturer, and model so only known hardware passes, where enrollment restrictions block personal devices.
How US organizations provision new Windows devices.
| Feature | Autopilot device preparation | Classic Windows Autopilot | Manual build or imaging |
|---|---|---|---|
Custom images maintained | None | None | Per model |
Per-device registration needed | No | Yes | Not applicable |
Hybrid Entra join supported | No | Yes | Yes |
Grouping | At enrollment time, direct | Usually dynamic groups | Manual |
Apps during setup | Profile selected | Enrollment Status Page | Installed by hand |
Progress visible to the user | Percentage indicator | Status page | None |
Per-script deployment status | Yes | Limited | No |
Technician time per device | None | None | Substantial |
Standard user by default | Yes | Configurable | Frequently not |
Suits a hybrid joined estate | No | Yes | Yes |
Autopilot device preparation against classic Windows Autopilot.
Consideration
Join type supported
- Device preparation
- Microsoft Entra join only
Consideration
Windows version required
- Device preparation
- Windows 11 24H2, or 23H2 and 22H2 with the March 2024 update
Consideration
Device registration needed in advance
- Device preparation
- No, and prior Autopilot registration takes precedence
Consideration
Grouping mechanism
- Device preparation
- Enrollment time grouping into a pre-defined device security group
Consideration
Group assignment type
- Device preparation
- Direct, which deploys faster than a dynamic device group
Consideration
Applications during setup
- Device preparation
- Only those selected in the profile
Consideration
Application types
- Device preparation
- Line-of-business and Win32 in the same deployment
Consideration
Policy application tracked
- Device preparation
- No, policies sync but application is not tracked
Consideration
User rights by default
- Device preparation
- Standard non-administrator
Consideration
Reporting
- Device preparation
- Near real time, with per-application and per-script status
Five steps, and the first two are eligibility rather than build.
- 1
Confirm version and join type eligibility
The fleet must be on Windows 11 24H2 or later, or 23H2 / 22H2 with the March 2024 update, and must target Microsoft Entra join, not hybrid. Both requirements are absolute; an estate that fails either needs a different provisioning path, not a tweaked profile.
- 2
Clear any classic Autopilot registrations
Registered devices obey the Autopilot profile, so every pilot candidate gets its registration state checked and cleared where needed. Skip this and the pilot quietly exercises the mechanism you were trying to leave behind.
- 3
Design the device group and profile content
A device security group built for enrollment time grouping, using direct assignment because it deploys faster than dynamic membership. Then the split: profile-selected apps and scripts that run during setup, versus group-assigned content that lands afterwards.
- 4
Build the profile and pilot on real hardware
The single profile covering deployment and out-of-box settings, exercised on the exact models you actually purchase. We time the deployment end to end and export logs from a pilot machine so the service desk has done it once before they need to do it under pressure.
- 5
Add enrollment controls and hand over the reporting
Corporate identifiers loaded where personal-device blocking demands them, and the monitoring walked through with the operations team, down to the per-application and per-script status that turns troubleshooting from general to specific.
What organizations ask about Autopilot device preparation.
Fifteen checks that prevent a confusing first attempt.
Eligibility
- Are devices on Windows 11 24H2 or later?Or 23H2 and 22H2 with the update.
- Is Entra join the target?Hybrid join is not supported.
- Are any devices registered for Autopilot?That profile takes precedence.
- Do we need to deregister any devices?Before piloting them.
- Are we in a GCC High or DoD environment?Both are supported.
Profile content
- Which apps must exist at first sign-in?Those go in the profile.
- Which apps can arrive later?Group assignment is enough.
- Which scripts are needed during setup?Selected, not just assigned.
- Are LOB and Win32 apps both covered?They can be in one deployment.
- Do we depend on a policy being applied at desktop?Application is not tracked.
Controls
- Do we block personal device enrollment?Then corporate identifiers are needed.
- Have serial, manufacturer, and model been uploaded?The identifier fields.
- Is the device security group direct assignment?Faster than dynamic.
- Are users standard users by default?They are, by design.
- Has the service desk seen the reporting?Per-app and per-script status.
Check two things: Windows version, and whether your devices are Entra joined or hybrid.
The requirements are Windows 11 24H2 or later (or 23H2 / 22H2 with the March 2024 update) and Entra join only. Those two facts decide whether device preparation is available to you before anyone spends an hour building a profile.
Related Services
Explore more solutions that work great with this service