Engineering
What Get-WindowsAutopilotInfo Actually Does (and How to Use It Today)
Note 4 in the thread Getting devices into Intune
Windows Autopilot has a simple promise. A new laptop comes out of the box, the user signs in with their work account, and Intune turns it into a managed, configured machine without anyone touching an image. The catch is that Intune has to recognize the device before that first sign-in. It does that with the device's hardware hash, and Get-WindowsAutopilotInfo is how you get it.
If you buy through a reseller or OEM that registers devices for you, you may never need this. For everything else (existing machines, a test box, the one laptop that slipped through), this is the tool.
What the script does
It reads a handful of identifiers from the device: the serial number, the Windows product ID, and the hardware hash, which is a long blob built from the TPM, the motherboard and other components. Then it does one of two things with them:
- Uploads them straight to Intune (with
-Online). This is the way to go when the device has internet access and you have an admin account handy. - Writes them to a CSV (with
-OutputFile) that you import into the Intune admin center later.
The old version of this post said it produces a JSON file. It doesn't. The output is a CSV, and that's the format Intune's import expects. (The JSON you may be thinking of is the Autopilot profile file, which is a different thing entirely.)
Getting the script
It lives in the PowerShell Gallery, so don't go hunting for a copy on a file share. From an elevated PowerShell prompt:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
Install-Script -Name Get-WindowsAutopilotInfo -Force
The execution policy change only lasts for that window, which is what you want on a machine you're about to hand to someone. If it asks to install the NuGet provider, say yes.
The quick way: upload it directly
Get-WindowsAutopilotInfo -Online
You'll get a Microsoft sign-in prompt. Use an account with the Intune Administrator role (or a custom role that can manage Autopilot devices). The first time anyone in the tenant runs it, you'll also be asked to consent to the permissions the script needs. After that, it uploads the hash and waits until Intune shows the device.
A few switches worth knowing:
-GroupTag Kioskstamps a group tag on the device, which you can use in a dynamic group to decide which Autopilot profile it gets.-Assignwaits until a deployment profile has actually been assigned, so you're not guessing.-Rebootrestarts the device once it's done, which is handy if you're doing this during OOBE.
Speaking of OOBE: if the device is already sitting at the out-of-box setup screen, press Shift+F10 to get a command prompt, type powershell, and run the same commands. No need to finish setup first.
The offline way: export a CSV
No network, or not signing in with admin credentials on a user's device? Save the hash to a USB stick instead:
Get-WindowsAutopilotInfo -OutputFile D:\AutopilotHWID.csv
Then in the Intune admin center go to Devices > Enrollment, pick the Windows tab, open Devices under Windows Autopilot, and choose Import. (Microsoft reshuffles these blades every so often, so if the path has moved, search for "Windows Autopilot devices".) You can combine several devices into one CSV, up to 500 rows per file. Just keep the header row from the first one only.
After the upload
Registering the device is only half of it. It still needs a deployment profile:
- Put it in a group. The usual approach is a dynamic device group. To catch everything with a particular group tag, the rule looks like
(device.devicePhysicalIds -any (_ -eq "[OrderID]:Kiosk")). - Assign your Autopilot profile to that group.
- Wait for "Assigned". In the Autopilot devices list, the profile status needs to say Assigned before you reset or start the device. Start too early and it goes through a normal, unmanaged setup, and you'll get to do it all again.
A few things that trip people up
- Run it elevated. Reading the hardware hash needs admin rights. A non-admin prompt gives you an error or an empty hash.
- Virtual machines work, mostly. Hyper-V VMs with a virtual TPM register fine for testing. Some other hypervisors produce hashes Autopilot won't accept.
- Swapped a motherboard? The hash changes, and the device may not be recognized anymore. Delete the old record and register it again.
- There's a newer option. Windows Autopilot device preparation doesn't use hardware hashes at all. It works from the user's sign-in and a device group instead. If you're starting fresh, it's worth a look before you commit to hash uploads.