Intune Windows Autopilot

Windows Autopilot is Microsoft's zero-touch provisioning service for new Windows devices. A user opens a sealed box, signs in with their work account on a wifi network, and a few minutes later the device is fully configured — joined to Entra ID, enrolled in Intune, with policies, apps, and security in place. No imaging server, no IT desk, no engineer-built golden image.

How it works

1. The device manufacturer (or your IT) registers the device's hardware hash with your tenant during procurement or initial setup.
2. The user powers on the device for the first time.
3. Windows OOBE (Out Of Box Experience) launches.
4. The device looks up its hardware hash against the Autopilot service.
5. Autopilot pulls down the deployment profile for that device (or device group).
6. The OOBE is automatically customised — corporate branding, no end-user privacy prompts, no consumer account creation.
7. The user signs in with their Entra ID account.
8. The device auto-enrols in Intune, joins Entra ID, and starts pulling configuration profiles, apps, and security baselines.
9. Enrolment Status Page (ESP) shows progress; the user waits at this screen until provisioning completes.

A typical first sign-in takes 15–45 minutes depending on profile complexity and network speed.

Autopilot deployment scenarios

• User-Driven — the most common; user signs in and the device joins their identity.
• Self-Deploying — kiosk and shared-device scenarios; no user sign-in during provisioning.
• Pre-Provisioning ("White Glove") — IT provisions the device through ESP, then ships sealed. The user just signs in.
• Existing device — re-deploy an existing device through Autopilot without re-imaging.

Hardware registration

OEMs (Dell, HP, Lenovo, Surface, others) can pre-register devices at purchase. They upload the hardware hash directly to your tenant — the user opens the box and the device is already known.

For existing devices, the Get-WindowsAutoPilotInfo PowerShell script extracts the hash from a running machine and uploads it.

What Autopilot replaces

Autopilot replaces traditional imaging (WIM, MDT, Configuration Manager OS Deployment). Instead of building a custom Windows image with apps and settings baked in, you start from the OEM-provided Windows installation and configure on top via Intune. This is cheaper to maintain, faster to update, and easier to vary by user type.

Edge cases and gotchas

• Hardware hash mismatches — common on devices flashed with a non-standard BIOS or modified firmware.
• Network requirements — Autopilot needs internet during OOBE. Captive portals and proxies require care.
• Hybrid Entra Join scenarios add complexity (an on-prem network line of sight requirement); cloud-only Entra Join is much simpler and is Microsoft's recommended path.
• ESP timing — Big profiles (many apps, many policies) can take long enough that users get frustrated. Tune the must-install list.

Autopilot is a transformative shift in device provisioning for Microsoft 365 customers. Once you've stood it up, you'll wonder how you ever shipped imaged laptops.

Worked example: a 40-person office move from imaged laptops to Autopilot

A firm replacing 40 ageing laptops asks its OEM reseller to pre-register the new devices' hardware hashes against the tenant at the point of order — a checkbox on the purchase order, no extra cost. A deployment profile is built in Intune scoped to a dynamic device group matching those hashes, set to user-driven mode with the must-install app list trimmed to the five apps genuinely needed on day one (everything else installs in the background after ESP completes, via a separate, non-blocking assignment).

The first three devices that arrive are treated as a pilot: IT unboxes one, confirms it goes through OOBE, ESP, and lands on the desktop with the expected apps in under 25 minutes, before authorising a bulk ship to end users. Two of the pilot devices work cleanly; the third stalls at ESP because a legacy VPN client in the must-install list depends on a driver Windows hasn't finished installing yet. The fix is to move that one app out of the must-install blocking list and into the background list — the device still gets it, just without holding the user at the ESP screen waiting for it.

The lesson that generalises: Autopilot failures are almost always something in the must-install list, not Autopilot itself. Keep that list to what genuinely has to be present before the user starts working, and let everything else land quietly afterward.

Decision matrix: which deployment mode

| Situation | Mode | Why | | --- | --- | --- | | A named employee receiving their own laptop | User-Driven | The device joins their identity directly; no technician step needed | | A shared kiosk, meeting-room PC, or digital signage device | Self-Deploying | No user sign-in during provisioning; needs TPM 2.0 attestation | | A regulated or high-touch rollout where IT must verify the device before the user sees it | Pre-Provisioning (White Glove) | IT completes the device-phase setup and hands over a device that's already through the slow part | | An existing fleet being reset rather than replaced | Existing device | Re-deploys through Autopilot without a full re-image, reusing hardware already on hand | | An organisation with domain-joined line-of-business apps it can't yet move off on-premises AD | Hybrid Entra Join via Autopilot | Works, but needs on-prem network line of sight and is markedly less reliable — migrate off this as soon as the blocking app moves |

When Autopilot is the wrong tool

• Devices with no reliable internet during first boot — a site with no wifi and no wired drop at the unboxing location can't complete OOBE registration; ship the device somewhere with connectivity first, or fall back to a technician-built image.
• Highly customised firmware or BIOS images from a specialist reseller — some third-party imaging pipelines invalidate the hardware hash Autopilot needs to recognise the device; confirm compatibility with the OEM before committing a whole fleet to Autopilot.
• A single-digit number of devices with no Intune investment otherwise — Autopilot's value is in repeatable, unattended provisioning at volume; a handful of one-off machines may be faster to set up by hand than to build and test a deployment profile for.

MSP checklist

• Confirm hardware-hash registration happens at the OEM or distributor level for every client that can support it — chasing hashes from already-shipped devices with Get-WindowsAutoPilotInfo is strictly more work per device.
• Keep a standard, lean must-install app list per client tier rather than reinventing ESP blocking lists per rollout — most ESP timeout complaints trace back to an oversized blocking list, not a client-specific requirement.
• Pilot every new client's first Autopilot rollout on two or three devices before authorising a bulk ship, even when the profile looks identical to a previous client's — driver and firmware variance between hardware batches is the most common source of a rollout that worked in testing and stalls in the field.
• Document which clients still depend on Hybrid Entra Join and why, and revisit that list at each quarterly review — it is the one Autopilot path Microsoft is steering everyone away from.