Breaking down the Windows Autopilot hardware hash

Lots of you have gone through the effort of gathering the Windows Autopilot hardware hash from a computer (with around 17 million downloads of the Get-WindowsAutopilotInfo script on the PowerShell Gallery), with even more devices registered directly by OEMs and resellers when the device is purchased.

But what exactly is a hardware hash? The documentation says that it contains details about the device, but it doesn’t go into specifics beyond the high-level info (manufacturer, model, serial number, “many other attributes that can be used to uniquely identify the device”).

Fortunately, the ADK contains a tool, OA3TOOL.EXE, that can be used to decode a hardware hash into its components. Look at what you can see from one of my devices. First, using this command line (with part of my hash obscured as I don’t want anyone to try to register my device to their tenant):

So yes, that’s a command with a 4000-byte hash provided as a command-line option. And the result is much prettier:

So what’s truly important from that? Well, the “oa3tool.exe /?” output provides a clue: There’s an additional “/ValidateHwHash” switch that will tell you if any “critical” fields, i.e. those required for Windows Autopilot, are not valid. If I run that on my computer’s hardware hash, here’s what I get:

So that’s telling me my computer doesn’t have a TPM, which Windows Autopilot needs for some scenarios (self-deploying, pre-provisioning), and that could be a critical problem. (In my case, the machine has a TPM, but it’s never been enabled in the firmware. It’s running Windows Server 2022, so that’s not a huge issue for me. I should probably fix that sometime though.)

So what are the “other” critical fields? Fortunately, the OA3Tool documentation spells that out for us:

• DiskSerialNumber
• TpmVersion
• EkPubHash
• MacAddress
• ProductKeyId
• SmbiosSystemFamily
• SmbiosSystemManufacturer
• SmbiosSystemProductName
• SmbiosSystemSerialNumber
• SmbiosUuid

That doesn’t mean each of the fields are always used, just that should all be defined and meet the requirements. For example, TPM 2.0 is required, so 1.2 won’t work. And there’s a hierarchy to how these are used, with the specifics not documented — obviously since Autopilot still works fine if you replace the disk drive with one that has a different serial number, you can see that it’s able to handle some hardware changes. But as the Windows Autopilot documentation indicates, some changes go too far, e.g. replacing a motherboard, since that changes too many attributes at once.

Obviously some of those fields aren’t unique by themselves, but could be used together with other fields (e.g. Manufacturer + Product Name + Serial Number).

Also notice that the hardware hash (which isn’t really a hash at all, but instead is just an encoded conglomeration of a list of attributes of the device) knows whether it was captured in the full OS vs. in Windows PE. If you capture it in Windows PE, some of the critical information will be missing as there may not be drivers available to even see the hardware details. So don’t do that.

Also note that the hash contains the date and time that it was generated, along with the OS version and patch level at that point, so this does generally change each time it’s captured. That’s no big deal since the hash is not compared literally, it’s broken apart and compared using those “critical” fields.

But what about the “non-critical” information in the hardware hash? Well, that’s not for Windows Autopilot, that’s just part of the OEM activation process. When the OEM injects a product key into the firmware of the device to activate the Windows install that ships on the device, information about the device and that key are passed to Microsoft via the computer build report, which includes the hardware hash. That applies to every OEM device shipped with Windows. You can read more about that in the OEM Activation documentation. (Interestingly, it’s this process that enables partners to register devices *without* using the hardware hash — they can provide other hardware details, e.g. Manufacturer + Model + Serial Number, to look up the hash in a big database of all devices manufactured using OAv3. So it’s still using the hash behind the scenes, they just get a simpler way that uses a database query to find the hash that was generated when the device was manufactured.)

(If any of this sounds familiar, you may have read about it in Per’s blog post.)