Windows Autopilot Overview
The core use case of Windows Autopilot is to allow automatic configuration and setup of endpoints across an enterprise. Once configured, it can take a fresh out of the box copy of Windows into a user ready state with little to no intervention from IT admins. In general, old fashioned “Imaging” should be avoided with modern device management. As an alternate, consider using pre-provisioned deployment.
Enrollment Modes
Section titled “Enrollment Modes”Designer for end-user enrollment, aimed at devices with user affinity. If provisioning timing is a concern for your end user expierence, consider using pre-provisioned deployment for User-driven mode
Used for public facing devices when no user input is expected during setup. Ideal for shared-use machines, labs, kiosks, and signage endpoints. No user signs in during OOBE.
Comparison: Deployment modes
Section titled “Comparison: Deployment modes”| Feature | User-Driven Enrollment | Self-Deploying |
|---|---|---|
| User Presence | Required during setup | Not required |
| Device Assignment | Linked to primary user | Device-level, not tied to one user |
| Personalization | High – user-specific apps, settings | Low – apps and settings are device-wide |
| App Deployment | Per-user | Per-device |
| Reset Behavior | Retains user data and config | Reset to default state |
| Use Cases | Dedicated devices, remote workers | Labs, reception, kiosks, signage |
Shared Behaviors
Section titled “Shared Behaviors”ESP (Enrollment Status Page)
Section titled “ESP (Enrollment Status Page)”The Enrollment status page is displayed during the Autopilot process, and delegates which apps are deployed and configures what is displayed during this process. Ideally, you would need very few ESP’s as it should be very bare-bones, and not be used to deploy a full suite of applications.
- ESP starts after network is established.
- Required apps and configurations are applied.
- User (or device) reaches desktop or login screen.
- Keep ESP lightweight to avoid bloated deployment times and time outs.
- Avoid large apps like Microsoft Office or Adobe creative cloud at this stage.
- Focus on reporting/IT administration apps, if any during this stage.
Reset Behavior
Section titled “Reset Behavior”Both Autopilot modes support reset workflows. However:
- User-driven: Use Autopilot Reset to reassign and reconfigure quickly.
- Self-Deploying: Autopilot Reset is not supported. Use a full wipe instead and it should re-enroll
- User-driven with pre-provision
Record Lifecycle
Section titled “Record Lifecycle”The lifecycle of devices should be relatively straight forward and kept simple. By default, once onboarded into autopilot, a device should not be removed until full retirement.
- Device hash is uploaded during purchase/onboarding.
- Device is assigned and used.
- When reassigned or reset, Autopilot record stays in place.
- Only remove from Intune, Entra, and Autopilot at end-of-life.
Software best practice guidelines for OEM Windows Autopilot
Section titled “Software best practice guidelines for OEM Windows Autopilot”- The Windows Autopilot device should be preinstalled with only a Windows base image plus drivers.
- Licensed versions of Office, such as Microsoft 365 Apps for enterprise, can be preinstalled.
- Unless explicitly requested by the customer, no other preinstalled software should be included.
- Per OEM Policy, Windows features, including built-in apps, shouldn’t be disabled or removed.
The above guidance supports the device lifecycle, improving performance of the Autopilot Program and minimizing the need to debloat the OS during deployment