Skip to main content

Provisioning with Windows Autopilot

Windows Autopilot is a provisioning mechanism, not a join type. It sits on top of the join decisions made in Entra Join (The Cloud-Only Path) and Hybrid Deployment (The Transition Path), replacing the manual imaging and deployment workflows that precede enrollment. A device ships from an OEM directly to an end user, and Autopilot configures it automatically—without IT ever touching it.

What Autopilot IsWhat Autopilot Is Not
A cloud-based OOBE configuration workflowA device join type (that is Entra Join or Hybrid Join)
A replacement for imaging/re-imagingA replacement for Intune policy management
A way to assign profiles and skip OOBE stepsAvailable without Intune licensing
Autopilot works with both join types

Autopilot with Entra Join is the primary, recommended path. Autopilot with Hybrid Join is supported but requires additional on-prem infrastructure (the Intune Connector for Active Directory) and line-of-sight to a Domain Controller during provisioning.

Business Value & Capability Ranking​

The capabilities below are listed in order of operational impact. Most deployments realize the top three immediately; the remaining are additive.

1. Zero-Touch Provisioning​

The highest-value capability. A device ships from an OEM directly to an end user — IT never touches it. The user powers it on, signs in with their Entra ID credentials, and the device self-configures: it joins Entra, enrolls in Intune, applies all security baselines, installs required applications, and presents the desktop to the user. The entire workflow replaces the traditional imaging station, staging desk, and device hand-off.

Operational impact: Eliminates per-device IT labor for new hardware deployment. For organizations shipping 10+ devices per quarter, the labor savings are substantial. For geographically distributed teams, it removes the requirement for users to be on-site or for hardware to route through IT before reaching the field.

2. Automatic Corporate Device Designation​

Devices registered in Autopilot are automatically flagged as Corporate-owned in Intune at the moment the hardware hash is registered — before the device is ever turned on. This distinction matters because enrollment restrictions can (and should) block personally-owned device enrollment from MDM management entirely.

Without Autopilot registration, a device a user manually enrolls enters Intune as Personal by default. IT must then manually change the ownership designation — an operational gap that breaks enrollment restriction enforcement. With Autopilot, ownership is established at registration time and never ambiguous.

This is also the mechanism for the Ownership field visible in 10-1: Modern Endpoint Operations device status — devices that read "Corporate" without having been manually corrected are Autopilot-registered.

3. Guaranteed Security Baseline on First Boot​

The Enrollment Status Page (ESP) blocks the user from reaching the desktop until all required applications and device configuration policies have been applied. A user cannot begin working on a device that is in a partial-policy state. For compliance environments where device compliance gates resource access via Conditional Access, this prevents the edge case of a freshly enrolled device that passes compliance checks before its security policies have landed.

4. Group Tag Routing — Right Profile Without Manual Group Management​

Group Tags applied at hardware hash registration automatically route a device into the correct Entra dynamic group — which carries the correct Autopilot deployment profile, device naming convention, and initial app assignments. For organizations with multiple departments, locations, or security tiers, this eliminates manual group assignment after device registration and the human error that comes with it.

5. Autopilot Reset for Device Re-Assignment​

When a device transfers from one user to another, Autopilot Reset wipes user data and re-applies all device-phase policies without removing the device from Intune or Autopilot registration. This is substantially faster than a full wipe-and-re-enroll cycle and preserves the device's corporate designation and Autopilot record. See Device Lifecycle & Onboarding for the re-assignment procedure.

6. Self-Deploying Mode for Shared / Kiosk Devices (Commercial only)​

Devices with no dedicated user — shared workstations, kiosks, AVD session host pre-staging — can enroll and configure themselves with zero user interaction. Authentication is handled by the device's TPM presenting a device certificate to Entra. No user account is required at setup time.

7. Pre-Provisioning (White Glove) for Large App Payloads (Commercial only)​

