Register a device for classic Autopilot and the Autopilot profile wins. Device preparation never runs.
Microsoft states the precedence rule directly, and it is the single most common reason a device preparation pilot appears to do nothing. The two mechanisms are separate, they are not layered, and a device can only be in one of them.
- Entra join onlyHybrid join is not supported
- Windows 1124H2, or 23H2 and 22H2 with the March 2024 update
- Enrolment 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 is documented, and it is the reason a proportion of device preparation pilots appear to do nothing at all.
- The published rule is explicit: 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.
- That produces a confusing pilot. The policy is configured correctly, the device is enrolled correctly, and the classic Autopilot experience appears instead, which looks like the new policy failing rather than the old registration winning.
- Checking registration state before testing takes a minute and removes the ambiguity entirely. It also forces a useful conversation about which devices should follow which path, rather than leaving the two approaches to collide device by device.
- The other prerequisite to confirm early is identity: only Microsoft Entra join is supported. Estates that are hybrid joined by default need that difference understood before they plan a rollout around device preparation.
Eight things that determine whether it works as expected.
It cannot coexist with classic Autopilot on the same device
If a device is registered or added as a Windows Autopilot device, the Windows Autopilot profile takes precedence over the device preparation policy. A device intended for device preparation must not be registered for Autopilot, and if it already is, it needs deregistering first.
Microsoft Entra join only
Only Microsoft Entra join is supported. Hybrid Entra join is not, which rules device preparation out for estates still dependent on on-premises domain join for line of business applications, and makes it a natural fit for organisations that have already moved past that.
Enrolment time grouping is the mechanism
When a user authenticates, the device is added to a pre-defined device security group during enrolment, and what is assigned to that group deploys. Microsoft notes direct assignment deploys quicker and more efficiently than a dynamic device group, which is the underlying performance improvement.
Only what you selected runs during setup
Only applications and PowerShell scripts selected in the device preparation profile are deployed during the out of box experience. Anything else assigned to the same device group deploys after the deployment completes, which is a meaningful distinction when a critical application is missing at first sign in.
Policies sync but are not tracked
Device preparation syncs any policies assigned to the device group, and does not track whether those policies are applied during the deployment. They might apply during it or after it completes. Treating policy application as guaranteed at desktop arrival is the mistake to avoid.
No custom images to maintain
It uses the OEM-optimised version of Windows preinstalled on the device, so custom images and drivers do not need maintaining per device model. Rather than re-imaging, the existing Windows installation is transformed into a business-ready state, which is what removes the imaging infrastructure.
A better experience at the machine
A simplified out of box experience with a percentage progress indicator for user-driven flows, users informed when setup is complete, logs exportable easily when something goes wrong, and standard non-administrator users by default rather than as a setting somebody has to remember.
Reporting that actually helps
Near real-time status per device covering device details, profile name and version, deployment status details, applications applied with status, and scripts applied with status. That level of detail is the practical difference when troubleshooting a deployment that stalled.
Registered for Autopilot, and device preparation simply does not apply.
Each of these is documented, and each produces a symptom that looks like a fault rather than a design.
- If the device is registered or added as a Windows Autopilot device, the Windows Autopilot profile takes precedence over the device preparation policy. A pilot device that was previously registered for Autopilot will therefore go through the old flow, with nothing obvious explaining why.
- Only applications and PowerShell scripts selected in the device preparation profile deploy during the out of box experience. Additional items assigned to the same device security group deploy afterwards, so an application the user needs at first sign in must be selected in the profile rather than merely assigned to the group.
- Policies assigned to the device group are synced, and device preparation does not track whether they applied during the deployment. They might apply during it or after it. Any acceptance test that assumes a specific policy is in force the moment the desktop appears will be intermittently wrong.
- The version requirement is also narrower than people expect: Windows 11 version 24H2 or later, or 23H2 and 22H2 with the March 2024 update or later. Devices below that are not candidates, and in a mixed estate that needs establishing before a pilot rather than during it.
Four things that make a device preparation pilot succeed first time.
We check for existing Autopilot registrations first
If a device is registered or added as a Windows Autopilot device, the Autopilot profile takes precedence over the device preparation policy. A pilot run on a previously registered device tests classic Autopilot while everybody believes they are testing device preparation.
We separate profile content from group assignment
Only applications and scripts selected in the profile deploy during the out of box experience. Everything else assigned to the group arrives afterwards. Deciding which applications a user genuinely needs at first sign in is the design decision that determines whether the device feels ready.
We set expectations about policy timing
Device preparation syncs policies assigned to the device group and does not track whether they applied during the deployment. Acceptance criteria written as a specific policy being in force at desktop arrival will pass sometimes and fail sometimes, which is the worst kind of test.
We confirm the join type before anything else
Only Microsoft Entra join is supported. For an organisation still dependent on hybrid join for line of business applications, device preparation is not the right tool yet, and establishing that in the first conversation saves a pilot that was never going to work.
Four phases across roughly four weeks.
- 01Week 1
Confirm eligibility and clear prior registrations
Windows version checked against the requirement, join type confirmed as Entra join rather than hybrid, and any devices already registered for classic Autopilot identified, since the Autopilot profile would otherwise take precedence and the device preparation policy would never apply.
- Windows version coverage established across the estate
- 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 defined, then the important distinction: which applications and scripts must be present at first sign in and therefore belong in the profile, and which can arrive afterwards and can simply be assigned to the group.
- Device security group created for enrolment 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
A single profile provisioning deployment and out of box experience settings in one location, then piloted on actual devices of the models you deploy. The percentage progress indicator and completion message are worth observing rather than assuming.
- 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 enrolment controls and hand over
Corporate identifiers uploaded where enrolment restrictions block personal device enrolment, monitoring reviewed so the near real-time reporting is being used, and the service desk shown the per device view with application and script status.
- Corporate identifiers uploaded where required
- Enrolment restrictions aligned with the approach
- Monitoring demonstrated to the service desk
- Runbook covering the documented behaviours
Six situations where device preparation is the right choice.
An organisation already on Entra join
The prerequisite that decides it. For estates that completed the move away from domain join, device preparation offers a simpler profile model, faster deployment through direct group assignment, and considerably better reporting than the classic flow provides.
A business tired of maintaining images
It uses the OEM-optimised Windows preinstalled on the device, so custom images and drivers do not need maintaining for every model. The existing installation is transformed into a business-ready state rather than replaced, which removes the imaging infrastructure entirely.
A team that cannot see why deployments fail
Classic Autopilot troubleshooting is frequently guesswork. Near real-time status with device details, profile name and version, and per application and per script status turns a stalled deployment into a specific failing item, which is a different conversation with the vendor.
An operator shipping devices directly to sites
No technician touch and no per-device registration means a device can go from supplier to site and be provisioned by the person who opens the box. The percentage progress indicator and completion message matter here, because nobody technical is standing next to the machine.
A regulated firm that wants standard users by default
Device preparation makes users standard non-administrator users by default rather than leaving it as a setting somebody configures. For organisations where local administrator sprawl has been an audit finding, defaulting the right way is worth more than documenting the right way.
A company restricting enrolment to known hardware
Corporate identifiers allow pre-uploading serial number, manufacturer and model so only trusted devices go through device preparation. Microsoft notes this is only required where enrolment restrictions block personal device enrolment, which is a common configuration.
How UAE organisations 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 enrolment time, direct | Usually dynamic groups | Manual |
Apps during setup | Profile selected | Enrolment 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 | Device preparation | |
|---|---|---|
| Join type supported | Microsoft Entra join only | |
| Windows version required | Windows 11 24H2, or 23H2 and 22H2 with the March 2024 update | |
| Device registration needed in advance | No, and prior Autopilot registration takes precedence | |
| Grouping mechanism | Enrolment time grouping into a pre-defined device security group | |
| Group assignment type | Direct, which deploys faster than a dynamic device group | |
| Applications during setup | Only those selected in the profile | |
| Application types | Line of business and Win32 in the same deployment | |
| Policy application tracked | No, policies sync but application is not tracked | |
| User rights by default | Standard non-administrator | |
| Reporting | 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
Windows 11 version 24H2 or later, or 23H2 and 22H2 with the March 2024 update or later, and Microsoft Entra join rather than hybrid join. Both are hard requirements, and an estate failing either needs a different provisioning approach rather than an adjusted one.
- 2
Clear any classic Autopilot registrations
Where a device is registered or added as a Windows Autopilot device, the Autopilot profile takes precedence. Devices intended for device preparation need deregistering first, otherwise the pilot silently tests the mechanism you were moving away from.
- 3
Design the device group and profile content
A device security group for enrolment time grouping with direct assignment, since that deploys faster than a dynamic group. Then the split between applications and scripts selected in the profile, which run during setup, and everything else assigned to the group, which runs afterwards.
- 4
Build the profile and pilot on real hardware
A single profile covering deployment and out of box experience settings, tested on the actual models you deploy. Deployment time measured end to end, and the log export path exercised from a pilot device so the service desk knows it works before they need it.
- 5
Add enrolment controls and hand over the reporting
Corporate identifiers uploaded where enrolment restrictions block personal devices, and the near real-time monitoring demonstrated to the people who will use it, including the per application and per script status that makes troubleshooting specific rather than general.
What organisations 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 GCCH 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 enrolment?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.
Windows 11 24H2 or later, or 23H2 and 22H2 with the March 2024 update, and Entra join only. Those two answers decide whether device preparation is available to you before anybody builds a profile.
Related Services
Explore more solutions that work great with this service
Windows Autopilot Dubai
Zero-touch laptop deployment, supplier registration onward
Zero-Touch Deployment UAE
Sealed box to working device without IT touching it
Device Enrolment
Which path, which reset, and what you can enforce after
Intune Configuration Profiles
Settings catalog, templates and conflict management
Win32 App Packaging
Packaging, detection rules and deployment that works
MDM Solutions Dubai
Device management across Windows, Apple and Android
Microsoft Intune
Device management and endpoint security
Endpoint Security
Defender for Endpoint and Intune managed