Key takeaway: Windows Autopilot enables zero-touch device provisioning — new laptops ship directly to remote employees and self-configure with corporate settings, apps, and Intune enrollment without IT touching the hardware. The prerequisite is hardware hash registration in Intune, which requires either a vendor-provided hash CSV or running a PowerShell script on the device. The most common failure point in hospital environments is network connectivity: Autopilot requires HTTPS access to several Microsoft endpoints during OOBE, and corporate firewalls or proxy configurations frequently block these without explicit allow-listing.
In This Article
- How Does Windows Autopilot Work?
- What Are the Prerequisites for Windows Autopilot?
- How Do You Register Devices for Windows Autopilot?
- How Do You Configure Windows Autopilot Deployment Profiles?
- What Is the Enrollment Status Page and How Do You Configure It?
- How Do You Deploy Apps Through Autopilot and Intune?
- How Does Autopilot Work with Hybrid Entra ID Join?
- Common Failures and How to Fix Them
Windows Autopilot lets you ship a laptop directly from a supplier to a remote employee's home address and have that employee set it up themselves — fully enrolled in Intune, joined to Entra ID, corporate apps installed, security policies applied — without your IT team ever touching the device. When it works, it is the most efficient endpoint deployment model available. When it fails, it fails silently in ways that are hard to diagnose. Here is how to build it right from scratch.
How Does Windows Autopilot Work?
Windows Autopilot is not an imaging solution. It does not replace the Windows installation — the OEM Windows image stays on the device. What Autopilot does is redirect the Windows Out-of-Box Experience (OOBE). Instead of the generic setup wizard, the user sees your organization's branded sign-in page, signs in with their corporate credentials, and Autopilot uses those credentials to look up the device's hardware hash in Intune and apply the correct deployment profile. Entra ID join and Intune enrollment happen automatically during the OOBE. By the time the user reaches the desktop, the device is managed and the Enrollment Status Page (ESP) installs required apps before allowing access.
The result is a corporate-managed device configured entirely from the cloud, on hardware your IT team never physically handled. This model is especially valuable for distributed workforces, healthcare field staff, and any environment where shipping devices through a central IT office is operationally impractical.
What Are the Prerequisites for Windows Autopilot?
Before registering a single device, verify these are in place:
- Licensing: Microsoft Intune license (included in M365 Business Premium, E3, E5, or standalone Intune Plan 1/Plan 2). Autopilot itself has no separate license cost.
- Windows version: Windows 10 version 1903 or later; Windows 11 all versions. Pro, Enterprise, or Education SKUs. Home SKU does not support Intune MDM enrollment.
- Intune enrollment configured: MDM auto-enrollment must be enabled in Entra ID (Mobility → Microsoft Intune → MDM user scope). Without this, devices that join Entra ID do not enroll in Intune automatically.
- Domain name configured: Your organization's domain must be verified in Entra ID.
- Company branding: Configure your organization's branding in Entra ID (Entra portal → Company branding). This branding appears on the Autopilot OOBE sign-in page and communicates to users that this is the correct corporate login.
How Do You Register Devices for Windows Autopilot?
Autopilot identifies devices by a hardware hash — a cryptographic fingerprint derived from the device's hardware identifiers. Devices must be pre-registered in Intune with their hardware hash before the OOBE will redirect to Autopilot. There are four registration methods:
OEM registration: The cleanest option for new device purchases. Major OEMs (Dell, HP, Lenovo, Microsoft) can register devices directly to your tenant at point of manufacture if you provide your tenant ID during the procurement process. Devices arrive pre-registered and Autopilot-ready in the box. Ask your procurement contact or the OEM's business portal to confirm this option.
Reseller/CSP registration: If purchasing through a Microsoft CSP or authorized reseller, they can register devices to your tenant on your behalf using the Microsoft Partner Center.
CSV upload in Intune: For existing devices or devices not registered by OEM, boot the device to Windows, run the Get-WindowsAutoPilotInfo PowerShell script to capture the hardware hash, export a CSV, and upload it in the Intune portal under Devices → Windows → Windows Enrollment → Devices → Import.
Windows Autopilot Diagnostics Page: During OOBE, pressing Ctrl+Shift+D opens the diagnostics page and can trigger a registration check. This is a diagnostic tool, not a registration method, but useful for verifying that a device is resolving its profile correctly.
The PowerShell capture script:
Install-Script -Name Get-WindowsAutoPilotInfo
Get-WindowsAutoPilotInfo -OutputFile C:\Autopilot.csv
CSV uploads process within 15 minutes. OEM registrations propagate within 24 hours of device manufacture. After registration, assign a deployment profile to the device or device group before the user unboxes it.
How Do You Configure Windows Autopilot Deployment Profiles?
Autopilot deployment profiles define the OOBE behavior for registered devices. Create profiles in the Intune portal under Devices → Enrollment → Windows Autopilot → Deployment Profiles.
User-Driven, Entra ID Join: The standard profile for cloud-only organizations. The user signs in with their corporate credentials during OOBE, the device joins Entra ID, and Intune enrollment completes automatically. The device is a pure Entra ID device — no on-premises domain join. This is the recommended profile for new deployments.
User-Driven, Hybrid Entra ID Join: Joins both Entra ID and on-premises Active Directory during OOBE. Requires the Intune Connector for Active Directory installed on a domain-joined Windows Server in your on-premises environment. The device must be able to reach a domain controller during OOBE — on a corporate network or VPN.
Self-Deploying Mode: Designed for kiosk, digital signage, or shared-use devices. No user interaction during OOBE — the device enrolls and configures itself using a device identity (TPM attestation). Requires a TPM 2.0 chip. The device runs as a device-only identity until a user logs in.
Pre-Provisioning (White Glove): A two-phase model where a technician or OEM completes the device provisioning half (device-side ESP) before shipping to the end user. The user receives a device that is already enrolled and has device apps installed — only user-targeted apps install when the user first signs in. Substantially reduces end-user setup time and is valuable for healthcare environments where clinicians should not wait on app installations.
Key profile settings to configure: Skip privacy settings (yes, in corporate deployments), hide EULA (yes), user account type (standard user, not administrator, unless the role requires local admin), and language/region settings. The "Skip AD connectivity check" setting in Hybrid join profiles is useful when devices will be set up off-network, but be aware it defers domain join to when the device next reaches a domain controller.
What Is the Enrollment Status Page and How Do You Configure It?
The Enrollment Status Page (ESP) holds the user at a progress screen after sign-in while required policies and apps are installed. Without the ESP, users reach the desktop before Intune policies are applied — a security gap in environments that require device compliance before allowing access to corporate resources.
Configure the ESP in Intune under Devices → Enrollment → Windows Enrollment → Enrollment Status Page. Set it to block device use until all required apps are installed. Target it to All Devices or a device group containing your Autopilot devices. The ESP has two phases: device setup (completes during pre-provisioning or user-driven OOBE before sign-in) and user setup (completes after the user signs in for the first time).
The most common Autopilot support call is users stuck on the ESP for longer than expected. Usually this is caused by a required app that is large, slow to download from Intune, or has a dependency that is taking time to resolve. Keep the required app list on the ESP to the absolute minimum — security baseline policies, the VPN client, and endpoint detection agents. Install productivity apps (M365 Apps, Teams, line-of-business apps) as available apps that install post-ESP. Set a timeout on the ESP (60 minutes is typical) with a clear error message so users can contact IT rather than staring at an indefinite progress bar.
How Do You Deploy Apps Through Autopilot and Intune?
Intune deploys applications in several packaging formats. Win32 apps (packaged as .intunewin files using the Microsoft Win32 Content Prep Tool) are the most flexible format and support complex installers, custom detection rules, and dependency chains. Microsoft 365 Apps (the Office suite) have a dedicated Intune app type with a built-in configuration UI — use it rather than packaging Office as a Win32 app. Line-of-business apps (MSI-based installs) can be deployed directly without repackaging but offer less control than the Win32 format.
For Autopilot deployments, assign required apps to Entra ID device groups (containing your Autopilot devices) rather than user groups. Device-targeted apps install during the device phase of the ESP, before user sign-in, which is critical for security tools that need to be present before a user session starts. User-targeted apps install after sign-in and are appropriate for productivity and role-specific applications.
How Does Autopilot Work with Hybrid Entra ID Join?
Hybrid join Autopilot is significantly more complex than cloud-only and should only be used when on-premises domain join is genuinely required — typically for legacy applications that use Kerberos authentication against on-premises AD and cannot be modernized to use Entra ID tokens. If your applications can be migrated to Entra ID authentication, use cloud-only Autopilot and avoid the operational complexity.
Hybrid join requires the Intune Connector for Active Directory, a Windows Server application installed on a domain-joined server with line-of-sight to your AD domain controllers. The connector handles the computer object creation in AD on behalf of the OOBE. The connector server needs outbound internet access to Intune service endpoints and inbound connectivity from Intune during join operations. Network segmentation in healthcare environments frequently blocks this — verify firewall rules before deploying the connector.
Common Failures and How to Fix Them
Device not found during OOBE: The hardware hash is not registered, the device is assigned to the wrong tenant, or OEM registration has not propagated. Verify in Intune under Devices → Windows → Autopilot Devices. If missing, capture and upload the CSV manually.
ESP stuck at "Identifying": The Intune enrollment did not complete. Check MDM auto-enrollment is enabled in Entra ID. Verify the user has an Intune license. Check the Windows event log (Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider) for enrollment errors.
ESP app installation hanging: A required Win32 app has a failed dependency, a large download timed out, or the detection rule is not triggering on a successful install. Use the Intune Management Extension log (%ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log) to identify which app is failing and why.
Hybrid join failing: The connector cannot reach domain controllers, the connector service account lacks permissions to create computer objects in the target OU, or the DNS server used during OOBE cannot resolve the internal domain. Verify the Intune Connector service account has "Create computer objects" permission on the target OU, and that the OOBE network path can reach a domain controller on port 88 (Kerberos), 389 (LDAP), and 445 (SMB).
Autopilot's operating complexity lives almost entirely in the pre-deployment configuration. Once profiles, ESP, and app assignments are correctly set up and tested on a pilot device, production deployments are highly repeatable. The investment in getting the configuration right pays dividends across every device you ship afterward.