Module 6: Windows Autopilot & Deployment

← Module 5: App Management

Module 6 of 7

Module 7: Security & Monitoring →

🎯 Intune Course · Module 6 of 7

Windows Autopilot & Deployment

📂 Course: Intune & Endpoint Management
📦 Module: 6 of 7
🎯 Exam: MD-102
⏱ Read time: ~24 min
MD-102
MD-102 Exam Alignment
MD-102
  • Know that Autopilot uses the device’s hardware hash to identify and pre-configure the device — the hash uniquely identifies the device and is what links it to your Intune tenant before it ships
  • Know the three main deployment modes: User-driven (employee sets up their own device with work credentials), Self-deploying (device sets itself up with no user interaction — for shared/kiosk devices), and Pre-provisioning (IT partner or technician pre-provisions, employee completes setup later)
  • Know that the Enrollment Status Page (ESP) is a full-screen page shown during Autopilot setup that blocks the device desktop until all assigned apps and policies have been applied
  • Know that Windows Autopilot requires the device to have a Windows 10/11 internet connection and the hardware hash must be registered in Intune before the device is turned on for Autopilot setup
Exam Tip: Autopilot is not an OS imaging solution — it starts with a device running a fresh OEM Windows installation (or a factory-reset device). It does NOT deploy a custom OS image. Autopilot transforms the out-of-box Windows experience by applying your organisation’s profile during OOBE, then Intune handles the rest through MDM policies.
Windows Autopilot is Microsoft’s cloud-based zero-touch Windows provisioning technology. Instead of IT staff manually configuring each device, Autopilot allows devices to be shipped directly from the manufacturer or reseller to the end user. The user turns it on, signs in with their work account, and the device automatically configures itself with the organisation’s settings, apps, and compliance policies — all from the cloud, with no IT hands-on required.

🔑 How Autopilot Works — The Core Concept

Step What Happens
1. Hardware hash registered The device’s unique hardware hash is captured and uploaded to Intune before the device ships. The hash uniquely identifies the device (based on BIOS/UEFI, network adapters, and disk serial numbers).
2. Autopilot profile assigned An Autopilot deployment profile is assigned to the device (or device group) in Intune. This profile defines the OOBE experience — which screens to skip, device naming template, etc.
3. Device powered on During OOBE, the device connects to the internet and contacts Windows Activation servers and then the Autopilot service — which identifies the device by its hardware hash and downloads the Autopilot profile.
4. Custom OOBE runs The standard Windows OOBE is replaced by the customised experience defined in the profile. User signs in with work account.
5. Entra ID join + Intune enrol The device joins Entra ID and automatically enrolls in Intune via MDM auto-enrollment. All assigned configuration profiles, apps, and compliance policies begin deploying.
6. ESP completes If the Enrollment Status Page is configured, the device shows progress until all required apps and policies apply. Desktop is unlocked when setup completes.

📤 Hardware Hash Registration Methods

Method How Best For
OEM direct registration Hardware manufacturer (Dell, HP, Lenovo, Microsoft Surface) registers the hash directly with your Intune tenant at time of purchase. No manual steps — devices arrive Autopilot-ready. Large deployments, new device orders
CSV import Capture hash with PowerShell script, export to CSV file, import manually in Intune: Devices → Windows → Windows enrollment → Devices → Import Existing devices, small batches, lab environments
Microsoft Partner Microsoft CSP partner or reseller can register hashes on your behalf via Partner Center, linked to your tenant via your tenant ID Deployments through resellers
PowerShell — Capture Hardware Hash

# Install the Autopilot info script from PowerShell Gallery
Install-Script -Name Get-WindowsAutopilotInfo -Force

# Capture the hardware hash and save to a CSV file for upload
Get-WindowsAutopilotInfo -OutputFile 'C:\AutopilotHash.csv'

# Capture and upload directly to Intune (requires Azure AD auth)
Get-WindowsAutopilotInfo -Online -GroupTag 'Sales-Laptops'

🚀 Autopilot Deployment Modes

