Setup guide · from scratch
Register Windows devices into Autopilot (hardware hash)
This is how a Windows device actually gets into Autopilot: you capture its hardware hash, upload that hash to Intune, and the Autopilot service now recognises the machine so it can be zero-touch provisioned at next reset. The trap that catches almost everyone: only ever touch the hash CSV in a plain-text editor like Notepad. Open or save it in Excel and the file is silently mangled, the import fails, and the error message won't tell you why.
≈ 20 min
Windows — Autopilot & USB provisioning · step 12 of 12 · ≈ 20 min‹ Previous
Do these first — this guide assumes you already have:
- An active Intune subscription with a licence assigned to your admin account
- Microsoft Entra ID P1 or P2 (Autopilot rides on Entra premium features)
- Windows automatic enrolment enabled, with MDM user scope covering the enrolling user
- Your account holds Intune Administrator or Policy and Profile Manager, and has consented to the Intune and Microsoft Graph PowerShell apps
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 20 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
The steps
- Before you touch a device, confirm the four prerequisites are actually in place: an…
- Decide which route the device takes in. For brand-new kit bought through a…
- On the target device, sign in and open an elevated Windows PowerShell prompt (Run…
- Capture the hash to a file. Run: Get-WindowsAutopilotInfo -OutputFile…
- Alternatively, skip the file and the manual import entirely by uploading straight…
- If you're importing a CSV rather than using -Online, sanity-check the file in…
- In the Microsoft Intune admin center, go to Devices, choose Windows under 'By…
- On the Windows Autopilot devices blade, select Import from the toolbar, browse to…
- Once import reports complete, select Sync in the toolbar, then use Refresh…
- Set or correct the group tag if you didn't do it at capture. Select the device in…
- Confirm the job is done: the device shows in the Windows Autopilot devices list…
0 of 11 done
Step 1. Before you touch a device, confirm the four prerequisites are actually in place: an Intune licence on your admin account, Entra ID P1 or P2 on the tenant, Windows automatic enrolment switched on, and your account holding Intune Administrator or Policy and Profile Manager. Autopilot registration will appear to work without some of these and then fail silently at deployment time.
Screenshot: The Intune admin center Tenant admin > Tenant status or Licenses page showing an active Intune subscription, plus the Windows enrollment automatic enrolment blade set to some/all users. (captured during a live customer build — coming to this page)
Why: Registration (getting the hash in) and deployment (the profile applying) are separate stages. Missing automatic enrolment or a licence lets the hash upload succeed but breaks the actual out-of-box experience later, so the failure surfaces days after you thought the job was done.
Watch for: MDM user scope set to 'None' is the classic gap — the tenant looks configured but no user is actually in scope for enrolment.
Step 2. Decide which route the device takes in. For brand-new kit bought through a participating OEM or reseller, ask them to register it for you against your tenant ID — that is the proper production path and no hash handling is needed. Use the manual hardware-hash method described here for virtual machines, existing/legacy devices, or hardware from a non-participating vendor.
Screenshot: A simple decision split: OEM/reseller registration versus manual hash capture, with the three manual triggers (VM, existing device, non-participant vendor) called out. (captured during a live customer build — coming to this page)
Why: Manual hash registration means booting into Windows to harvest the hash, which is why Microsoft frames it as a testing and evaluation path rather than the way you'd onboard a thousand new laptops.
Don’t: Don't manually capture hashes for large fleets of new devices you bought through a partner — get the partner to register them at source instead. The 4K hash contains sensitive hardware detail that only the device owner should be circulating.
Step 3. On the target device, sign in and open an elevated Windows PowerShell prompt (Run as administrator). Then install the capture script by running, one line at a time: Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned then Install-Script -Name Get-WindowsAutopilotInfo. If asked to install the NuGet provider from the PSGallery, agree.
Screenshot: An elevated blue PowerShell window showing Install-Script -Name Get-WindowsAutopilotInfo completing, with the NuGet/PSGallery trust prompt visible. (captured during a live customer build — coming to this page)
Why: Get-WindowsAutopilotInfo reads the hardware hash out of WMI. The scoped execution-policy change only relaxes script running for that one session, which is tidier and safer than changing the machine-wide policy.
Watch for: The script was rewritten in July 2023 to use the Microsoft Graph PowerShell modules instead of the retired AzureAD ones. Make sure you pull the current version; old cached copies use dead authentication and will fail.
Step 4. Capture the hash to a file. Run: Get-WindowsAutopilotInfo -OutputFile C:\HWID\AutopilotHWID.csv (create the C:\HWID folder first if it doesn't exist). To stamp a group tag at capture time, add -GroupTag "Sales" (or whatever your tag scheme is). Copy the resulting CSV off the device onto a USB stick or share.
Screenshot: PowerShell showing the Get-WindowsAutopilotInfo command finishing, plus the resulting AutopilotHWID.csv sitting in C:\HWID in File Explorer. (captured during a live customer build — coming to this page)
Why: The serial number captured alongside the hash is what lets you tell one machine's row from another later. Tagging at capture time saves a manual edit pass in the portal afterwards.
Don’t: Don't rename the CSV headers or open it to 'tidy it up'. The columns and header text are consumed exactly as written.
Step 5. Alternatively, skip the file and the manual import entirely by uploading straight to Intune from the device. Run: Install-Script -Name Get-WindowsAutopilotInfo -Force then Get-WindowsAutopilotInfo -Online. When the Entra sign-in prompt appears, sign in with an account that is at least an Intune Administrator; the hash then uploads by itself. This is the neat option for a device sitting in OOBE (press Shift+F10 to reach a command prompt, type powershell.exe, then run the commands).
Screenshot: PowerShell running Get-WindowsAutopilotInfo -Online with the Microsoft Entra sign-in dialog popped up over it. (captured during a live customer build — coming to this page)
Why: The -Online path collapses capture and import into a single step, so there's no CSV to shepherd and no chance of mangling it. Ideal for one-off or in-OOBE registrations.
Watch for: First run triggers an app-registration consent prompt in Entra. If your account can't consent, the upload stalls here — that's the Graph PowerShell permission the prerequisites mention, not a fault with the device. If you use this path, jump straight to step 9 to confirm.
Step 6. If you're importing a CSV rather than using -Online, sanity-check the file in Notepad before uploading. The header row must read exactly: Device Serial Number,Windows Product ID,Hardware Hash,Group Tag,Assigned User — case-sensitive, no extra columns, no quotation marks, saved as ANSI (not Unicode). Up to 500 device rows per file.
Screenshot: The CSV open in Notepad showing the exact header row and one data row, with the Save As dialog encoding set to ANSI. (captured during a live customer build — coming to this page)
Why: Intune validates this format strictly and rejects anything off-spec, often with an unhelpful error. Getting the header and encoding right first time saves a frustrating round of blind retries.
Don’t: Never open or save this CSV in Microsoft Excel. Excel reformats the long hash, can add quotation marks, and changes the encoding — the file looks fine but imports as garbage. Notepad only.
If this step errors: Intune policies taking 8 hours? Check WNS first
Step 7. In the Microsoft Intune admin center, go to Devices, choose Windows under 'By platform', then open Enrollment, and under Windows Autopilot select Devices. This 'Windows Autopilot devices' list is the registry of every hash your tenant knows about.
Screenshot: The Intune admin center with the Windows Autopilot devices blade open, showing the Import, Sync, Refresh and Delete buttons on the toolbar and the (possibly empty) device list. (captured during a live customer build — coming to this page)
Watch for: Microsoft reshuffles this navigation periodically and the labels drift (you may land via Devices > Enrollment > Windows). If you can't find it, search 'Windows Autopilot devices' in the portal search bar rather than hunting through blades. Describe-the-destination, not the exact clicks, is the safe bet here.
Step 8. On the Windows Autopilot devices blade, select Import from the toolbar, browse to your hash CSV, and select Import to begin. The upload and validation can take several minutes for a full 500-row batch.
Screenshot: The 'Add Autopilot devices' flyout with the CSV file selected and the Import button ready. (captured during a live customer build — coming to this page)
Why: Import is where format problems reveal themselves. A clean file processes quietly; a bad one throws a per-row error you'll need to read.
Watch for: If you see ZtdDeviceAssignedToAnotherTenant, that hash is already registered to a different tenant — you can't steal it back by re-importing; it must be deregistered from the other tenant first. ZtdDeviceAlreadyAssigned simply means it's already yours, so leave it be.
Step 9. Once import reports complete, select Sync in the toolbar, then use Refresh (repeatedly if needed) until your device appears in the list. Match it by serial number.
Screenshot: The Windows Autopilot devices list now showing the new device row with its serial number, and a 'sync in progress' notification. (captured during a live customer build — coming to this page)
Why: Import writes the record; Sync is what reconciles the Autopilot service with Intune's view so the device surfaces in the list. Skipping the sync is why people think an import 'didn't work'.
On a schedule: Give it several minutes and keep hitting Refresh rather than assuming failure — the sync is not instant and there is no progress bar worth trusting.
Step 10. Set or correct the group tag if you didn't do it at capture. Select the device in the list, and in the details pane on the right edit the Group tag field, then Save. The group tag is the value your dynamic device groups key off to decide which Autopilot profile a machine receives.
Screenshot: The per-device details pane open on the right with the Group tag field being edited and the Save button highlighted. (captured during a live customer build — coming to this page)
Why: Profiles are assigned to groups, and the cleanest way to sort Autopilot devices into groups is a dynamic membership rule matching the group tag (device.devicePhysicalIds -any _ -eq "[OrderID]:Sales"). No tag, or a mistyped one, means the device never lands in the right group and never gets a profile.
Watch for: Dynamic group membership does not update the instant you save the tag — it can lag well beyond a few minutes. If the device is in the Autopilot list but not yet in its group, that lag is usually the reason, not a mistake on your part.
If this step errors: Autopilot dynamic group lag: apps missing during ESP
Step 11. Confirm the job is done: the device shows in the Windows Autopilot devices list with the correct serial number and group tag, and (if you assigned one) a profile status that moves to Assigned. At that point the device is registered and will pick up its Autopilot experience on the next clean OOBE or reset.
Screenshot: The device row in the Windows Autopilot devices list expanded to show serial number, group tag, and Profile status = Assigned. (captured during a live customer build — coming to this page)
Why: Appearing in the list proves registration; a profile moving to 'Assigned' proves the group and profile plumbing behind it is working. Both matter — registration alone gets you nothing at OOBE without an assigned profile.
Watch for: Profile status can sit on 'Not assigned' for a while after the tag is set, because it waits on dynamic group membership and profile assignment to catch up. Recheck later before concluding something is broken.
Put these on a schedule
| Step | Recurring action to diarise |
|---|---|
| Step 9 | Give it several minutes and keep hitting Refresh rather than assuming failure — the sync is not instant and there is no progress bar worth trusting. |
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Autopilot dynamic group lag: apps missing during ESP — Autopilot devices join dynamic groups minutes to hours late, so the ESP runs before apps are assigned. Why the ZTDId rule lags and how to fix it.
- Intune policies taking 8 hours? Check WNS first — Intune delivers policy changes in minutes via WNS; the 8-hour sync is only a safety net. If WNS is blocked at the firewall, here's how to fix it.
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access