Intune Autopilot deployment — the AU mid-market step-by-step (2026)

Windows Autopilot is the Microsoft answer to the build-room problem. New starter ordered a laptop on a Tuesday; the laptop ships from the vendor to their home on a Wednesday; the staff member unboxes on a Thursday; first login provisions the device into your Entra tenant, applies Intune compliance policies, deploys the right apps, joins the right groups — without IT touching it. For Australian mid-market organisations distributed across cities and time zones, Autopilot is the deployment model. Done badly, it's a re-imaging tax. Done well, it's the cleanest provisioning experience in the industry.

What you need before you start

• Microsoft Intune licences for every user receiving an Autopilot device — included in Microsoft 365 Business Premium, E3, E5 and EMS.
• Microsoft Entra Joined (or Hybrid Joined) target state agreed — the default modern pattern is Entra Joined (Cloud Native).
• A hardware vendor that supports the Autopilot hardware hash upload — every major AU vendor does (Dell, HP, Lenovo, Microsoft Surface). Confirm at quote time; this matters.
• Conditional Access policies that don't lock out the device during enrolment — particularly the require-compliant-device policy must exempt the enrolment flow.
• A standardised baseline image — typically OEM Windows 11 Pro or Enterprise (OEM is fine, you upgrade at Autopilot deployment via licence).

The four Autopilot profile types

Intune offers four Autopilot deployment profile types. The choice depends on the device's owner and use case.

1. 1User-driven mode (Entra join) — the new starter signs in with their work account during OOBE; their tenant provisions and joins the device. The default for AU mid-market knowledge workers. 90% of deployments.
2. 2User-driven mode (Hybrid Entra join) — for orgs with line-of-business apps that require domain join. Adds complexity (VPN or Entra Cloud Sync). Use only if needed.
3. 3Self-deploying mode — the device provisions itself with no user input; assigned to a specific user or group later. Used for kiosks, conference room devices, dedicated single-purpose machines.
4. 4Pre-provisioned mode — formerly White Glove. IT runs the device-related provisioning offline (drivers, policies, baseline apps), seals it, ships it; the new starter completes user-related provisioning on first sign-in. Used when day-one application install is too slow over residential broadband.

The step-by-step

1. 1Hardware hash upload — your hardware vendor uploads the Autopilot hash for every device they ship you, directly to your Intune tenant via the Microsoft Partner Center. Make this part of the procurement contract.
2. 2Autopilot group — create a dynamic Entra group keyed on device-related attributes (typically the GroupTag set by the vendor at hash upload). Devices land in this group automatically once the hash is uploaded.
3. 3Autopilot deployment profile — create the profile (user-driven, Entra join, default behaviour overrides), assign it to the Autopilot group.
4. 4Enrolment Status Page (ESP) — configure ESP for the right experience: block device use until apps are installed, show progress, set timeouts. ESP is the most-overlooked configuration; default settings produce poor first-impression experiences.
5. 5Compliance policies — what makes a device compliant (BitLocker on, Defender for Endpoint on, OS version current, hardware Trusted Platform Module present). These apply at first sign-in.
6. 6Configuration profiles — security baselines, BitLocker, OneDrive Known Folder Move, Edge config. Push to the Autopilot group so they apply during provisioning.
7. 7Application assignments — required Win32 apps (often via Intune Win32 Wrapper) and Microsoft Store apps assigned to the Autopilot group with 'Required' install behaviour, set to install during ESP.
8. 8Test with one device end-to-end — never roll out without a full physical test on the actual vendor model. Vendor BIOS/firmware quirks are real and varied.

Common failure modes in AU deployments

• Hash upload race condition — device ships before the vendor uploads the hash; user gets a blank Autopilot screen. Solution: contractual SLA with the vendor on hash upload timing.
• Conditional Access blocking enrolment — the require-compliant-device CA policy refuses sign-in before the device has been enrolled. Solution: exclude device enrolment from the policy, or use a dedicated Intune Enrolment Manager pattern.
• ESP timeout — apps take longer than ESP timeout to install over residential broadband; user gets an error and is dumped into an unprovisioned desktop. Solution: increase ESP timeout to 60+ minutes, or move to pre-provisioned mode.
• Win32 app dependencies — App B requires App A but Intune installs them in alphabetical order. Solution: explicit dependency declarations in the Win32 app or the new Intune Enterprise App Catalog handles ordering.
• OOBE country selection drift — the user picks the wrong country and English-US installs instead of English-AU; date formats, default keyboard wrong. Solution: lock OOBE country selection via the Autopilot profile.

What good looks like at maturity

A mature Australian Autopilot operation has three traits: every new device hits the user's hands with full provisioning inside an hour of first power-on, the helpdesk gets zero re-image tickets per quarter, and the joiner workflow (new starter HR notification → laptop ordered → laptop shipped → device autopilots → user signs in) takes 5 working days end-to-end. Frontrow's Autopilot engagements aim for this within 12 weeks of project start.