Windows Autopilot Deployment Modes Explained: User-Driven, Self-Deploying, and White Glove

A shipment of forty kiosk devices lands at three regional sites. The Autopilot profile is set to self-deploying so a technician can plug each one into Ethernet, walk away, and come back to a fully provisioned, auto-signed-in kiosk. Instead, every device sits at a plain "Let's start with region" screen, waiting for someone to pick a language and type in a local account. No branding, no ESP, no policy. Autopilot never ran. Nobody touched a setting since the last successful pilot three weeks ago — and that's exactly the problem, because the pilot devices were never re-imaged, and the pilot's Intune device records were never deleted before this batch shipped.

Windows Autopilot doesn't have one deployment flow with a few options — it has three genuinely different modes, each with its own identity requirements, hardware requirements, and failure behaviour. Picking the wrong one, or leaving a stale record behind from a previous run, doesn't produce a helpful error dialog. It produces a device that quietly reverts to plain, unmanaged, standard Windows setup. This post walks through what each mode actually does, when to use which, where the prerequisites diverge, and the specific misconfiguration that causes this drop-to-OOBE behaviour most often in production.

The problem — Autopilot doesn't fail loudly, it fails by simply not showing up

Here's the side-by-side that's worth pinning to a wiki page, because "which mode should this batch use" is a question that comes up every time a new device order lands:

That third column is where most planning mistakes start. It's tempting to assume White Glove supports hybrid join everywhere because the end-user phase can complete as hybrid-joined — but the technician phase that does the heavy lifting still runs on self-deploying's mechanics underneath, which means the TPM 2.0 and attestation requirement applies regardless of which join type the finished device ends up using.

The three modes are: user-driven (the default — a real person signs in with their own credentials during OOBE), self-deploying (little to no user interaction, intended for kiosks, shared devices, and digital signage), and pre-provisioning, also called White Glove (a technician does the time-consuming provisioning work up front, then the end user just signs in and finishes in minutes). Each is selected explicitly on the Windows Autopilot deployment profile in Intune — there's no automatic detection of "what kind of device is this."

That explicit selection is exactly where things go wrong, because the profile only controls what Windows Autopilot tries to do. It doesn't guarantee the device is eligible for that mode, and it doesn't guarantee the profile will even be delivered before the device connects to a network during OOBE. When either of those things is off, the device doesn't fall back to a "simpler" Autopilot mode — it falls all the way out of Autopilot and into completely standard, unbranded Windows Setup, as if it had never been registered at all.

In practice, the decision of which mode to use comes down to three questions: does a named person own this device, does it need to be unattended, and does IT need hands-on time before it reaches the user? Knowledge-worker laptops going to named employees are almost always user-driven — someone signs in with their own identity and the device becomes theirs. Kiosks, shared meeting-room PCs, and digital signage that nobody should have to log into are self-deploying candidates, provided the hardware actually has TPM 2.0. And any fleet where IT, a reseller, or an OEM wants to front-load app installs and policy before the box ever reaches the end user — so the person unboxing it is looking at a five-minute final step rather than a forty-minute first-run — is a White Glove candidate.

Why it happens — three separate mechanisms, and each mode trips a different one

Under the hood, each mode has a different reason it can silently fail to run:

User-driven mode supports both Microsoft Entra join and Microsoft Entra hybrid join. It's the only mode of the three that does. For hybrid join, the device needs a currently-supported Windows version, network access to a domain controller (to resolve DNS records for the domain and authenticate the user), and the Intune Connector for Active Directory installed and healthy — that connector is what actually performs the domain join on the user's behalf, so users don't need on-premises domain-join permissions themselves. If the connector is offline, or the device can't reach a domain controller and VPN with "skip domain connectivity check" hasn't been configured, the hybrid-join steps stall or fail. Microsoft's own hybrid-join guidance is explicit that Entra hybrid join is not the recommended path for new devices going forward — Entra join is.