IT or a reseller pre-stages the device phase (installs heavy applications, applies certificates) before shipping. The end user sees only the shorter user-phase of the ESP. Reduces first-boot wait time for devices with large or slow-installing application sets.

Classic Autopilot (v1) vs. Autopilot Device Preparation (v2)​

Two generations of Autopilot exist. Which generation you use is determined by your cloud environment.

Classic Autopilot (v1)Device Preparation (v2)
Commercial? All modes? User-Driven only
GCC High? Not supported? User-Driven only
Deployment ModesUser-Driven, Self-Deploying, Pre-ProvisioningUser-Driven only
Hybrid Join? User-Driven only? Not supported
Hash RegistrationCSV import or OEM directCSV import, OEM direct, or Graph API
Enrollment Status Page? Full (device + user phase)? Full (device + user phase)
GCC High: Classic Autopilot (v1) is not available

GCC High tenants must use Autopilot Device Preparation (v2). The setup workflow is different from Classic Autopilot — see the GCC High tab in the Implementation Guide below. Self-Deploying and Pre-Provisioning modes are not available in GCC High.

Deployment Modes​

User-Driven Mode​

The end user powers on the device, signs in with their Entra ID credentials, and Autopilot completes the rest—applying the Autopilot profile, enrolling in Intune, and running the Enrollment Status Page (ESP) before handing off the desktop. This is the standard mode for 1:1 knowledge worker devices.

Works with: Entra Join and Hybrid Join | Available in: Commercial (v1 and v2), GCC High (v2)

Self-Deploying Mode​

The device enrolls and configures itself with no user interaction. Authentication is handled by the device's TPM chip presenting a device certificate to Entra ID. There is no user sign-in prompt during setup. Used for shared devices, kiosks, and AVD session hosts that should be pre-configured before any user touches them.

Works with: Entra Join only | Available in: Commercial only (Classic Autopilot v1)

TPM 2.0 Required for Self-Deploying Mode

Self-Deploying mode requires TPM 2.0 with device attestation support. Virtual machines require a virtual TPM explicitly enabled. Devices without a qualifying TPM will fail at the attestation step with error 0x800705B4.

Pre-Provisioning (White Glove)​

IT or a reseller pre-stages the device phase (applies OEM apps, baseline policies) before shipping to the end user. The user then completes a shorter OOBE that only runs the user-phase of the ESP. Reduces end-user wait time for large software deployments.

Works with: Entra Join and Hybrid Join | Available in: Commercial only (Classic Autopilot v1)

Triggering Technician Flow

In Classic Autopilot v1, Pre-Provisioning is initiated at the OOBE language screen by pressing Windows key 5 times. The device enters Technician Flow, completes the device phase of the ESP (apps, certs, policies), then seals. When the end user powers it on, they only see the shorter user phase.

Autopilot with Entra Join — The Primary Path​

This is the recommended combination. No on-prem infrastructure is required beyond DNS records (Phase 1: DNS Discovery Records). The device contacts Entra ID and Intune directly over the internet during OOBE.

Flow:

Device powers on ? OOBE starts ? Device queries Windows Autopilot Deployment Service
    ? Deployment Service returns Autopilot profile
    ? OOBE skips/shows steps per profile
    ? User signs in with Entra credentials (User-Driven) or TPM attests (Self-Deploying)
    ? Device Entra Joins
    ? Intune enrollment triggers automatically
    ? ESP runs (installs required apps, applies policies)
    ? Desktop presented to user

Autopilot with Hybrid Join — Supported, Higher Overhead​

Hybrid Join via Autopilot requires the Intune Connector for Active Directory installed on an on-prem Windows Server with line-of-sight to a Domain Controller. The connector brokers the domain join on behalf of the device during OOBE.

Additional requirements vs. Entra Join:

  • Windows Server 2016+ joined to your domain, with internet access
  • Intune Connector for Active Directory installed and enrolled
  • Device must be able to reach a Domain Controller during the Autopilot OOBE (typically requires on-site provisioning or a VPN-capable pre-boot environment)
  • Only User-Driven mode is supported (no Self-Deploying for Hybrid)

