This chapter covers Windows Autopilot deployment, a critical technology for modern device lifecycle management in Microsoft 365. Autopilot enables zero-touch, cloud-based provisioning of new Windows devices, reducing IT effort and enabling a seamless end-user experience. On the MS-102 exam, questions on Autopilot appear in the Tenant Management domain (Objective 1.5) and typically account for 5-8% of total questions. You will need to understand its components, deployment modes, configuration steps, and how it integrates with Intune and Azure AD.
Jump to a section
Windows Autopilot is like a luxury hotel that allows guests to pre-register before they arrive. When a guest books a room, the hotel's system receives their details: name, preferences, and payment info. The hotel then assigns a room and prepares a key card, but the guest doesn't get the physical key until they check in. Upon arrival, the guest goes to a self-service kiosk, enters their booking reference, and the kiosk immediately prints the key card. The room is already set to their preferences—temperature, pillows, minibar items. The guest never needs to queue at the front desk or fill out forms. In this analogy, the hotel's central reservation system is Microsoft Intune, the booking reference is the device's hardware hash (or other identifier), the kiosk is the Windows Out-of-Box Experience (OOBE), and the key card is the fully configured device profile. The hotel chain's standards (like brand-specific amenities) are equivalent to the organization's compliance policies and application assignments. Just as a hotel can revoke a booking if the guest doesn't show, Autopilot can reset the device if it doesn't connect within a certain timeframe. The key insight: the device is 'known' to the cloud before it ever powers on, enabling zero-touch deployment. The hotel analogy breaks down if you imagine the guest building their own room—Autopilot does not involve imaging or custom OS builds; it uses the OEM-installed Windows edition and customizes it post-boot.
What is Windows Autopilot?
Windows Autopilot is a collection of technologies designed to simplify and automate the deployment of new Windows 10/11 devices. Instead of IT staff manually imaging or configuring each device, Autopilot leverages the cloud to deliver a customized out-of-box experience (OOBE). The device ships with a generic Windows installation from the OEM, and upon first boot, it contacts Microsoft Intune to download organization-specific settings, policies, and applications. The result is a device that is automatically joined to Azure AD, enrolled in Intune, and configured for the user—with zero physical interaction from IT.
How Autopilot Works Internally
Autopilot is not a single feature but a pipeline of services:
1. Device Registration: Before a device can use Autopilot, it must be registered in the Autopilot service. Registration can happen in three ways:
- OEM registration: The OEM uploads the device's hardware hash (a unique hash of the device's hardware components) to Microsoft Partner Center, which then syncs to the customer's tenant.
- Reseller registration: Similar, but via a Microsoft Cloud Solution Provider (CSP) partner.
- Manual registration: IT admin manually collects the hardware hash using a PowerShell script (Get-WindowsAutopilotInfo.ps1) and uploads it via Intune.
- Automatic registration: Devices already enrolled in Intune can be converted to Autopilot devices (though this is rare).
The hardware hash is a base64-encoded string derived from the device's TPM, hard drive, and network adapter identifiers. It uniquely identifies the device to the Autopilot service.
Profile Assignment: Once registered, the device is assigned an Autopilot deployment profile. Profiles are created in Intune and define the deployment mode (user-driven or self-deploying), Azure AD join type (Azure AD joined or Hybrid Azure AD joined), language and locale settings, privacy settings, and more. The profile is stored in Intune and associated with the device via its hardware hash.
First Boot: When the device powers on for the first time, the Windows OOBE checks for network connectivity. If connected, it contacts the Autopilot service (via https://login.microsoftonline.com and https://autopilot.microsoft.com). The service identifies the device using its hardware hash and returns the appropriate deployment profile.
4. OOBE Customization: The OOBE is customized based on the profile. For example: - User-driven mode: The user is prompted to sign in with their Azure AD credentials. The device then joins Azure AD and is enrolled in Intune. - Self-deploying mode: No user interaction required. The device automatically joins Azure AD and enrolls in Intune, typically used for kiosks or shared devices. - White Glove mode: A technician performs initial setup, then reseals the device for the end user.
Azure AD Join and Intune Enrollment: During the OOBE, the device authenticates to Azure AD and creates a computer object. It then enrolls in Intune, which applies device configuration policies, compliance policies, and installs required applications.
Post-Provisioning: After the user signs in, Intune continues to apply policies and install apps in the background. The user can start working immediately while remaining configurations are applied.
Key Components, Values, and Defaults
Hardware Hash: A SHA-256 hash of the device's TPM EKpub, disk serial number, and MAC address. Approximately 4,000 characters when base64-encoded.
Autopilot Profile: Contains settings like:
Deployment mode: User-Driven, Self-Deploying, or White Glove.
Join type: Azure AD joined (default) or Hybrid Azure AD joined.
Language: Default is OS language; can be overridden.
Privacy settings: Allows disabling Cortana, location services, etc.
Skip EULA: Can be set to automatically accept the EULA (requires organization to accept legal responsibility).
Default Timers:
OOBE timeout: 15 minutes if no user interaction.
ESP (Enrollment Status Page) timeout: 60 minutes by default for device setup; 60 minutes for user setup.
Device preparation timeout: 30 minutes.
Azure AD Join: Requires Azure AD Premium P1 or P2 for Autopilot features.
Intune Licensing: Each user must have an Intune license (e.g., Microsoft 365 E3 or E5).
Configuration and Verification Commands
To collect a hardware hash manually:
# Install the Autopilot module (requires Windows 10/11)
Install-Module -Name WindowsAutopilot
# Get the hardware hash and export to CSV
Get-WindowsAutopilotInfo -OutputFile C:\Devices.csvTo upload the CSV to Intune:
Navigate to Devices > Windows > Windows enrollment > Devices.
Click Import and select the CSV file.
To verify an Autopilot deployment:
In Intune, go to Devices > Windows > Windows enrollment > Device preparation profiles (or Deployment profiles).
Check the profile assignment status.
On the device, run dsregcmd /status to verify Azure AD join status.
Check Intune enrollment status via https://portal.azure.com/#blade/Microsoft_Intune_DeviceSettings/DevicesMenu/overview.
Interaction with Related Technologies
Intune: The primary management endpoint. Autopilot profiles are stored and assigned via Intune. Intune also handles device configuration, compliance, and app deployment after enrollment.
Azure AD: Provides identity and device join functionality. Autopilot requires Azure AD for device authentication and registration.
Microsoft Store for Business (deprecated): Was used for app deployment; now replaced by Intune app deployment.
Windows Update for Business: Can be used to keep devices updated post-deployment.
Conditional Access: Can be configured to require compliant devices (enrolled via Autopilot) before accessing resources.
Important Considerations
Network Requirements: Devices must have internet access to reach Azure AD and Intune endpoints. Proxy servers must allow traffic to login.microsoftonline.com, autopilot.microsoft.com, manage.microsoft.com, and other Intune endpoints.
Windows Edition: Autopilot supports Windows 10/11 Pro, Enterprise, and Education. Windows Home is not supported.
TPM Requirement: Self-deploying mode and White Glove mode require a TPM 2.0 chip. User-driven mode does not require TPM.
Hybrid Azure AD Join: Requires a line-of-sight to an on-premises domain controller during Autopilot. This can be achieved via VPN or DirectAccess.
Common Pitfalls
Device not registered: The most common issue. Ensure the hardware hash is correctly uploaded and synced.
Profile not assigned: Check that the profile is assigned to the correct device group.
Network connectivity: The device must reach Microsoft cloud services. Corporate firewalls often block required endpoints.
TPM not present: Self-deploying and White Glove modes fail on devices without TPM 2.0.
Time skew: The device's time must be accurate for Azure AD authentication.
Summary
Windows Autopilot transforms device deployment from a manual, image-based process to a cloud-driven, zero-touch experience. It relies on hardware identification, cloud services, and Intune policies to deliver a customized OOBE. Understanding the registration process, profile assignment, and deployment modes is essential for the MS-102 exam.
Register Device in Autopilot
The device's hardware hash must be uploaded to the Autopilot service. This can be done by the OEM or reseller during purchase, or manually by IT. To manually register, run the PowerShell script `Get-WindowsAutopilotInfo.ps1` on the device to export its hardware hash to a CSV file. Then, in the Intune portal, navigate to Devices > Windows > Windows enrollment > Devices and click Import to upload the CSV. The device will appear in the list with a status of 'Not assigned' until a profile is applied. The hardware hash is a unique identifier, so duplicate registrations are prevented. If a device is already registered, re-importing will update its record.
Create Autopilot Deployment Profile
In Intune, go to Devices > Windows > Windows enrollment > Deployment profiles and click Create profile. Provide a name and description. Choose the deployment mode: User-Driven (user signs in), Self-Deploying (no user interaction), or White Glove (technician pre-provisions). Select the join type: Azure AD joined (default) or Hybrid Azure AD joined. Configure OOBE settings such as language, privacy settings (e.g., disable Cortana), and whether to skip the EULA. For self-deploying, you must specify a device name template (e.g., `Kiosk-%RAND:5%`). The profile is saved and ready to be assigned to device groups.
Assign Profile to Device Group
After creating the profile, assign it to an Azure AD device group. In the profile's Assignments tab, select 'Include groups' and choose the group containing the registered devices. You can also exclude groups. The assignment triggers the Autopilot service to associate the profile with the devices in that group. The profile is applied to all devices in the group, so ensure the group is scoped correctly. It may take a few minutes for the assignment to propagate. You can verify by checking the device's Autopilot status in Intune.
Ship Device to End User
The device is now ready for deployment. Ship it directly to the end user with minimal packaging—no IT staging needed. The device should have internet access on first boot. The user unboxes it, plugs it in, and turns it on. The Windows OOBE appears. If the device is in user-driven mode, the user will be prompted to select their language and then sign in with their Azure AD credentials. For self-deploying, the device automatically proceeds without user input, but the user may see a status screen.
Device Boots and Connects to Autopilot
On first boot, the Windows OOBE checks for network connectivity. Once connected, it contacts the Autopilot service using the hardware hash. The service identifies the device and returns the assigned deployment profile. The OOBE is then customized according to the profile: for user-driven, it shows the organization's branding and sign-in page; for self-deploying, it shows a progress screen. The device authenticates to Azure AD, creates a computer object, and enrolls in Intune. Intune applies device configuration policies and installs required applications. The user sees the Enrollment Status Page (ESP) showing progress. Once complete, the user reaches the desktop and can start working.
Enterprise Scenario 1: Global Rollout of Standardized Laptops
A multinational corporation with 10,000 employees needs to deploy new Windows laptops to remote workers. Previously, IT staged each device in a central location, imaging and configuring them before shipping. This process took weeks and required significant logistics. With Autopilot, the company negotiates with its OEM to automatically register all devices in its tenant. IT creates a single Autopilot profile for 'Corporate Laptops' assigned to an Azure AD group containing all devices. The profile is user-driven with Azure AD join. Devices are shipped directly from the OEM to employees. On first boot, employees sign in with their corporate credentials, and the device is automatically joined to Azure AD, enrolled in Intune, and configured with company policies and Microsoft 365 Apps. The deployment time drops from weeks to days. Common issues include network proxies blocking Autopilot endpoints; the company configures proxy auto-discovery (WPAD) to ensure devices can reach the cloud. Another challenge is time zones: if the device's BIOS time is incorrect, Azure AD authentication fails. The IT team includes a script in the OOBE to sync time via NTP.
Enterprise Scenario 2: Self-Service Kiosks in Retail
A retail chain deploys 500 self-service kiosks in stores. These kiosks run Windows 10 in kiosk mode and must be provisioned without user interaction. The company uses Autopilot self-deploying mode. Each kiosk is registered via OEM and assigned a profile that specifies a device name template like 'Kiosk-StoreID-001'. The profile also configures the device to automatically sign in with a local account and launch the kiosk app. Since self-deploying requires TPM 2.0, the company ensures all kiosk hardware includes a TPM. On first boot, the kiosk connects to the internet, joins Azure AD, enrolls in Intune, and applies the kiosk configuration. The store manager simply plugs in the kiosk and turns it on. Misconfiguration example: If the profile does not include a device name template, the kiosk will use a random name, causing confusion in inventory. Also, if the kiosk loses internet during provisioning, it may fall back to a generic OOBE, requiring manual intervention.
Enterprise Scenario 3: Hybrid Azure AD Join for On-Premises Resources
A large enterprise with on-premises Active Directory wants to use Autopilot but still needs devices to access legacy apps that require domain membership. They configure Autopilot for Hybrid Azure AD join. The Autopilot profile specifies 'Hybrid Azure AD joined' and requires the device to have line-of-sight to a domain controller during OOBE. The company sets up a VPN connection that automatically connects during OOBE (using a profile pushed via Intune). Alternatively, they use DirectAccess or a site-to-site VPN. The device joins the on-premises domain via the VPN, then syncs to Azure AD via Azure AD Connect. The user experience is similar to pure Azure AD join, but the device appears in both on-prem AD and Azure AD. Common pitfalls: The device must be able to resolve the domain controller's DNS name; IT must ensure the VPN profile is available before Autopilot runs. Also, the time to complete hybrid join can be longer due to domain controller sync delays.
MS-102 Exam Focus: Windows Autopilot
Objective 1.5: Implement device management using Autopilot and Intune. The exam tests your ability to configure Autopilot profiles, register devices, and troubleshoot deployment issues. Key areas: - Deployment modes: User-driven, self-deploying, White Glove. Know the requirements for each (TPM for self-deploying and White Glove; no TPM needed for user-driven). - Registration methods: OEM, CSP, manual (PowerShell), and automatic (Intune). - Profile settings: Join type (Azure AD vs Hybrid), language, privacy settings, skip EULA. - Troubleshooting: Common errors like 'No Autopilot profile assigned', 'TPM not found', 'Network connectivity issues'.
Common Wrong Answers and Why 1. 'Autopilot requires a custom Windows image': Wrong. Autopilot uses the OEM-installed Windows edition. No imaging is needed. Candidates confuse Autopilot with traditional imaging (MDT/SCCM). 2. 'Self-deploying mode requires user credentials': Wrong. Self-deploying is fully automated; no user interaction. The device uses a TPM to authenticate. Candidates think all modes require sign-in. 3. 'Autopilot can deploy Windows 10 Home': Wrong. Only Pro, Enterprise, and Education are supported. Home lacks the required APIs. 4. 'Hybrid Azure AD join does not require domain controller connectivity': Wrong. It requires line-of-sight to an on-premises DC during OOBE. Candidates assume it's purely cloud-based.
Specific Numbers and Terms - Hardware hash: ~4,000 characters base64. - ESP timeout: 60 minutes (device setup), 60 minutes (user setup). - OOBE timeout: 15 minutes. - TPM 2.0 required for self-deploying and White Glove. - Autopilot profiles are stored in Intune. - Devices must be registered before profile assignment.
Edge Cases
- White Glove mode: A technician runs through OOBE up to the ESP, then reseals the device. The end user only sees a 'Welcome' screen. Exam may ask about the 'reseal' step.
- Device rename: In self-deploying, you can specify a naming template (e.g., %RAND:5%). The exam may test that the template must include %RAND% or %SERIAL%.
- Multiple profiles: A device can only have one profile. If assigned to multiple groups with different profiles, the assignment is indeterminate. The exam likes to test this conflict.
How to Eliminate Wrong Answers - If the question mentions 'no user interaction', the answer must be self-deploying mode. - If the question mentions 'on-premises domain', the answer must be Hybrid Azure AD join. - If the question mentions 'technician pre-provisions', the answer is White Glove. - If the question asks about the first step, it's always 'Register the device'. - For troubleshooting, check network connectivity first, then TPM availability, then profile assignment.
Windows Autopilot enables zero-touch, cloud-driven deployment of Windows devices without custom imaging.
Devices must be registered in Autopilot via hardware hash before a profile can be assigned.
Three deployment modes: User-Driven, Self-Deploying, and White Glove; each has distinct requirements and use cases.
Self-Deploying and White Glove modes require a TPM 2.0 chip; User-Driven does not.
Autopilot profiles are assigned to Azure AD device groups, not individual devices.
Hybrid Azure AD join requires line-of-sight to an on-premises domain controller during OOBE.
Common troubleshooting steps: verify network connectivity, TPM presence, profile assignment, and hardware hash registration.
The Enrollment Status Page (ESP) has a default timeout of 60 minutes for both device and user setup.
These come up on the exam all the time. Here's how to tell them apart.
User-Driven Mode
Requires user to sign in with Azure AD credentials during OOBE.
Does not require TPM 2.0; can run on any supported Windows edition.
Device joins Azure AD as 'Azure AD joined'.
User is associated with the device as primary user.
Suitable for personal devices assigned to individual users.
Self-Deploying Mode
No user interaction needed; device provisions automatically.
Requires TPM 2.0 for device authentication.
Device joins Azure AD as 'Azure AD joined' (no user context).
No primary user is assigned; device is shared or kiosk.
Suitable for shared devices, kiosks, or IoT scenarios.
Mistake
Autopilot requires a custom Windows image to deploy.
Correct
Autopilot uses the factory-installed Windows edition. It does not require imaging. Customization occurs via cloud policies and apps after the device boots.
Mistake
All Autopilot deployment modes require a TPM 2.0 chip.
Correct
Only self-deploying and White Glove modes require TPM 2.0. User-driven mode does not require TPM because the user authenticates interactively.
Mistake
Autopilot can be used to deploy Windows 10 Home edition.
Correct
Autopilot only supports Windows 10/11 Pro, Enterprise, and Education. Home edition lacks the necessary MDM enrollment and Azure AD join capabilities.
Mistake
Hybrid Azure AD join via Autopilot does not require connectivity to an on-premises domain controller.
Correct
Hybrid Azure AD join requires the device to have line-of-sight to a domain controller during the OOBE to complete the domain join. This is often achieved via VPN or DirectAccess.
Mistake
Autopilot profiles are assigned to individual devices directly.
Correct
Profiles are assigned to Azure AD device groups, not individual devices. All devices in the group receive the same profile. A device can only have one profile.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
User-Driven mode requires the end user to sign in with their Azure AD credentials during the out-of-box experience (OOBE). The device is then joined to Azure AD and enrolled in Intune with the user as the primary user. This mode does not require a TPM. Self-Deploying mode requires no user interaction; the device automatically joins Azure AD and enrolls in Intune using a TPM 2.0 for authentication. It is ideal for shared devices or kiosks. On the exam, remember that Self-Deploying mode is for scenarios where no user sign-in is desired, and it mandates TPM 2.0.
To manually register a device, you first collect its hardware hash using the PowerShell script `Get-WindowsAutopilotInfo.ps1` (available from the PowerShell Gallery or Microsoft). Run the script on the device to generate a CSV file containing the hardware hash. Then, in the Microsoft Intune admin center, go to Devices > Windows > Windows enrollment > Devices and click Import. Upload the CSV file. The device will appear in the list and can be assigned an Autopilot profile. Alternatively, you can use a CSV with the device serial number, Windows product ID, and hardware hash. The hardware hash is a unique identifier derived from the device's TPM, disk, and network adapter.
Yes, Autopilot supports Hybrid Azure AD join, which allows devices to join both on-premises Active Directory and Azure AD. To use Hybrid Azure AD join, you must configure the Autopilot profile with the join type set to 'Hybrid Azure AD joined'. Additionally, the device must have network connectivity to an on-premises domain controller during the OOBE. This can be achieved via a VPN connection that is established automatically (e.g., using a VPN profile pushed via Intune) or through DirectAccess. The device will first join the on-premises domain, then sync to Azure AD via Azure AD Connect. Without domain controller connectivity, the hybrid join will fail.
Devices must have internet access to reach Microsoft cloud services. The key endpoints are: `login.microsoftonline.com` (Azure AD authentication), `autopilot.microsoft.com` (Autopilot service), `manage.microsoft.com` (Intune enrollment), and `ctldl.windowsupdate.com` (for certificate revocation lists). Additionally, for Intune management, endpoints like `*.manage.microsoft.com` and `*.notify.windows.com` may be needed. If the device is behind a proxy, the proxy must support HTTPS inspection or allow these URLs. For Hybrid Azure AD join, the device must also be able to reach an on-premises domain controller (typically via VPN or DirectAccess).
White Glove mode is a deployment scenario where an IT technician performs the initial setup of the device up to the Enrollment Status Page (ESP), then reseals the device for the end user. The technician boots the device, connects to the network, and the Autopilot process runs. Once the ESP shows that provisioning is complete (or at a certain point), the technician presses Ctrl+Shift+D to reseal the device. The device is then shipped to the end user, who only sees a simplified 'Welcome' screen and does not need to go through the full OOBE. White Glove mode requires TPM 2.0 and is useful for pre-provisioning devices in bulk. On the exam, remember that the technician reseals the device using Ctrl+Shift+D.
First, verify the device is registered in Autopilot by checking the Intune portal under Devices > Windows > Windows enrollment > Devices. If the device is not listed, re-import its hardware hash. If it is listed, check that it has an assigned profile. The profile assignment is based on Azure AD group membership; ensure the device is a member of the group targeted by the profile. Also, confirm the profile is active and not expired. On the device, check network connectivity to Autopilot endpoints. You can also run `Get-AutopilotInfo` (if available) or check the Windows event logs under `Applications and Services Logs/Microsoft/Windows/DeviceDirectoryClient` for errors. Common causes: incorrect time, proxy blocking, or TPM issues (for self-deploying).
No, Windows Autopilot is only supported on Windows 10/11 Pro, Enterprise, and Education editions. Windows 10 Home does not include the necessary MDM enrollment capabilities or Azure AD join functionality. If you attempt to use Autopilot on a Home edition device, the OOBE will not contact the Autopilot service and will proceed with the standard consumer experience. For the exam, remember that Autopilot requires a business-capable edition of Windows.
You've just covered Windows Autopilot Deployment — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?