If your enterprise fleet is still on Windows 11 24H2, you are not behind — but the clock is running. Windows 11 25H2 is the correct mainstream upgrade target for existing x86/x64 hardware in 2026, and Autopilot v2 (Device Preparation) reached general availability in late 2025. Together, they change the deployment calculus enough that a guide written before this year is probably missing a few things that will bite you.
This article covers the practical workflow: which OS target to pick and why, how to configure the Device Preparation policy, how to avoid the Conditional Access trap that kills every third Autopilot rollout, and how to structure rollout phases so you are not triaging failures at scale.
Why 25H2: The Case Against Waiting for 26H1
Unless you are deploying new Arm-based Copilot+ hardware, skip 26H1.
Microsoft positioned Windows 11 26H1 primarily around Snapdragon X2 optimizations and Neural Processing Unit scheduling improvements. For existing Intel/AMD fleets, those features are irrelevant. The operational upside of waiting for 26H1 is zero. The downside is spending several months on an untested path while 25H2 continues accumulating quality updates.
What matters for planning:
- Support window: Windows 11 25H2 Enterprise/Education receives 36 months of support from September 30, 2025. That is enough runway for a methodical migration without re-imaging pressure.
- April 2026 cumulative update (KB5055523): This update resolves OOBE-phase Autopilot enrollment timeouts on specific Dell Latitude and HP EliteBook models during Device Preparation policy provisioning. If you have a mixed OEM fleet, treat KB5055523 as a prerequisite. Apply it before broad rollout or slip-stream it into your deployment media.
- Pin your feature update policy: In Intune’s Windows Update for Business, explicitly target Windows 11, version 25H2 rather than “Latest feature update.” The moment 26H1 reaches your update ring’s GA threshold, an open-ended policy will pull devices across before you have validated it. That is not a theoretical risk.
Autopilot v2 vs v1: Choose Deliberately
Autopilot v2, formally called Device Preparation, changes how provisioning is orchestrated at the architecture level. The decision to use it should be deliberate, not automatic.
What v2 changes:
- Device Preparation policies replace per-device deployment profiles. Policies are scoped to Entra ID device groups, not individual device objects.
- Hardware hash CSV is no longer the primary registration path. Devices register through Entra direct registration or OEM/Partner Center integration.
- MDM API call volume during OOBE is reduced, shortening the provisioning sequence by 8 to 15 minutes in most environments.
- A small set of apps (maximum 10) is tracked in a simplified status screen during provisioning. The full Enrollment Status Page is still present, but the primary blocking logic moves to the Device Preparation sequence.
When to stay on v1:
- Hybrid Entra Join deployments where devices must join an on-premises AD domain during OOBE. As of April 2026, v2 Device Preparation does not support Hybrid Join. v1 profiles with the Hybrid Join connector remain the supported path.
- White glove and technician pre-provisioning workflows on existing hardware. v2 supports pre-provisioning, but the steps differ enough to require retraining and lab validation before touching field engineers.
- Devices currently registered under v1 profiles being re-enrolled. The v1 profile stays active until you explicitly delete it and re-register the device.
Run both workflows in parallel if your fleet has a mix of cloud-native and Hybrid Join machines. Do not try to force everything into v2 on a deadline.
Tenant Readiness: The Checklist You Actually Need
Most Autopilot failures trace back to gaps that a pre-flight check would have caught. Work through this before touching a deployment profile.
| Item | Requirement |
|---|---|
| Intune service release | April 2026 or later (Tenant administration > Tenant status) |
| Entra ID licensing | P1 minimum; P2 for PIM-gated LAPS and risk-based Conditional Access |
| Windows Enterprise licensing | E3/E5 or Microsoft 365 E3/E5 |
| Autopilot v2 enabled | Devices > Windows > Enrollment > Device Preparation policies visible |
| MDM authority | Intune only (no co-management authority conflict) |
| Conditional Access | OOBE-phase exclusion in place (see next section) |
| Diagnostic endpoint reachability | *.manage.microsoft.com and *.dm.microsoft.com reachable from deployment subnet |
The Conditional Access trap
Missed Conditional Access exclusions are the single most common cause of Autopilot enrollment failures. Here is what happens: during OOBE, the device authenticates with the user’s credentials before the device is compliant. If you have a CA policy requiring a compliant device for All Cloud Apps, it will block the enrollment before the device has had a chance to become compliant. The device is stuck before it can reach the state the CA policy requires.
The fix must be in place before rollout begins.
Create a named device group for Autopilot-provisioning devices and exclude it from any CA policy with “Require compliant device” or “Require Entra hybrid joined device” as a grant control. Alternatively, use Microsoft’s documented Autopilot bootstrap exclusion, which scopes the exclusion to the Windows Enrollment application during the provisioning window. Document which approach you choose and put it in your change log so it does not get removed during your next CA policy audit.
Configuring the Device Preparation Policy
In the Intune admin center, navigate to Devices > Windows > Enrollment > Device Preparation policies > Create.
Deployment mode: User-driven for most enterprise scenarios. Pre-provisioned (Technician Flow) is useful when pre-loading heavy LOB apps before shipping hardware to users, but it adds an OOBE step and requires field engineer retraining.
Join type: Microsoft Entra joined for cloud-native endpoints. If you need Hybrid Join, stop here and use a v1 profile.
User account type: Standard. Combine with Windows LAPS for local administrator account control rather than provisioning users with local admin rights.
Allowed device group: Scope the policy to a dynamic Entra ID device group based on the group tag set during hardware registration:
(device.devicePhysicalIds -any (_ -eq "[OrderID]:EnterpriseLaptop-25H2"))Use group tag names that reflect your deployment rings (Pilot-25H2, Broad-25H2) rather than hardware model. OEM models change; ring structure should not.
Apps tracked during Device Preparation: Keep this list short. Every app on it is a blocking dependency. A realistic minimum for a 25H2 enterprise deployment is Microsoft 365 Apps for Enterprise and your endpoint security agent. Add a VPN client only if users cannot reach resources without split-tunnel access. Everything else should be required but non-blocking, or available for background install.
App Tiering: The Difference Between a 45-Minute Enrollment and a 4-Hour One
The longest Autopilot enrollments — and most of the ESP failures — come from poor app deployment decisions, not profile configuration. Three tiers works in practice.
Tier 1 (ESP blocking, must complete before desktop):
- Microsoft 365 Apps for Enterprise (deploy as Required, assigned to device group, not user group)
- Endpoint security agent
- VPN client
Tier 2 (Required, non-blocking):
- Browser enterprise policies
- Certificate profiles
- Monitoring and telemetry agents
Tier 3 (Available):
- Department tools, developer tooling, optional productivity apps
For M365 Apps, deploy using the Microsoft 365 Apps (from Microsoft) app type in Intune with a custom XML configuration. The store variant has slower delivery and less channel control. Set the update channel to Monthly Enterprise Channel for production stability. Current Channel belongs in dev/test rings only.
For LOB applications in Tier 1, package as Win32 (.intunewin format). Script-based installs are less reliably tracked by the MDM agent for ESP state reporting. For each Win32 app in the blocking list, confirm a working detection rule before adding it. Use a file version check, registry key, or MSI product code. Test on a clean Windows 11 25H2 VM before the policy goes near production devices.
Update Ring Strategy
Run three rings minimum. More than five adds governance overhead with diminishing operational returns for most fleet sizes.
- Ring 1 (Pilot, 5-10% of fleet): Zero-day deferral on quality updates. Feature update policy pinned to Windows 11 25H2.
- Ring 2 (Early Adopters, 20-30% of fleet): 7-day deferral on quality updates. Feature update pinned to 25H2.
- Ring 3 (Broad, remaining fleet): 14-day deferral. Feature update pinned to 25H2.
Review Ring 1 for seven days after each Patch Tuesday before promoting Ring 2. The April 2026 Security Update (KB5055523) should be the first update you validate in Ring 1 if you have Dell or HP hardware in the fleet.
Your compliance policy minimum OS version should target the Windows 11 25H2 baseline build (10.0.26100.xxxx). Set the compliance grace period to 72 hours during initial rollout. This prevents devices from being flagged non-compliant before BitLocker encryption and required policies have had time to apply. Reduce to 24 hours after the rollout stabilizes.
Phased Rollout: The Sequence That Does Not Generate Incidents
Phase 0: Lab Validation (1-2 weeks)
Build a clean 25H2 Autopilot v2 environment in a test tenant or isolated Intune instance. Enroll 3 to 5 devices representing your OEM mix through the full provisioning flow. Validate that ESP completes and the device joins Entra ID with all Tier 1 apps installed. Document your baseline provisioning time from OOBE start to desktop ready. Run the disaster recovery test: wipe a device, re-enroll, confirm it reprovisioned correctly.
Phase 1: Pilot (weeks 1-2)
Target IT staff and helpdesk volunteers who understand this is a test and will give useful failure reports rather than just logging a ticket. 10 to 50 devices depending on fleet size. Check Intune’s enrollment failure report daily. Success threshold: zero unresolved ESP failures, compliance rate at or above 95%, provisioning time within 20% of your lab baseline.
If Phase 1 surfaces failures, stop. Do not expand until root cause is confirmed. The two most common Phase 1 failures are a CA policy exclusion that was missed and an ESP-blocking app with a detection rule that does not match the 25H2 install state.
Phase 2: Early Adopters (weeks 3-5)
Department leads, project volunteers, lower-risk business units. Expand device deployment rings. Maintain daily monitoring. Set an Intune alert for enrollment failure rates above 5%.
Phase 3: Broad Deployment (weeks 6-10)
Remaining fleet. At this point your provisioning process should require no manual intervention for the majority of devices. Budget a remediation buffer of roughly 5% per week for devices that need hands-on work. The typical cases are hardware that was not pre-registered and devices carrying conflicting v1 profiles. OEM firmware that predates Autopilot v2 compatibility fixes is a smaller but real category on older Dell and HP models.
Common Failure Points
| Symptom | Likely Cause | Fix |
|---|---|---|
| ESP stuck at 0% (“Identifying your device”) | Device not registered in Autopilot | Verify in Intune > Devices > Enrollment > Windows Autopilot devices. Allow 15 minutes for sync after import. |
| ”Something went wrong” after user sign-in | CA policy blocking OOBE auth | Audit CA policies for “Require compliant device” without Autopilot exclusion |
| M365 Apps hanging at ESP (>45 min) | CDN routing or bandwidth saturation | Check Delivery Optimization config; verify proxy is not intercepting HTTPS to CDN endpoints |
| App detection rule failing | Rule does not match install state on 25H2 | Test rule on a clean 25H2 VM; check 32-bit vs 64-bit path mismatch |
| Device marked non-compliant immediately | Grace period too short or BitLocker not yet complete | Set grace period to 72 hours during rollout |
| ”Device is already managed” error | Previous enrollment record not cleaned up | Remove from Intune device list, delete Autopilot object, factory reset |
When a device fails during OOBE, pull the diagnostic logs before wiping:
mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -cab C:\Temp\autopilot-diag-$env:COMPUTERNAME.cabRun that before touching anything else. The diagnostic cab gives you the event log and MDM enrollment state alongside the full policy application trace. Those three data points tell you whether the failure was a CA block, a network reachability issue, or an app install problem.
What This Does Not Cover
A few things are intentionally outside the scope of this article.
Hybrid Entra Join: If your devices need to join on-premises AD during OOBE, the v2 Device Preparation policy is not the right tool as of May 2026. Use v1 profiles with the Intune Connector for Active Directory.
SCCM co-management migration paths: Migrating devices from co-management to Intune-only as part of this rollout is a separate workload with its own sequencing requirements.
Copilot+ PC and Arm64 considerations: Windows 11 26H1 brings meaningful changes for Snapdragon X2 hardware. If new Copilot+ PCs are part of your 2026 procurement cycle, plan a separate 26H1 validation track for that hardware segment and keep it isolated from your existing x64 fleet rollout.
The Practical Summary
Windows 11 25H2 with Autopilot v2 is a well-documented, well-understood deployment path by mid-2026. The main failure modes are not architectural — they are operational. CA policies that were not audited before rollout. App blocking lists built without detection rule testing. Update ring policies left open-ended. Pin your feature update target to 25H2. Apply KB5055523 before touching OEM hardware. Run the phased sequence. The rollout that generates no incidents at 3 AM is the one that spent two weeks in Phase 0.