The remote-hybrid-join scenario deserves its own callout, because it's a frequent source of "it worked in the office but not from home" tickets. Microsoft Entra hybrid join for user-driven mode normally validates connectivity by pinging a domain controller before continuing — if a remote device has no path to one, the process stops there by design. Enabling Skip domain connectivity check on the hybrid join profile removes that gate, but only if you've also deployed a working VPN profile through Intune that either lets the user connect manually from the sign-in screen or connects automatically. Skipping the connectivity check without a working VPN in place doesn't make the domain reachable — it just removes the check that would have told you it wasn't.

Self-deploying mode only supports Microsoft Entra join — Microsoft Entra hybrid join is not supported for this mode at all. It authenticates the device into your tenant using the device's TPM 2.0 hardware and TPM device attestation. No TPM 2.0, or a TPM that can't complete attestation (including a Hyper-V virtual TPM), and the process fails outright with a documented timeout error: 0x800705B4. Self-deploying also never sets a primary user automatically, which quietly breaks features that assume one exists, like self-service BitLocker recovery key retrieval from Company Portal.

Pre-provisioning (White Glove) is built on top of self-deploying's mechanics for its technician phase, so it inherits the same TPM 2.0 and attestation requirement — even though the end-user phase can complete as either Entra join or Entra hybrid join. Virtual machines are explicitly unsupported. White Glove also has two timing rules that catch people out: wait at least 90 minutes between finishing the technician flow and starting the user flow (so authentication tokens refresh properly), and don't let more than six months pass between the two, or the Intune Management Engine's certificates can expire and app detection starts failing.

All three of those failure paths converge on the same root cause the intro scenario hit: a device that already has an existing device record from a prior deployment can't automatically re-enroll through Windows Autopilot. This is explicitly documented behaviour for both self-deploying and pre-provisioning — if you re-image or redeploy a device that went through either mode before, you must manually delete its device record in the Intune admin center first (Devices > All devices, select the device, Delete). Skip that step and the second attempt at Autopilot simply doesn't engage — the device proceeds through plain OOBE because, from Intune's perspective, it's already a known device and there's nothing to re-provision.

How to verify — check profile assignment and device identity before you ship anything

Before you hand devices to a technician or an end user, confirm two separate things: that the device is actually registered with Windows Autopilot, and that a deployment profile has been assigned to it — not just that it's a member of the group you think should get one.

For a fast, scriptable check against Microsoft Graph rather than clicking through the portal one serial number at a time, use the Microsoft Graph PowerShell SDK:

That confirms registration. It does not confirm a profile is actually assigned and will download during OOBE — a device can be registered for months with no profile attached, or attached to a static group it was never manually added to. Check the device's own assignment status property returned by Graph, and cross-reference the deployment profile object itself before you trust group membership as a proxy for "this device will get the right mode."

The fix — assign deliberately, verify TPM eligibility, and clear stale records before every re-run

The fix isn't one setting — it's three separate checks that map to the three failure paths above.

Step 1 — Confirm the profile is assigned to the device, not just the group

Step 2 — Match the mode to the hardware, not the wish list

Step 3 — Delete stale device records before any re-run

Proof it worked — verify mode and status with a read-only Graph script, not a guess

Once you've confirmed assignment, hardware eligibility, and cleared any stale records, don't just trust the OOBE screen looked right. Pull the device's actual registration and deployment profile assignment state from Microsoft Graph. The companion script below, Get-AutopilotDeploymentModeStatus.ps1, checks a device by serial number, reports its assigned deployment profile (and therefore its intended mode), and flags whether the profile assignment status is actually assigned rather than pending or failed. It makes no changes to Autopilot, Intune, or Entra ID — every call it makes is a Graph read.

References

• Windows Autopilot user-driven mode — Microsoft Learn
• Windows Autopilot self-deploying mode — Microsoft Learn
• Windows Autopilot for pre-provisioned deployment (White Glove) — Microsoft Learn
• Manually register devices with Windows Autopilot — Microsoft Learn
• Windows Autopilot requirements — Microsoft Learn