- Home
- Corporate IT
- Device Management
- Windows Autopilot and Device Preparation: Differences, Workflows, and Choosing an Approach
Windows Autopilot and Device Preparation: Differences, Workflows, and Choosing an Approach
Section titled “Windows Autopilot and Device Preparation: Differences, Workflows, and Choosing an Approach”Microsoft offers two approaches to cloud-based Windows provisioning: traditional Windows Autopilot and Windows Autopilot Device Preparation, which uses a different architecture. Both connect a newly delivered PC to the organization’s management environment using configuration prepared by IT.
Both approaches typically use the manufacturer’s preinstalled Windows installation, reducing the need to maintain a custom image for every model. IT focuses on applications and policies instead. Traditional Autopilot overview, Device Preparation overview
This article compares both approaches and presents their workflows separately. The workflows cover user-driven employee PCs using Microsoft Entra join and Microsoft Intune. We use “traditional Autopilot” and “Device Preparation” to distinguish them. Requirements and documentation were checked on October 24, 2026.
What zero-touch provisioning means
Section titled “What zero-touch provisioning means”Provisioning means preparing a device with the settings and applications it needs. In both approaches, zero-touch generally means IT does not need to physically handle each PC before delivery.
Neither approach eliminates preparation or every user action. In user-driven deployments, employees still unbox the PC, power it on, connect to the internet, and authenticate with a work account. Language selection and multifactor authentication may also be required. This makes direct shipment to remote employees practical. Traditional user-driven mode, Device Preparation user-driven deployment
What OOBE means and how to pronounce it
Section titled “What OOBE means and how to pronounce it”OOBE stands for Out-of-Box Experience and is pronounced “OO-bee,” rhyming with “ruby.” Microsoft uses the term for the initial setup experience. Microsoft’s introduction to OOBE
In Windows, OOBE is the sequence of screens and actions presented when a new PC starts for the first time. It can include language, region, keyboard, networking, sign-in, Windows Hello, and privacy settings. The pages and their order vary with Windows and organizational configuration. Windows 11 OOBE
Both approaches connect this experience to organizational setup. The shared outline of a user-driven journey is:
- Start the PC and connect to a network during OOBE.
- Authenticate with a work account using the organizational setup flow.
- Join the organization, enroll in Intune, and receive assigned applications and settings.
- Complete the defined initial setup tasks and reach the desktop.
OOBE is the initial setup experience; ESP reports enrollment and configuration progress. Traditional Autopilot uses ESP, while Device Preparation uses its own progress experience.
How both approaches work with Entra ID and Intune
Section titled “How both approaches work with Entra ID and Intune”| Service | Main responsibility |
|---|---|
| Traditional Windows Autopilot | Uses preregistered devices and deployment profiles to guide setup and enrollment |
| Autopilot Device Preparation | Uses a dedicated policy and enrollment-time grouping to guide setup and enrollment |
| Microsoft Entra ID, formerly Azure AD | Handles organizational identity, authentication, and device join |
| Microsoft Intune | Delivers applications and policies and manages the device after deployment |
Both approaches work with management services for application delivery and ongoing administration. This article uses Intune. See the Microsoft Intune article for its responsibilities.
How it differs from traditional PC deployment
Section titled “How it differs from traditional PC deployment”Manual staging and imaging can include sophisticated automation. The comparison below contrasts that model with cloud deployment characteristics shared by both approaches.
| Area | Manual staging or imaging | Cloud deployment with either approach |
|---|---|---|
| Shipping | Devices pass through IT or a staging provider | Eligible devices can ship directly to employees |
| Operating system | IT maintains an image or configures Windows individually | Usually uses the preinstalled Windows installation |
| Configuration | Images, scripts, and individual tasks | Centrally assigned applications and policies |
| IT effort | Device-by-device preparation and checks | Configuration design, validation, and exception handling |
| Deployment location | Often a staging facility | A location with access to required cloud services |
Benefits shared by both approaches
Section titled “Benefits shared by both approaches”- Less repetitive work: Standard assignments reduce repeated configuration and opportunities for omissions.
- Simpler remote onboarding: Direct delivery can reduce shipping through an IT office.
- More consistent configuration: Applications and settings can be assigned by role or department.
- Less image maintenance: IT can focus on application packages and policies rather than model-specific images.
Reduced hands-on effort does not guarantee a shorter setup for the employee. Measure technician time separately from the time users spend waiting for downloads and installation.
Traditional Windows Autopilot vs. Windows Autopilot Device Preparation
Section titled “Traditional Windows Autopilot vs. Windows Autopilot Device Preparation”The user-driven experience of starting a PC and authenticating with a work account is similar in both approaches. Traditional Autopilot centers on preregistered devices and deployment profiles; Device Preparation uses a dedicated policy and enrollment-time grouping. Device Preparation is a separate deployment choice, rather than a product rename.
Configuration and capability comparison
Section titled “Configuration and capability comparison”| Area | Traditional Windows Autopilot | Windows Autopilot Device Preparation |
|---|---|---|
| Main configuration | Deployment profile, ESP, groups, app assignments | Device Preparation policy, designated device security group, app assignments |
| Autopilot device preregistration | Required | Optional; Device Association is also available |
| Join types | Entra join or hybrid join | Entra join |
| Deployment modes | User-driven, pre-provisioned, self-deploying, and others | User-driven and supported automatic deployment scenarios |
| Setup progress | ESP | Dedicated experience, with percentage progress for user-driven setup |
| Deployment reporting | Traditional Autopilot report | Near-real-time app and script status |
| Win32 and LOB apps together | Mixing has restrictions | Supported |
| Waiting for user configuration | Configurable through user ESP | No equivalent user ESP blocking |
| Autopilot Reset | Supported | Not supported |
Automatic deployment in Device Preparation is a different scenario from traditional self-deploying mode. Check the target devices and requirements rather than assuming equivalent behavior. Microsoft’s comparison
What changes for administrators
Section titled “What changes for administrators”Traditional Autopilot assigns deployment profiles to preregistered devices and uses ESP to define setup completion requirements. Device Preparation selects essential applications and PowerShell scripts through its dedicated policy. Application preparation and assignments are still necessary.
Enrollment Time Grouping adds the device directly to its designated group during Intune enrollment, reducing dependence on dynamic group evaluation. Selected apps and scripts run during OOBE; other assignments can arrive after deployment. Provisioning has limits, so keep the initial essential set focused. Device Preparation workflow
Optional Device Association
Section titled “Optional Device Association”Device Association binds a device to the organization’s tenant before MDM enrollment, using TPM-backed verification and affiliation information stored in UEFI. It enables corporate ownership recognition, supported OOBE customizations, and device-targeted policy assignments.
This differs from traditional hardware-hash registration. Optional preregistration does not mean that prior tenant association is unavailable. Device Association overview
Choosing between the two approaches
Section titled “Choosing between the two approaches”Device Preparation’s main benefits are simpler deployment preparation and clearer operational visibility.
| Benefit | Operational effect |
|---|---|
| Hardware-hash preregistration is not mandatory | Less dependence on reseller registration services |
| Devices join a predefined group during enrollment | Less waiting for dynamic group evaluation before delivery |
| Near-real-time deployment reports | Easier review of application and script failures |
| Win32 and LOB apps in the same deployment | Both application types can be included together |
Based on these differences, it is a strong candidate for eligible, supported Windows 11 employee PCs using Entra join and Intune, where users can sign in during initial setup. Evaluate it when purchasing through multiple channels or delivering a small essential app set first and the remaining apps later.
Traditional Autopilot remains relevant when you need pre-provisioning before shipment, Entra hybrid join, ESP blocking until user-targeted configuration completes, or Windows Autopilot Reset. Feature comparison
Both approaches can coexist in one organization. For example, pilot Device Preparation for new Entra join PCs while retaining traditional Autopilot where existing requirements justify it. One device does not run both simultaneously; check deployment precedence for its registration and association state.
Optional preregistration does not eliminate the need to identify corporate devices. Environments blocking personal enrollment can use corporate identifiers such as serial number, manufacturer, and model. Device preparation also does not track completion of every configuration policy, so the completion screen alone is not proof of security readiness. Corporate identifiers and policy delivery
Traditional Windows Autopilot workflow
Section titled “Traditional Windows Autopilot workflow”This workflow covers traditional user-driven Autopilot with Microsoft Entra join. It uses hardware-hash registration and a deployment profile.
1. Prepare the management environment
Section titled “1. Prepare the management environment”Set up accounts, licenses, and automatic MDM enrollment. Create the Autopilot deployment profile and target groups, then prepare the required Intune applications and policies.
2. Register the device with Autopilot
Section titled “2. Register the device with Autopilot”Ask the manufacturer or reseller to register it, or collect and upload its hardware hash internally. The hash represents multiple hardware attributes; it is more than a serial number.
Autopilot registration and Intune enrollment are separate steps. Registration identifies the device for deployment; it does not itself start ongoing device management. Registration overview
3. Verify assignments and deliver the PC
Section titled “3. Verify assignments and deliver the PC”Confirm that the intended deployment profile is assigned before the first setup. Provide the employee with connection instructions, account details, authentication guidance, and a support contact.
4. Connect and authenticate
Section titled “4. Connect and authenticate”During the Windows out-of-box experience (OOBE), the PC connects to the internet and retrieves its Autopilot profile. The employee authenticates, and the device joins Microsoft Entra ID and automatically enrolls in Intune. User-driven deployment sequence
5. Apply required configuration
Section titled “5. Apply required configuration”Intune delivers assigned applications and settings. The Enrollment Status Page (ESP) displays progress and can block desktop access while specified requirements are being completed.
Reaching the desktop does not necessarily mean every application or policy has arrived. The completion criteria depend on the ESP configuration. Enrollment Status Page
6. Verify readiness and continue management
Section titled “6. Verify readiness and continue management”Define operational acceptance checks for required applications, encryption, recovery-key storage, updates, and compliance. Continue managing the PC throughout its working life.
Windows Autopilot Device Preparation workflow
Section titled “Windows Autopilot Device Preparation workflow”This workflow covers the basic user-driven Entra join setup with a user-assigned policy. Device Association additionally enables device-targeted assignments and supported OOBE customization.
1. Prepare enrollment and target groups
Section titled “1. Prepare enrollment and target groups”Verify accounts, licensing, automatic Intune enrollment, and permission to join Entra ID. Create the target user group and an assigned device security group for enrollment-time grouping. Set Intune Provisioning Client as an owner of the device group.
2. Configure essential apps and the Device Preparation policy
Section titled “2. Configure essential apps and the Device Preparation policy”Assign applications and PowerShell scripts to the device group, then select which ones should run during initial deployment in the Device Preparation policy. Specify the enrollment device group and deployment settings, and assign the policy to the target user group. This replaces the traditional deployment-profile and ESP configuration steps.
3. Establish device identification as needed and deliver the PC
Section titled “3. Establish device identification as needed and deliver the PC”Traditional Autopilot device registration is not mandatory. If personal enrollment is blocked, configure corporate identifiers or Device Association to identify trusted corporate devices. Associated devices do not also need a corporate identifier upload.
For PCs already registered with traditional Autopilot, check deployment precedence for their registration and association state. Deliver the prepared PC with setup instructions. Preparation steps and identification requirements
4. Authenticate during OOBE and retrieve the policy
Section titled “4. Authenticate during OOBE and retrieve the policy”The employee starts the PC, connects to a network, and authenticates with a work account during OOBE. In this basic configuration, the policy assigned to that user is delivered to the device and defines its deployment.
5. Join Entra ID, enroll in Intune, and join the device group
Section titled “5. Join Entra ID, enroll in Intune, and join the device group”The PC joins Entra ID and enrolls in Intune. Enrollment Time Grouping adds it to the designated device group so it can receive assignments. The Intune management extension also installs. Enrollment Time Grouping
6. Process the selected essentials
Section titled “6. Process the selected essentials”The deployment installs selected applications and runs selected PowerShell scripts, displaying its dedicated progress experience. Successful completion leads to the required-setup completion screen. It does not use traditional ESP or user ESP blocking.
7. Reach the desktop and receive additional configuration
Section titled “7. Reach the desktop and receive additional configuration”After the employee dismisses the completion screen, the desktop appears. A further sync delivers additional assigned apps and scripts not selected for initial provisioning, along with user-targeted configuration.
Device Preparation does not track every configuration policy to completion before opening the desktop. Define business readiness separately from deployment completion and continue validation through Intune. Post-authentication deployment sequence
Requirements and practical limitations for both approaches
Section titled “Requirements and practical limitations for both approaches”Manufacturer and reseller support varies
Section titled “Manufacturer and reseller support varies”Distinguish vendor-assisted registration from device eligibility. A reseller’s inability to register a purchase does not automatically make the PC incompatible: qualifying existing devices can also be registered internally.
For unopened shipment using traditional Autopilot, confirm registration support for the exact model and purchasing channel, along with fees, lead times, and repair handling. Registration options
Device Preparation does not require that traditional registration service. Still verify the Windows release and updates shipped with the device, and the applicable requirements if using Device Association. Device Preparation requirements
Licensing
Section titled “Licensing”You need an eligible Windows edition plus the relevant identity and MDM entitlements. Common Intune-based combinations include Microsoft 365 Business Premium, Microsoft 365 E3/E5, or Microsoft Entra ID P1/P2 with Microsoft Intune.
Assign the necessary licenses to enrolling users. A subscription that provides Office applications is not automatically sufficient for either approach. Check shared-device scenarios separately. Traditional Autopilot licensing, Device Preparation licensing
Operating system and deployment mode
Section titled “Operating system and deployment mode”For new deployments, verify a supported Windows 11 release and an eligible edition such as Pro, Enterprise, or Education. Windows Home is not supported.
Device Preparation requires Windows 11 and has specific version and update prerequisites. Check the factory-installed state rather than relying only on the OS name. Traditional Autopilot also depends on the OS support lifecycle and the selected deployment mode’s requirements.
Traditional Autopilot pre-provisioning lets IT or a partner perform time-consuming tasks before delivery, reducing the employee’s remaining setup work. It requires eligible physical hardware with TPM 2.0 and device attestation. Pre-provisioning requirements
Traditional self-deploying mode serves kiosks and shared PCs without requiring user authentication during provisioning. It also requires TPM 2.0 attestation and supports Entra join rather than hybrid join. This is distinct from Device Preparation’s automatic deployment scenarios. Self-deploying mode
Network access, application packaging, and support
Section titled “Network access, application packaging, and support”A useful pilot should check whether:
- Home networks and office proxies allow setup to finish.
- Application packages install silently and handle detection and restarts correctly.
- The essential application set produces an acceptable waiting time.
- Support staff can obtain logs and help recover failed deployments remotely.
Internet connectivity alone does not guarantee access to every required service. Validate endpoints against the requirements for traditional Autopilot and Device Preparation.
Evaluating a rollout
Section titled “Evaluating a rollout”Both approaches shift device-by-device staging toward centrally designed and validated configuration. First define join requirements, preparation before delivery, and setup completion criteria. Select an approach that meets them, then pilot procurement, first sign-in, required applications, and failure recovery. Compare IT labor, shipping steps, employee waiting time, and first-attempt success to assess the outcome.
Further reading
Section titled “Further reading”These Japanese-language articles provide introductory context and deployment examples. Use the Microsoft documentation linked above to verify technical requirements.