When Hybrid Autopilot Makes Sense​

Hybrid Autopilot is useful in one specific scenario: issuing new hardware to users who still require on-prem AD resources. The device ships to the user, Autopilot handles the Hybrid Join (AD domain join + Entra registration) in a single OOBE workflow, and the user receives a clean, fully managed profile without requiring IT to image the machine or bring it to a staging location.

This is the right tool when:

  • The user needs Group Policy–delivered resources, legacy on-prem app authentication, or file shares that require domain membership
  • You are deploying new hardware (not re-joining an existing machine)
  • You have the Intune Connector and a DC reachable during provisioning

What Hybrid Autopilot Does Not Do​

Hybrid Autopilot is a provisioning tool for new or factory-reset devices going through OOBE — it is not a migration tool. Applying it to an existing AD-only joined machine requires wiping that machine first to re-enter OOBE. However, Entra Hybrid Join itself does not require a wipe: an existing AD-joined machine can be brought into Hybrid Join by configuring Entra Connect and the targeted deployment GPO without touching user data. See Hybrid Deployment for that procedure, or Scenario: Migrating to Entra Join if the goal is to move to cloud-only.

Autopilot Reset on a Hybrid-joined device also differs from Entra Join: the device must reach a Domain Controller during the reset to re-complete the domain join. This means reset-in-field only works if the device is on-site or connected via VPN. A Hybrid-joined device reset from a remote location without DC line-of-sight will partially complete and leave the device in an unenrolled state.

Known Issues and Failure Modes​

Hybrid Join via Autopilot introduces failure modes that don't exist in Entra Join deployments. These are often intermittent and difficult to diagnose because the domain join happens during OOBE — before the admin has a desktop, Event Viewer, or diagnostic tools available.

Failure modeWhat happensRoot causeFix
DNS resolution failureDomain join silently fails. Device completes OOBE as Entra-joined only — no AD computer object is created. No error is shown to the user.The device is on a network segment (guest Wi-Fi, wrong VLAN, hotel network) that cannot resolve the AD domain name via DNS. The Intune Connector requests a domain join, but the device can't locate a DC.Ensure the device is on a network with DNS resolution to the AD domain. For on-site provisioning, use a wired connection or a Wi-Fi network on the corporate VLAN.
Intune Connector timeoutESP hangs at "Joining your organization's network" for 30+ minutes, then fails.The Intune Connector for Active Directory has a 30-minute timeout for creating the computer object in AD. Slow WAN links, overloaded DCs, or connector service issues cause the operation to expire.Check the Intune Connector service on the on-prem server (ODJConnectorSvc). Verify the connector server has fast, reliable connectivity to a writable DC. Review the connector logs at C:\ProgramData\Microsoft\IntuneConnector\Logs.
Computer object pre-staging conflictDomain join fails with an ambiguous error during ESP.Someone pre-created the computer object in AD (common in orgs that stage objects in specific OUs for GPO targeting). The connector tries to create the object in its configured OU but the name already exists in a different OU.Either delete the pre-staged object before Autopilot runs, or configure the connector to target the same OU where the object was pre-created. Do not pre-stage objects for Autopilot Hybrid Join — let the connector create them.
VPN bootstrap chicken-and-eggRemote user cannot complete Hybrid Join because the device can't reach a DC.The user is at home or off-site. The VPN client isn't installed until ESP completes, but the domain join requires DC access before ESP finishes. There is no pre-boot VPN available.Hybrid Join Autopilot is not viable for remote provisioning without a pre-boot VPN or Always On VPN configured at the network level. Provision Hybrid Join devices on-site only, or use Entra Join for remote users and migrate to Hybrid Join later via Entra Connect.
Clock skewKerberos authentication to the DC fails during the domain join. Device may show a generic "Something went wrong" error or silently fall back to Entra Join only.New-in-box hardware that has been in a warehouse may have a significantly drifted system clock. Autopilot syncs the clock via NTP, but in some network configurations the domain join attempt occurs before the clock sync completes, and Kerberos rejects the authentication due to time skew.Ensure the provisioning network allows outbound NTP (UDP 123) to time.windows.com. If provisioning in a restricted network, configure a local NTP server and point the DHCP scope's NTP option at it. For persistent issues, manually set the clock at the OOBE command prompt (Ctrl+Shift+F10 → w32tm /resync /force) before allowing OOBE to proceed.
These failures are silent

