Two years ago, an IT team at a global manufacturing company unboxed 500 new laptops expecting a smooth Windows Autopilot rollout. Instead, the project stalled for days—hardware hashes weren’t uploaded correctly, ESP hung on app installs, and Hybrid Join devices kept looping through OOBE.
It was a familiar story: Autopilot (classic) is powerful, but it demands precision, infrastructure alignment, and patience.
Fast‑forward to today. A new shipment arrives—same company, same scale—but this time something is different.
Devices don’t have to be pre‑registered. No ESP purgatory. No “why did that app install before that one?” mysteries. Users sign in, policies land cleanly, provisioning progress is visible, and devices are ready fast.
This is Autopilot Device Preparation — often called Autopilot v2 — a re-architected provisioning experience built for speed, simplicity, and cloud-first identity, which Microsoft positions as a “next generation” Autopilot experience, built alongside classic Autopilot to deliver faster iteration and improved reporting without disrupting existing customers.
Yet the choice between Autopilot v1 vs Autopilot v2 (AP-DP) isn’t as simple as “newer must be better!”
If you run hybrid identity, support certain device types, rely on pre-provisioning/white glove, or need deep OOBE control, Autopilot v1 still does things v2 can’t. Conversely, if you’re cloud-native and rolling out Windows 11 at scale, v2 can dramatically reduce operational friction and improve reliability with near real-time visibility.
This post gives you a strategic, scenario-based comparison so you can pick the right model based on identity, device mix, app strategy, and modernization goals.
Table of Contents
1. Autopilot v1 vs Autopilot v2 (Device Preparation): Core Concept Differences
Autopilot v1 (Classic Autopilot)
Classic Autopilot hinges on device registration so that the Autopilot service recognizes the device at the beginning of OOBE and can apply an Autopilot profile early. It supports multiple provisioning modes (user-driven, pre-provisioned, self-deploying, existing devices) and both Entra join and Entra hybrid join.
- Requires device registration (hardware hash upload or OEM registration).
- Supports many deployment modes (User‑Driven, Self‑Deploying, Pre‑Provisioning, Existing Devices).
- Supports both Entra ID Join and Entra Hybrid Join.
- Provides broad customization during OOBE and ESP.
Autopilot v2 (Device Preparation)
Device preparation is designed to simplify and speed deployments.
- No hardware hash required; uses dynamic device registration during sign‑in.
- Supports only User‑Driven and Automatic (Windows 365) modes. No Self‑Deploying/Hybrid/Pre‑Provisioning.
- Supports Entra ID Join only — no Hybrid Join.
- Streamlined provisioning policy mode.
- Delivers near real-time deployment status and richer troubleshooting.
Microsoft’s own framing: device preparation is built on re-engineered architecture to “deliver more efficient results” and improve reporting, while running “in tandem” with classic Autopilot until the experience can be unified.
2. Device Registration & Identity
| Feature | Classic Autopilot (v1) | Autopilot Device Preparation (v2) |
| Hardware Hash Required | Yes (unless OEM registers) | No (dynamic registration) |
| OEM/CSV Pre‑Registration | Required for identifying device before OOBE | Not required |
| Corporate Identifiers | Optional | Required only when personal device enrollment is blocked |
| BYOD Filtering | Through hash | Through corporate identifiers |
3. Deployment Modes & Join Types
| Deployment Mode | v1 Support | v2 Support |
| User‑Driven | ✔️ | ✔️ |
| Self‑Deploying | ✔️ | ❌ |
| Pre‑Provisioning (White Glove) | ✔️ | ❌ |
| Existing Devices (ConfigMgr + JSON) | ✔️ | ❌ |
| Automatic (Windows 365 Frontline) | ❌ | ✔️ |
| Hybrid Join | ✔️ | ❌ |
Conclusion:
Classic Autopilot (v1) is the only option for Hybrid, Self‑Deploying, and White‑Glove scenarios.
4. OOBE & ESP Experience
Autopilot v1 (Classic)
- Traditional Windows OOBE → downloads Autopilot profile
- Fully separate ESP with device phase + user phase
- Supports device naming, branding, OOBE page customization
Autopilot v2 (Device Preparation)
- Combines OOBE + provisioning into a single unified flow
- Shows a cleaner progress screen
- ESP is integrated, not the classic separate ESP process ref.
- Fewer customization options, e.g., device naming not supported
Result: v1 = rich customization. v2 = simple, guided, faster but limited.
5. App & Script Delivery
| Capability | v1 | v2 |
| # Apps during provisioning | Up to 100 overall (device + user ESP) | Up to 10 essential apps (Win32, LOB, Store, 365) during OOBE |
| Script Support | Post‑enrollment only | Scripts run during provisioning (pre‑desktop) |
| App Install Order | Unpredictable, parallel installs | Structured order (MSI → Win32 → others), fewer failures |
| Win32 + LOB together | ❌ | ✔️ |
Result: v2 significantly improves reliability and order of app deployment.
6. Reporting & Troubleshooting
| Capability | v1 | v2 |
| Deployment Status | Basic | Near real‑time, phase tracking |
| Script Results | Not shown | Available |
| App‑Level Diagnostics | Limited | Good detail (not perfect) |
| Device Prep Deployment Report | ❌ | ✔️ |
Result:v2 dramatically improves monitoring, visibility, and diagnostics.
7. Windows Version & Device Type Support
| Feature | v1 | v2 |
| Windows 10 Support | ✔️ | ❌ (Win11 only) |
| Windows 11 Support | ✔️ | ✔️ (24H2+ recommended) |
| HoloLens / MTR Devices | ✔️ | ❌ |
| Government Cloud (GCC High / DoD) | ❌ | ✔️ |
| VMs / VDI | ✔️ | Limited / Windows 365 specific (Automatic mode) |
8. Customization Flexibility
| Feature | v1 | v2 |
| Device Naming | ✔️ Supported | ❌ Not supported |
| OOBE Page Control | Highly customizable | Limited |
| Self‑Deploying Kiosk Flow | ✔️ | ❌ |
| White‑Glove/Pre‑Provisioning | ✔️ | ❌ |
| Hybrid Join Customization | ✔️ | ❌ |
9. Performance & Speed
Autopilot v1
- Speed depends heavily on
- Number of apps
- Complexity of policies
- ESP reliability
- Parallel app installs often lead to failures.
Autopilot v2
- Faster OOBE due to:
- No hardware hash preregistration
- Streamlined profile model
- Structured app sequencing
- Fewer apps/scripts allowed (reduces failure surface)
- Clearer progress UI
- Reliability significantly improved
🆚Quick comparison overview of Classic Autopilot vs Autopilot Device Preparation
| Classic Autopilot | Intune Device Preparation (Previously Autopilot Device Preparation) |
   |    |