Mode User Present? Use Case Key Requirement
User-driven (Entra ID join) Yes — user signs in Employees setting up their own assigned laptop. Entra ID joined, MDM enrolled. Most common mode. Internet + Autopilot profile assigned. User must be in MDM scope.
User-driven (Hybrid Entra ID join) Yes Organisations still requiring domain join for legacy apps. Requires on-premises AD + Intune Connector for Active Directory. Intune Connector installed on a domain-joined server. Device must reach a domain controller.
Self-deploying No — fully automated Kiosk devices, digital signage, shared workstations. Zero user interaction — device completes setup automatically. Requires TPM 2.0 (for hardware attestation). No user credentials during OOBE.
Pre-provisioning (White Glove) Technician phase + user phase IT/partner pre-installs all apps and policies before handing to user. User only completes the account setup phase. Wired network recommended for technician phase. Autopilot profile must have pre-provisioning enabled.

📋 Autopilot Deployment Profile Settings

Setting Description
Deployment mode User-driven or Self-deploying
Join to Entra ID as Entra ID joined or Hybrid Entra ID joined
Microsoft Software License Terms Hide (skip EULA screen) or Show
Privacy settings Hide (skip Windows privacy settings screens) or Show
Device name template Apply a naming convention (e.g., CONTOSO-%RAND:5% generates random suffix like CONTOSO-AB3F2). Applied to the device during OOBE.
Allow pre-provisioned deployment Enable White Glove pre-provisioning phase for technicians
Language / Region Pre-configure or allow user to select during OOBE

⏳ Enrollment Status Page (ESP)

The Enrollment Status Page shows a full-screen progress page during Autopilot setup, preventing users from accessing the desktop until all required apps and profiles have been applied. This ensures the device is fully configured before first use.

📋 ESP Phases

  • Device preparation: Intune client installs, Autopilot profile applies, device registers
  • Device setup: Configuration profiles, security policies, certificates, and Required device apps deploy
  • Account setup: User-specific apps and policies deploy after the user signs in
  • Each phase shows individual progress bars. If an app fails, ESP blocks and shows the error — the admin can configure whether to allow users to proceed past errors or wait indefinitely.

💡 Best Practices

  • Use OEM direct registration wherever possible for large deployments — it eliminates the hash capture step entirely and devices arrive Autopilot-ready from the factory. Specify your Intune tenant ID to the reseller at purchase time.
  • Configure the Enrollment Status Page with a timeout (e.g., 60 minutes) and set “Allow users to collect logs” — this enables helpdesk to diagnose ESP failures from the error screen without needing remote access to the device
  • Test Autopilot profiles in Self-deploying mode with a VM (using Hyper-V or Azure VMs) before rolling out to physical hardware — this validates the profile, ESP, app deployment sequence, and naming template at no hardware cost

🎓 Interview Q&A

Q: A company wants to deploy 500 new laptops directly from the manufacturer to remote employees. Employees should only need to power on the laptop, sign in with their work account, and have the device fully configured automatically. What approach should be used?
Use Windows Autopilot User-driven mode with OEM direct hardware hash registration. When placing the laptop order, provide the manufacturer with the company’s Intune tenant ID. The manufacturer registers the hardware hashes directly with the Intune tenant. In Intune, create an Autopilot deployment profile configured for User-driven Entra ID join, skipping EULA and privacy screens, with a device naming template applied. Assign the profile to the Autopilot device group. Configure the Enrollment Status Page with Required apps listed. Devices ship directly to employees. When the employee powers on the laptop and connects to internet, the Autopilot service identifies the device, delivers the profile, and the employee signs in with their work credentials — Entra ID join and Intune enrolment happen automatically, apps deploy via ESP, and the device is fully configured without any IT involvement after the initial profile setup.
🎯 MD-102 Mock Test
Module 6 — Windows Autopilot & Deployment
5 questions · Pass mark: 70%

Q1 OF 5

An IT admin wants to deploy 100 new Windows 11 laptops to remote employees with zero IT hands-on. Devices should configure themselves after employees sign in with their work accounts. Which Autopilot mode and registration method combination is most appropriate?

