How user-driven, pre-provisioned and self-deploying Autopilot modes differ in join type, user interaction and TPM requirements.
From Ultra Transcenders MD-102 by Tony Rough (coming December 2026)
The deployment mode decides who interacts with the device, how the device proves its identity and which join types are possible. Figure 6.1 compares who touches the device in each of the three main modes.
| Capability | User-driven | Pre-provisioned | Self-deploying | Existing devices | Reset |
|---|---|---|---|---|---|
| Microsoft Entra join | Yes | Yes | Yes | Yes | Yes |
| Microsoft Entra hybrid join | Yes | Yes | No | Yes | No |
| User interaction | Yes | Yes (user flow) | No | Not applicable | Local reset |
| IT, OEM or reseller interaction | No | Yes (technician flow) | No | Yes | Remote reset |
| Assigns a user to the device | Yes | Yes | No | Not applicable | Not applicable |
| TPM authenticates the device | No | Technician flow | Yes | Not applicable | Not applicable |
| Must be registered first | Yes | Yes | Yes | No | Yes |
User-driven mode associates the device with the user who signs in at the branded Entra sign-in page; together with automatic MDM enrollment this gives the “sign in at OOBE and the device enrols itself” experience. Microsoft Entra company branding supplies the logo and sign-in text shown during OOBE.
Pre-provisioning splits the work. In the technician flow, IT, a partner or the OEM presses the Windows key five times at the first OOBE screen, chooses Windows Autopilot provisioning, checks the profile, organisation, assigned user and QR code, and selects Provision. Device-targeted policies and apps install (plus user-targeted, device-context apps for a preassigned user); on success the technician selects Reseal. The user flow later completes user-targeted configuration.
Self-deploying mode needs no user credentials: the TPM authenticates the device, it joins Microsoft Entra ID, enrols, and the ESP holds it until provisioning finishes. It suits kiosks, digital signage and shared devices.
Windows Autopilot for existing devices uses a Configuration Manager task sequence to wipe and reinstall Windows and drop an AutopilotConfigurationFile.json (ASCII or ANSI, one profile per file) so the device runs a user-driven Autopilot deployment on first boot. The JSON supports only user-driven Entra join and user-driven hybrid profiles; self-deploying and pre-provisioning need TPM attestation. If the device is already registered with an assigned profile, that profile wins. It is also a documented route for moving hybrid joined devices to Microsoft Entra join.
Common trap: Testing self-deploying or pre-provisioning on a Hyper-V virtual machine - both need physical TPM 2.0 attestation, and VMs (including virtual TPMs) fail with 0x800705B4.
Common trap: Believing self-deploying mode depends on a firmware-embedded Windows Pro product key - what it depends on is TPM 2.0 with device attestation.
Common trap: Using an Autopilot deployment profile to take over existing domain-joined PCs in place - Convert all targeted devices only registers devices and doesn’t convert hybrid joined devices; existing domain machines are enrolled through hybrid join with automatic enrollment (see “Enrolling Windows, macOS and Apple mobile devices”) or reinstalled with Autopilot for existing devices.
This note is one section of Ultra Transcenders MD-102: Managing and Securing Microsoft 365 Endpoints by using Intune, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · MD-102 terms in the glossary · All MD-102 study notes
How Microsoft Entra registered, Entra joined and hybrid joined devices differ in ownership, sign-in, management and the scenarios each one suits.
The tenant-wide compliance settings and per-platform policies behind Intune compliance, and how a device's overall status is worked out.
Which devices can back up a local admin password to Entra ID or Active Directory, and how to build the Windows LAPS policy in Intune.
The six ways Intune manages Android devices, from personal work profiles to fully managed, dedicated and AOSP, and how to choose between them.
What each Enrollment Status Page setting does, from blocking apps and time limits to quality updates during OOBE, and where to create profiles.
Which Intune remote action keeps personal data and which resets the device, with platform support, wipe options and daily limits.
How Intune update rings set quality and feature update deferrals, deadlines, grace periods and restart behaviour for groups of Windows devices.
How Intune app protection policies protect work data inside apps on enrolled and personal devices, and the three-level data protection framework.