| Supports Windows 10 and Windows 11. | Only supported on Windows 11 22H2 and 23H2 having the March 2024 update (KB5035942). It won’t be backported to Windows 10, so no support for Windows 10. |
| Device needs to be registered to Autopilot service – either manually using device hash or by OEM. | No need for device pre-registration if BYOD enrolment for Windows platform on the tenant is not restricted. If it is, then you need to pre-register devices to allow Device Preparation to go through vide Corporate Device Identifier. |
| Device ownership gets marked as Corporate from the beginning. | For devices provisioned via Device Preparation method, devices first enrol as Personal device and later the ownership is flipped by the service to Corporate. Thus for a device to be able to successfully go through AP v2 provisioning, the tenant must allow BYOD enrolment or else pre-register device vide CDI as mentioned in above point. |
Device provisioning monitored by old ESP experience | Device provisioning monitored by new ESP experience |
| Takes effect from the very initial phases of OOBE. Thus curating OOBE experience possible with Autopilot. | Device Preparation takes effect at the later stages of OOBE, post user sign-in. As such, curating OOBE experience is not possible, at least now, and user has to go through OOBE pages like accepting EULA and others which are otherwise hidden with normal Autopilot. |
| ESP allows to track Apps only. Not recommended to have both Win32 and MSI tracked in ESP. | New ESP allows to track Apps and Scripts, max 10 items. You can have both Win32 and MSI tracked in ESP. |
| ESP completes to present user with the desktop directly. | New ESP shows a new screen to make users understand device provisioning completed.  Â Â |
| Lacks the real-time reporting. | Comes with real-time reporting. |
🧠Summary: Which One Should You Use?
Choose Autopilot v1 when:
- âś” You need Hybrid Join
- ✔ You require Self‑Deploying or Kiosk mode
- ✔ You use White‑Glove/Pre‑Provisioning
- âś” You need deep customization (naming, ESP control, app volume)
- âś” You deploy Windows 10, HoloLens, Teams Room Devices, VMs
- âś” You need >10 apps/scripts during provisioning
Choose Autopilot v2 when:
- âś” You want fastest provisioning
- ✔ You want simplified zero‑touch enrollment
- âś” You want no hardware hash
- ✔ You need real‑time reporting and troubleshooting
- âś” You deploy Windows 11 only
- ✔ You operate cloud‑first Entra ID environments
- âś” You accept limited customization in exchange for speed
📌 Ultimate One‑Line Summary
Classic Autopilot (Autopilot v1) = Maximum flexibility & legacy compatibility (but slower, more complex).
Autopilot Device Preparation (Autopilot v2) = Fastest, simplest, most reliable cloud‑first onboarding — but with limited features.
Sources:
Compare Windows Autopilot device preparation and Windows Autopilot | Microsoft Learn
Overview of Windows Autopilot device preparation | Microsoft Learn
Windows deployment with the next generation of Windows Autopilot | Microsoft Intune Blog
Windows Autopilot device preparation known issues | Microsoft Learn
Windows Autopilot device preparation troubleshooting FAQ | Microsoft Learn
Be the first to comment