ASelf-deploying mode with CSV import — employees don’t need to sign in
BUser-driven mode with OEM direct registration — devices ship pre-registered, employees sign in to complete setup
CPre-provisioning (White Glove) — requires IT technician involvement per device
DUser-driven mode with CSV import from a pre-boot environment on each device

✅ B. User-driven mode is correct for employee-assigned devices that require a personal user sign-in. OEM direct registration means the manufacturer registers hardware hashes at purchase time — devices arrive Autopilot-ready with no IT hash capture step. Self-deploying (A) is for shared/kiosk devices with no user sign-in, not employee-assigned laptops.

Q2 OF 5

What is the hardware hash used for in Windows Autopilot?

AIt encrypts the Windows installation during OOBE for secure deployment
BIt is a checksum of the Windows image to verify integrity during Autopilot
CIt is used to generate the device’s BitLocker encryption key
DIt uniquely identifies the physical device hardware, allowing Autopilot to recognise the device and deliver the correct profile when it connects to the internet during OOBE

✅ D. The hardware hash is a unique fingerprint of the device’s hardware components (BIOS/UEFI, network adapters, serial numbers). When the device is pre-registered in Intune with its hardware hash, the Autopilot service can identify it the moment it connects to the internet during OOBE. Without the pre-registered hash, the device goes through standard Windows OOBE instead.

Q3 OF 5

An organisation is deploying interactive kiosk devices in a retail store. These devices should configure themselves without any user signing in, running only a specific retail app. Which Autopilot mode is appropriate?

AUser-driven mode — the store manager signs in to configure each device
BPre-provisioning (White Glove) — technician provisions each kiosk in advance
CSelf-deploying mode — no user credentials required; device configures itself and can be set to Kiosk mode via configuration profile
DHybrid Entra ID join mode — kiosk devices must be domain joined for security

✅ C. Self-deploying mode is designed for devices with no assigned user — kiosks, digital signage, shared workstations. The device powers on, connects to internet, the Autopilot profile downloads, and the device configures itself using device-level credentials (TPM hardware attestation) — no user signs in during setup. Requires TPM 2.0 for the hardware attestation step.

Q4 OF 5

An employee’s Autopilot setup is stuck on the Enrollment Status Page showing “Identifying your device’s requirements.” After 30 minutes it hasn’t progressed. What is the most likely cause?

AThe device cannot reach Intune — likely a network or proxy issue blocking the required Microsoft URLs
BThe hardware hash was not captured correctly and the device is not registered in Autopilot
CThe Autopilot profile has not been assigned to the device group yet
DThe user’s Entra ID account does not have an Intune licence assigned

✅ A. “Identifying your device’s requirements” is the early ESP phase where the device is downloading the Autopilot profile. Hanging at this stage typically indicates a network connectivity issue — the device cannot reach the Microsoft Autopilot service or Intune MDM endpoints. Common causes: corporate network proxy not configured for Autopilot URLs, captive portal blocking the connection, or required endpoints blocked by firewall. If the hash wasn’t registered (B), the device would show standard Windows OOBE, not the ESP.

Q5 OF 5

What is the purpose of the Enrollment Status Page (ESP) timeout and the “Allow users to use device if setup doesn’t complete” setting?

AThe timeout controls how long Intune waits before wiping the device and starting Autopilot again
BThe timeout defines when the ESP shows an error if setup hasn’t completed; “Allow to use” lets users access the desktop despite incomplete setup — preventing devices from being permanently blocked by a failing app deployment
CThe timeout only applies to app installations — policy deployments have no timeout
DThe timeout setting is the maximum time the user has to sign in before the device resets

✅ B. The ESP timeout determines when the ESP gives up waiting for a Required app or policy to install and shows an error message. Without “Allow users to use device if setup doesn’t complete” enabled, the device is blocked on the ESP error screen indefinitely. Enabling this setting provides a “Continue anyway” option — useful in production where a single app failure shouldn’t block all new device setups. In secure environments, leave it disabled to ensure no device enters production partially configured.



🔒

Module locked — Complete Module 5 first.