Windows-itpro-docs: Issue with malformed hardware hash - bad length

[ShrCaJesmo]

This issue occurred with a Lenovo ThinkCentere M93p, this might matter. Ideally I'd like to just make a PR for this to document the troubleshooting and resolution steps but it seems a weird fit for any of the autopilot docs.

Pulling the hash with the script worked as expected. Importing the hash into Intune didn't though - selecting the file is fine, it passes the row check, but clicking Import does nothing. A network trace reveals that the import fails with error 400, the error body is Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'

Trying to decode the base64 with this snippet throws Invalid length for a Base-64 char array or string

[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DeviceHash"))

running it through oa3tool /decodehwhash=DeviceHash throws The value specified in /DecodeHwHash is neither a file nor a base64-encoded string

The issue seems to be that the payload needs padding. All those 'A's are effectively empty data, equal to 000000, but this means the data can end up not ending on a clean full byte moving between 6-bits to 8-bits. So we can use = to "pad" the payload with a non-6-bit padding. Wikipedia explains this better.

The padding isn't necessary per Base64, but the implementation can require it. It seems the process that generates the Base64 does so without padding, but autopilot and Powershell's Base64 implementations require padding.

So now to fix it - you can either add or remove. I fixed by adding.

If the hash can't be decoded with the powershell above, to the original hash, add an "=". If it still fails, add a second. If it still fails, remove both "=" and add an "A" instead. If it still fails, to the new hash with an extra "A", add "=", and repeat until it decodes to mostly illegible text (it stops throwing errors). This is a valid padded base64 string. Replace the hash in the csv with this new one then try again.

To do it by removal, replace the last "A" with "==". Then try removing an "=". Then the other. Then (with both "=" removed), replace the next last "A" with "==", so on, so forth.

Never have more than 2 "=" in a row, and never have them anywhere else but at the very end of the payload. So no "===" and no "A=A"

The script itself isn't at fault, this seems to be a discrepency between the data generated and stored in devicehardwaredata in mdm-devdetail-ext01 and what intune expects, and it seems to be that the encoder that generates the devicehardwaredata isn't encoding with padding. It might have been fixed in subsequent releases of windows, I don't have the build version documented.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: adcfcc02-d931-66e3-6f4f-c14b936358e6
• Version Independent ID: 8972647b-ba21-b68f-b698-5fb6e9e9f1fd
• Content: Troubleshooting Windows Autopilot - Windows Deployment
• Content Source: windows/deployment/windows-autopilot/troubleshooting.md
• Product: w10
• Technology: windows
• GitHub Login: @greg-lindsay
• Microsoft Alias: greglin

[illfated]

Awesome research. I support your suggestion to make a PR for it. I must humbly apologize for not being able to assist with much more than reviewing grammar & MarkDown formatting.

[ShrCaJesmo]

This would be the right article for it?

[illfated]

Good question. I have not delved that deep into it yet, but it would seem a very good place to start.

[ShrCaJesmo]

Ok thanks, I'll try to put this in a bit more of a "documentation-like" style instead of the ramble above and generate the PR tomorrow - in the meantime do we leave this open so it's documented here?

[illfated]

Very well. I concur. True, we leave this issue ticket as is until the PR is closed. Are you familiar with how to auto close tickets from a PR & its commit text?

[ShrCaJesmo]

I'm not, no - still getting the hang of github. If you have resources I could check out, they'd be much appreciated! I have to run but I'll get back on this tomorrow :)

[illfated]

Feel free to check out my PR https://github.com/MicrosoftDocs/windowsserverdocs/pull/3969 and compare the commit text with the opening PR comment (close to identical).

TL;DR : basically put a line at the end of the commit text, using one of these keywords "Closes / Fixes / Solves / Resolves" followed by #6150 (this ticket number).

[ShrCaJesmo]

Thanks for your help! The PR is made, but it's a bit wordy. I'm not really sure how to trim it down without leaving out important details regarding what exactly the issue is that the steps fix.

[greg-lindsay]

Very interesting, thanks for the PR.

[illfated]

@ShrCaJesmo : You are more than welcome. That initial work of yours seem to be quite the foundation for your PR, so good job making it this far without any assistance from my side (or any of the tech writers and copy reviewers). Thank you. Keep up the good work. 👍