Most Hybrid Join failures during Autopilot do not produce a clear error message. The device often completes OOBE in an Entra-joined-only state — the user can sign in and work, but Group Policy, domain-authenticated file shares, and on-prem apps that require a domain-joined machine fail silently later. Always verify the join state after provisioning:

dsregcmd /status

Check that both AzureAdJoined: YES and DomainJoined: YES appear. If only AzureAdJoined is YES, the Hybrid Join failed and the device needs to be reprovisioned on a network with DC line-of-sight.

Keep Entra Join and Hybrid Join Profiles Strictly Separate​

Do not mix Entra Join and Hybrid Join Autopilot profiles — they conflict

The Join type setting in an Autopilot Deployment Profile (Microsoft Entra joined vs. Hybrid Entra joined) fundamentally changes how the device completes OOBE. If an Entra-joined device receives a Hybrid profile, it will attempt to contact the Intune Connector for a domain join that cannot succeed — provisioning will fail or the device will end up in an ambiguous join state.

Enforce separation with dynamic device groups:

GroupMembership RuleAssigned Profile
Autopilot-EntraJoindevice.devicePhysicalIds -any (_ -eq "[OrderID]:EntraJoin")Entra Join deployment profile
Autopilot-HybridJoindevice.devicePhysicalIds -any (_ -eq "[OrderID]:HybridJoin")Hybrid Join deployment profile

Use a Group Tag (-GroupTag "EntraJoin" or -GroupTag "HybridJoin") when collecting hardware hashes to route each device into the correct group at registration time. Never assign both profiles to overlapping groups.

Profile settings that behave differently between join types:

SettingEntra Join ProfileHybrid Join Profile
Join typeMicrosoft Entra joinedHybrid Entra joined
Intune ConnectorNot usedRequired
Domain Controller reach during OOBENot requiredRequired
Self-Deploying modeSupported (Commercial)Not supported
Pre-Provisioning (White Glove)Supported (Commercial)Supported (Commercial), but DC must be reachable
GCC High (v2) supportSupportedNot supported
GCC High: Hybrid Autopilot (v1) is not available

Autopilot Device Preparation (v2) — the only Autopilot generation available in GCC High — supports Entra Join only. There is no Hybrid Join path via Autopilot in GCC High. Hybrid-join new hardware in GCC High requires manual domain join followed by Entra registration, or use of the Hybrid Deployment checklist.

Enrollment Status Page (ESP)​

The ESP blocks the user from reaching the desktop until required applications and policies have been applied. It has two phases:

PhaseWhat It CoversWhen It Runs
Device phaseDevice-targeted apps, certificates, device config profilesBefore user sign-in (Self-Deploying and Pre-Provisioning)
User phaseUser-targeted apps, user config profilesAfter user signs in

Key settings:

SettingRecommended ValueReason
Show app and profile configuration progressYesUser transparency; helps with troubleshooting
Block device use until all apps and profiles are installedYesEnsures baseline security before user access
Allow users to reset device if installation error occursNoPrevents accidental reprovisioning
Allow users to use device if installation error occurs after timeoutNoPrevents unenrolled device access
Error timeout (minutes)60Allows time for large app installs on slow connections

Implementation Guide​

OEM direct registration (both environments)

Many OEMs (Dell, HP, Lenovo, Microsoft Surface) can pre-register hardware hashes directly into your Intune tenant at order time — provide your Tenant ID to your account representative. Devices arrive already registered and require no manual hash collection. This works for both Commercial and GCC High tenants.

