The old way of setting up a corporate laptop meant IT manually imaging the device, installing applications one by one, joining it to a domain, and shipping or handing it to the user only after hours of preparation. Windows Autopilot replaces that entire process with something the user can do themselves, out of the box, just by signing in.
This guide walks through a real user-driven Autopilot enrollment from a Contoso Startup lab, covering hardware hash registration, deployment profile configuration, the out-of-box sign-in experience, and what actually happens when the device shows up in Intune. It also covers a real enrollment failure that came up during testing, not just the steps that worked on the first try.
What Windows Autopilot actually does
Windows Autopilot is a set of cloud-based technologies that takes a brand new or wiped Windows device and turns it into a fully enrolled, policy-compliant, work-ready machine, with the user doing nothing more than connecting to a network and signing in with their work account.
🖥️ The old way
IT receives the device, builds a custom image, installs applications manually, joins it to a domain, applies group policy, and ships or hands it to the user only after hours of preparation per machine.
☁️ The Autopilot way
The OEM or IT registers the device’s hardware hash once. The user unboxes the device, connects to Wi-Fi, signs in with their work account, and Intune handles Entra join, enrollment, policies, and apps automatically.
In this lab, the deployment mode used is user-driven, which means the device is associated with the specific user who signs in during setup. This is the most common Autopilot scenario for standard corporate laptops, as opposed to self-deploying mode, which is meant for shared or kiosk-style devices with no specific assigned user.
ℹ️ Beginner-friendly explanation: Think of the hardware hash as a fingerprint for the laptop. Once that fingerprint is registered in Intune, Windows recognises the device as belonging to your organisation the moment it is turned on, even before anyone signs in.
Prerequisites
Before starting the Autopilot lab, confirm the following are in place:
- A Microsoft Intune or Microsoft 365 tenant with Autopilot licensing included
- An appropriate Intune role, such as Intune Administrator or Policy and Profile Manager
- A Windows 10 or Windows 11 device, real or virtual, that is not yet enrolled anywhere
- Local administrator access on that device to run PowerShell and collect the hardware hash
- A Microsoft Entra ID security group dedicated to Autopilot devices
- A standard user account in Entra ID to sign in with during OOBE
- Automatic MDM enrollment already enabled in Entra ID
ℹ️ Lab tip: A Hyper-V or other virtual machine works fine for this lab if you do not have a spare physical laptop. The hardware hash collection script works the same way on a VM, and resetting a VM back to OOBE is much faster than reimaging a physical device.
Confirm automatic MDM enrollment
Before Autopilot can work, Entra ID needs to know that signed-in users should automatically enroll their devices into Intune. Without this setting, a user can sign in during OOBE and the device will join Entra ID, but it will not enroll into Intune for management.
Step 1: Check the MDM user scope
In the Microsoft Entra admin center, navigate to:
Confirm the MDM user scope is set to Some or All. For a pilot lab, scope it to a specific group rather than All users.
Replace this placeholder with your actual screenshot later.
💡 Why this matters: This is one of the most common reasons an Autopilot device joins Entra ID successfully but never appears as managed in Intune. Entra join and Intune enrollment are related but separate states, and this setting is the bridge between the two.
Prepare the Autopilot dynamic device group
Autopilot deployment profiles are assigned to a group, not to individual devices. The cleanest approach is a dynamic device group that automatically includes any device with an Autopilot enrollment profile assigned.
Create the dynamic device group
In the Microsoft Entra admin center, navigate to:
| Group type | Security |
| Group name | GRP-Autopilot-Devices |
| Membership type | Dynamic Device |
| Dynamic membership rule | (device.devicePhysicalIDs -any (_ -contains "[ZTDId]")) |
Replace this placeholder with your actual screenshot later.
ℹ️ What ZTDId means: ZTDId stands for Zero Touch Deployment ID. Every device registered in Windows Autopilot gets this identifier, and the dynamic rule above automatically captures any device that has gone through Autopilot registration, without needing to add devices to the group manually.
Collect the hardware hash
The hardware hash is a unique identifier generated from the device’s firmware. Microsoft, an OEM, or a CSP partner can supply this for new retail or enterprise purchases. For a lab environment, you collect it yourself using PowerShell.
Run the hash collection script
On the target Windows device, open PowerShell as Administrator and run:
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile C:\Autopilot\WINAUTO452-hash.csvThis generates a CSV file containing the device serial number, hardware hash, and product ID.
Replace this placeholder with your actual screenshot later.
💡 Run as Administrator: This script must run in an elevated PowerShell session. If it fails silently or returns no data, the most common cause is a non-elevated PowerShell window.
Import the hardware hash into Intune
With the CSV file ready, register the device in Intune’s Autopilot device list.
Step 1: Import the CSV
In the Microsoft Intune admin center, navigate to:
Select the CSV file generated in the previous step and upload it.
Replace this placeholder with your actual screenshot later.
Step 2: Sync and confirm the device appears
Click Sync to trigger Intune to process the import. This can take a few minutes. Refresh the Autopilot devices list to confirm WINAUTO452 appears with a status of registered.
Replace this placeholder with your actual screenshot later.
ℹ️ Import delay: The import can show as processing for several minutes before the device appears in the list. This is normal and does not need to be repeated.
Create the Autopilot deployment profile
The deployment profile defines what happens during the out-of-box experience. This is where you choose user-driven mode, Entra join type, and the device naming convention.
Step 1: Create the profile
Navigate to:
Replace this placeholder with your actual screenshot later.
Step 2: Configure the OOBE settings
| Profile name | AP-Profile-Contoso-UserDriven |
| Deployment mode | User-driven |
| Join type | Microsoft Entra joined |
| Microsoft Software License Terms | Hide |
| Privacy settings | Hide |
| User account type | Standard |
| Device name template | WINAUTO%RAND:3% |
Replace this placeholder with your actual screenshot later.
✅ Why hide license terms and privacy settings: Hiding these screens shortens the OOBE flow for the end user. They are still accepted on the user’s behalf, but the user does not need to click through several extra screens before reaching their desktop.
Assign the deployment profile
Assign the profile to the dynamic Autopilot device group created in Section 4. Because the group is dynamic and based on the ZTDId attribute, the newly imported device should already qualify for membership.
Assign and confirm
- Open the deployment profile and select Assignments.
- Select Add groups and choose
GRP-Autopilot-Devices. - Save the assignment.
- Return to the Autopilot devices list and confirm the Profile status column shows Assigned for WINAUTO452.
Replace this placeholder with your actual screenshot later.
Replace this placeholder with your actual screenshot later.
💡 Profile status stays Not assigned? This is the single most common stall point in an Autopilot lab. See Section 11 for exactly what to check.
The out-of-box sign-in experience
With the hash registered, the device in the group, and the profile assigned, reset or boot the target device to OOBE. This is where the user-driven experience actually shows itself.
What the user sees
- The device boots to a Windows setup screen and connects to a network.
- Because the device is recognised as an Autopilot device, it skips the standard consumer OOBE screens and goes straight to organisational sign-in.
- The user signs in with their work account, for example
autopilotuser@contoso.onmicrosoft.com. - The Enrollment Status Page (ESP) appears, showing progress as policies and apps install in the background.
- Once ESP completes, the user lands on a fully configured desktop.
Replace this placeholder with your actual screenshot later.
Replace this placeholder with your actual screenshot later.
ℹ️ What is actually happening behind ESP: While the user watches the progress bar, the device is being Entra joined, enrolled into Intune, and is downloading and applying the configuration profiles, compliance policies, and required apps assigned to it. This is the same work an IT technician used to do manually before handing over the laptop.
Verify the device in Intune
After the user reaches the desktop, confirm the device shows up correctly in Intune as corporate-owned, compliant, and enrolled.
| Field | Expected value |
|---|---|
| Managed by | Intune |
| Ownership | Corporate |
| Join type | Microsoft Entra joined |
| Compliance | Compliant (once the compliance policy evaluates) |
| Primary user | The account that signed in during OOBE |
Replace this placeholder with your actual screenshot later.
✅ This is the real proof point: a green checkmark in ESP tells you setup finished. The device record in Intune showing Corporate ownership and Intune management tells you the enrollment is actually correct, not just that the wizard completed.
Troubleshooting what actually went wrong
During this lab, the deployment profile initially stayed on Not assigned even after the assignment was saved, and the device’s MDM status briefly showed as None after the first Entra join attempt. Here is what was actually checked, in the order it was checked.
Profile status stuck on Not assigned
The dynamic device group had not finished evaluating membership for the newly imported device. Dynamic group membership calculation is not instant, it can take several minutes after a device is imported before the group rule picks it up.
💡 What fixed it: Waiting roughly 10 minutes and then triggering a sync on the Autopilot devices page resolved the assignment. For urgent lab testing, a small static group with the device added manually avoids this delay entirely.
MDM status showed None after Entra join
The device successfully joined Microsoft Entra ID during OOBE, but the device record in Intune briefly showed an MDM status of None instead of Intune MDM.
💡 What fixed it: This was confirmed to be the MDM user scope setting from Section 3 not yet applying to the test user’s group. Once the user account was confirmed to be inside the scoped group for automatic MDM enrollment, a re-attempt completed enrollment correctly.
| What you see | Most likely cause | What to check |
|---|---|---|
| Deployment profile stays Not assigned | Dynamic group has not finished evaluating the device | Wait several minutes, then sync the Autopilot devices list, or use a static group for urgent testing |
| OOBE shows standard consumer setup, not organisational sign-in | Hardware hash was not imported, or the device is not yet recognised as an Autopilot device | Confirm the device appears in the Autopilot devices list before booting to OOBE |
| Device joins Entra ID but MDM status shows None | MDM user scope does not include the signing-in user | Confirm the user account is inside the scoped group for automatic MDM enrollment |
| ESP hangs on app or policy installation | Assigned apps or policies have not finished deploying, or a dependency failed | Check Company Portal app status and the device’s policy check-in status in Intune |
| Device does not appear in Intune at all | License assignment, MDM scope, or enrollment restrictions are blocking enrollment | Confirm Intune licensing is assigned to the user and enrollment restrictions allow the platform |
MDM status: None
Join type: Microsoft Entra joined
Managed by: Not managedThis is exactly what an Entra-joined-but-not-yet-Intune-enrolled device looks like. It is a normal, fixable state, not a failed deployment, as long as the underlying MDM scope is corrected.
Summary
Windows Autopilot user-driven enrollment replaces hours of manual imaging and configuration with a process the end user completes themselves, just by signing in. The real value is not the OOBE wizard, it is everything Intune does automatically behind that progress bar: Entra join, MDM enrollment, corporate ownership, compliance evaluation, and app deployment.
🔑 Key takeaways
- User-driven mode associates the device with whoever signs in at OOBE, the most common scenario for standard corporate laptops
- The hardware hash is the device’s fingerprint and must be registered in Intune before Autopilot recognises it
- Use a dynamic device group based on the ZTDId attribute so newly imported devices are automatically included
- Automatic MDM enrollment scope in Entra ID must include the signing-in user, or the device will join Entra ID but never enroll into Intune
- A deployment profile stuck on Not assigned is usually just dynamic group evaluation delay, not a configuration error
- MDM status showing None after Entra join means the device joined identity but has not yet enrolled into management, these are separate states
- The real proof of a working enrollment is the device record in Intune showing Corporate ownership and Intune management, not just a completed ESP screen
- Always test with a pilot device and pilot user before relying on Autopilot for a wider rollout
