Quick Takeaways
- Windows Autopilot handles the initial setup of a new device. Microsoft Intune takes over afterward for ongoing app and policy management. They’re separate services designed to work together, not two names for the same thing.
- There are three deployment modes: user-driven (a real person signs in), self-deploying (no user interaction, built for kiosks and shared devices), and pre-provisioning, also called White Glove (a technician does the heavy lifting first).
- Setup requires a Microsoft Entra ID P1 license, a supported Windows version, and each device’s unique hardware hash uploaded to the Autopilot service.
- Up to 500 devices can be registered per CSV upload, and self-deploying mode specifically requires a physical TPM 2.0 chip – a Hyper-V virtual machine won’t work as a stand-in.
- Most deployment failures trace back to a missing license, an unassigned profile, or a TPM/network issue during OOBE, not an actual bug in Autopilot itself.
What is Windows Autopilot (and how does it relate to Intune)?
Windows Autopilot and Microsoft Intune are two different tools that solve two different problems, and mixing them up is where most of the confusion starts.
Autopilot handles a device’s first few minutes out of the box: joining it to your organization’s identity system and enrolling it into management, all without an IT technician physically touching the machine. Intune takes over from there – pushing configuration profiles, installing apps, enforcing compliance policies, and managing the device for as long as it’s in use.
Put simply: Autopilot deploys the device once, and Intune manages it forever after. An employee unboxes a new laptop, connects to Wi-Fi, signs in with their work account, and by the time they reach the desktop, the machine is already joined, enrolled, and configured – with no IT tickets and no imaging required.
The three Autopilot deployment modes
Which mode you pick depends on who’s using the device and how much hands-on setup you want a human involved in. Microsoft’s own scenario comparison covers this breakdown in more depth if you want the full decision matrix.
| Mode | Who signs in | Best for | Needs TPM attestation? |
| User-driven | The assigned end user, with their own credentials | Standard employee laptops | No |
| Self-deploying | Nobody – device joins before anyone logs in | Kiosks, shared devices, digital signage | Yes |
| Pre-provisioning (White Glove) | A technician first, then the end user for a short final step | Devices needing heavier pre-configuration before handoff | Yes, for the technician phase |
User-driven mode
This is the default most organizations reach for. A real person goes through the standard out-of-box experience, signs in with their own account, and the device gets joined to Microsoft Entra ID (or hybrid-joined to an on-prem AD, if that’s your setup) and enrolled in Intune automatically.
Self-deploying mode
Designed for devices nobody personally owns: shared kiosks, meeting-room displays, lab machines. There’s little to no user interaction, and the device authenticates itself using its TPM chip instead of a person’s credentials. This is also the mode most likely to trip people up in testing, because a physical TPM 2.0 is required. A Hyper-V VM with a virtual TPM isn’t an equivalent stand-in, so lab testing needs real hardware or a different mode entirely.
Pre-provisioning (White Glove)
A middle ground. A technician (yours, a reseller’s, or the OEM’s) runs the time-consuming parts of provisioning ahead of time, then reseals the device. When it reaches the end user, only a short final phase remains – sign in, and the device finishes up in the background.
What you need before you start
Before touching Intune, confirm the basics are in place:
- Licensing: Users enrolling devices need a Microsoft Entra ID P1 license assigned. This is separate from your Intune license.
- Supported OS: Windows 11 (Pro, Enterprise, Education, or Pro for Workstations) or Windows 10 equivalents.
- Admin permissions: You’ll need Intune Administrator or Policy and Policy Manager rights to import devices and assign profiles.
- Network access: Devices need outbound internet access during OOBE to reach Microsoft’s Autopilot and Intune endpoints. A restrictive proxy or firewall is a common, easily overlooked blocker.
How to set up Autopilot in Intune (step by step)
Step 1: Get the hardware hash
Every device needs a unique hardware hash uploaded before Autopilot recognizes it. If you bought hardware through an OEM or reseller that’s an Autopilot partner, this is often done for you automatically. If not, capture it manually using Microsoft’s documented PowerShell method:
- Boot the device into Windows.
- Open PowerShell as administrator.
- Run the following to install the required module and generate the hash file:
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv
- This produces a CSV containing the device’s serial number, model, and hardware hash.
Step 2: Import devices into Intune
- Sign in to the Microsoft Intune admin center.
- Go to Devices > Windows > Windows enrollment.
- Under Windows Autopilot Deployment Program, select Devices.
- Click Import, then upload the CSV file from Step 1.
- Wait for the import to finish before adding another batch. A single CSV upload can register up to 500 devices at once.
Step 3: Create and assign a deployment profile
- Under Windows enrollment, select Deployment Profiles > Create profile > Windows PC.
- Choose the deployment mode: User-driven or Self-deploying.
- Configure the out-of-box experience settings – hide or show privacy settings, EULA, and account type.
- Assign the profile to the device group containing your imported devices.
- Ship or hand off the device. On first boot, it will pick up the profile automatically.
Why Autopilot deployments fail (and how to fix the most common ones)
Most failures fall into a handful of predictable categories rather than being random Autopilot bugs.
No license assigned. If the enrollment status page (ESP) gets stuck at “Identifying,” the most common cause is a missing Entra ID P1 or Intune license on the signing-in user. Cross-checking your pending Autopilot users against your licensed accounts before shipping devices catches this early.
Profile not assigned. A device that’s registered but shows no profile in Intune will sit at a generic OOBE screen instead of your branded one. Verify the device’s group membership and confirm the deployment profile is actually assigned, not just created.
TPM attestation failure. Specific to self-deploying and White Glove modes. If the device shows a “securing your hardware” step that times out, check that the TPM firmware is current and the system clock is accurate – TPM certificate validation is time-sensitive and fails silently if the clock has drifted.
Network and proxy blocks. If a device never gets past the OOBE welcome screen or shows consumer branding instead of your organization’s, it likely can’t reach Microsoft’s Autopilot and Intune endpoints. Whitelisting the required URLs on your firewall or proxy usually resolves this.
App installation timeouts during ESP. If devices sit at “Installing apps” far longer than expected, the ESP has a default timeout of around 60 minutes per phase. Reducing the number of ESP-tracked apps or checking for Win32 app dependency issues is the usual fix.
I’ve found that fast triage almost always starts in the same place: check which OOBE screen the device is stuck on before digging into logs. It narrows the problem down to registration, profile assignment, TPM, or app installation before you’ve opened a single event log.
Frequently asked questions
Is Windows Autopilot the same as Microsoft Intune?
No. Autopilot handles initial device setup and enrollment. Intune manages the device on an ongoing basis afterward – apps, policies, and compliance.
Do I need a separate license for Autopilot?
Autopilot itself doesn’t require a standalone license, but users enrolling devices need a Microsoft Entra ID P1 license, and the organization needs an Intune subscription.
Can I test self-deploying mode on a virtual machine?
Not reliably. Self-deploying mode requires a physical TPM 2.0 and TPM attestation, which a Hyper-V VM with a virtual TPM doesn’t replicate. Use user-driven mode for VM-based testing instead.
How many devices can I register at once?
Up to 500 devices per CSV file uploaded through the Intune admin center. Confirm one batch has finished registering before starting another.
What’s the difference between user-driven and self-deploying mode?
User-driven mode requires a person to sign in with their own credentials during setup. Self-deploying mode requires no user sign-in and authenticates the device itself via TPM, making it suited for kiosks and shared devices rather than personal laptops.
Getting Autopilot and Intune set up correctly the first time saves a lot of support tickets down the line. Once devices are enrolled, most of the day-to-day admin work shifts to smaller Outlook and Microsoft 365 tasks – things like creating a rule in Outlook to route mail automatically, or adding a shared mailbox in Outlook for a new department. If users report sluggish Teams performance after a fresh deployment, clearing the Teams cache is usually the fastest fix worth trying first.