GCC High tenants use Windows Autopilot Device Preparation (v2), which replaces the Classic Autopilot deployment profile with a device preparation policy assigned to a user group. The policy triggers automatically when a user from the target group signs in during OOBE.

Step 1: Configure MDM User Scope​

Complete the MDM User Scope configuration in Phase 2: Entra Configuration and confirm these GCC High-specific MDM URLs are set:

  • Navigate to Entra > Settings > Mobility > Microsoft Intune
    • MDM User Scope: Autopilot Users group (or All)
    • MDM terms of use URL: https://portal.manage.microsoft.us/TermsofUse.aspx
    • MDM discovery URL: https://enrollment.manage.microsoft.us/enrollmentserver/discovery.svc
    • MDM compliance URL: https://portal.manage.microsoft.us/?portalAction=Compliance

Step 2: Allow Device Join​

  • Navigate to Entra > Devices > All Devices > Manage > Device settings
  • Users may join devices to Microsoft Entra: Set to All (default)

Step 3: Create the Device Group​

This group receives devices as they complete provisioning. Assign your Intune device policies (security baselines, compliance policies, app deployments) to this group.

  • Navigate to Entra > Groups > All Groups > New Group
    • Group name: Autopilot Deployed
    • Group type: Security
    • Membership type: Assigned
    • Owners: Add Intune Provisioning Client as an owner
Why "Intune Provisioning Client" must be an owner

The Intune Provisioning Client service principal places devices into this group during provisioning. Without it as an owner, device placement fails silently.

Step 4: Create the User Group​

Only users in this group will trigger the Device Preparation policy during OOBE.

  • Navigate to Entra > Groups > All Groups > New Group
    • Group name: Autopilot Users
    • Group type: Security
    • Membership type: Assigned
    • Add all users authorized to provision new devices as members

Step 5: Create the Device Preparation Policy​

  • Navigate to Intune > Devices > Windows > Windows enrollment > Device preparation policies > Create
SettingValue
NameAutopilot Device Preparation
Device groupAutopilot Deployed
Deployment modeUser-driven
Join typeMicrosoft Entra joined
User account typeStandard User
Allowed appsAdd any applications required before the user reaches the desktop
  • Assignments: Assign to the Autopilot Users group

Step 6 (Optional): Pre-Register Hardware Hashes via Graph API​

Pre-registration lets Intune identify the device at the first OOBE screen. Without it, the Device Preparation policy still applies — it just activates on sign-in rather than on machine startup.

Collect the hash (press CTRL+SHIFT+F10 during OOBE to open PowerShell):

Install-Script -Name Get-WindowsAutoPilotInfo -Force
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHardwareHash.csv

Upload to GCC High tenant via Microsoft Graph:

Install-Module -Name Microsoft.Graph -Force
Connect-MgGraph -Environment USGov

$csvFile = Import-Csv -Path ".\AutoPilotHardwareHash.csv"
foreach ($device in $csvFile) {
    $body = @{
        serialNumber       = $device.'Device Serial Number'
        productKey         = $null
        hardwareIdentifier = $device.'Hardware Hash'
    } | ConvertTo-Json -Depth 10

    Invoke-MgGraphRequest -Method POST `
        -Uri "https://graph.microsoft.us/beta/deviceManagement/importedWindowsAutopilotDeviceIdentities" `
        -Body $body -ContentType "application/json"
}

Provision and Verify​

To provision a device:

  1. Factory reset (or unbox new device) and power on
  2. Connect to internet — Ethernet is recommended for first run to avoid WiFi driver issues during OOBE
  3. OOBE runs. For Commercial (v1): the Autopilot profile is detected automatically and configured steps are skipped. For GCC High (v2): the Device Preparation policy triggers when the target user signs in.
  4. ESP runs (device phase, then user phase)
  5. Desktop is presented

Verification — Intune Portal:

  • Navigate to Intune > Devices > Windows > Windows enrollment > Devices
  • The device should move from "Registered" to "Enrolled" status

Verification — On Device:

dsregcmd /status
  • AzureAdJoined : YES (Entra Join) or DomainJoined : YES + AzureAdJoined : YES (Hybrid)
  • MDMEnrolled : YES

Common Provisioning Errors (Commercial v1):

Error CodeMeaningFix
0x800705B4TPM attestation timeout (Self-Deploying)Verify TPM 2.0 is enabled and meets attestation requirements
0x801c0003Device not registered in AutopilotRegister the hardware hash and wait 15 min for sync
0x80180018MDM terms of use endpoint unreachableCheck DNS records and firewall rules for Intune endpoints
0x80070032ESP app installation timeoutIncrease ESP timeout or investigate failing app deployment
Bypassing region, keyboard, and WiFi prompts in OOBE

Drop this JSON file before OOBE begins to pre-configure locale settings — this works in both environments:

Path: C:\Windows\Provisioning\Autopilot\AutopilotConfiguration.json

{
  "CloudAssignedLanguage": "en-US",
  "CloudAssignedRegion": "US",
  "CloudAssignedKeyboard": "us",
  "CloudAssignedOobeConfig": 177
}

Pre-configure WiFi for OOBE connectivity by exporting from a working machine and importing on the target:

netsh wlan export profile name="Corp-WiFi" key=clear folder="D:\Autopilot"
netsh wlan add profile filename="D:\Autopilot\Wi-Fi-Corp-WiFi.xml"

This is a one-time technician step to give the device network access during Autopilot OOBE — before Intune enrollment completes and the managed Wi-Fi profile is delivered. For ongoing Wi-Fi management after enrollment, deploy Intune Wi-Fi configuration profiles as documented in Mobile & Endpoint Security: Wi-Fi Configuration.

How to apply it:

  • Commercial (v1, White Glove): Press Windows key 5 times at the OOBE language screen to enter Technician Flow, drop the JSON and WiFi files, then reseal.
  • Any environment (v2 / no White Glove): Press CTRL+SHIFT+F10 at any OOBE screen to open a command prompt. Drop the files, then reboot to resume OOBE with prompts bypassed.

Group Tags and Device Naming​

Group Tags allow a hardware hash import to automatically route devices into the correct Entra group—and therefore the correct deployment profile and naming convention—without any manual group assignment after registration.

How Group Tags Work​

  1. Specify a Group Tag when collecting the hardware hash:

    Get-WindowsAutoPilotInfo -OutputFile AutopilotHWID.csv -GroupTag "Engineering"

  2. Create a Dynamic Device Group in Entra with the membership rule:

    device.devicePhysicalIds -any (_ -eq "[OrderID]:Engineering")

  3. Assign the Autopilot Deployment Profile (and ESP) to this dynamic group.

  4. Devices tagged Engineering are automatically placed in the group after hash import and receive the Engineering profile at OOBE — no manual group membership management required.

Device Naming Templates​

Configure a naming template in the Autopilot Deployment Profile (Apply device name template: Yes):

PatternExample ResultUse Case
DEPT-%SERIAL%ENG-5CG1234ABCDepartment-coded, traceable names
CRP-%RAND:5%CRP-A3F72Generic corporate naming
LOC-BLDG-%RAND:4%LOC-BLDG-3B9CLocation-coded names
  • The full device name (prefix + serial/random) must be = 15 characters
  • %SERIAL% uses the hardware serial number (unique and traceable)
  • %RAND:N% generates N random alphanumeric characters

Retiring an Autopilot Device​

For the full decommission procedure — including Intune retire, factory reset, Autopilot record deletion, and Entra cleanup — see Device Lifecycle & Onboarding: Device Retirement. Autopilot-registered devices require the additional step of deleting the Autopilot device record before deleting from Entra; that procedure is documented there.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.