Last Updated on February 5, 2023 by rudyooms

Again… I am writing a blog about TPM attestation. Why? Because sometimes, even when your device doesn’t have the Intel 11 gen or it isn’t an AMD device, you could still end up with some attestation errors during Autopilot for modern deployments.

I guess today something broke at Microsoft ?

0x81039001 again – Microsoft TPM attestation service issues? : Intune (reddit.com)

So I will create a separate blog to summarize the troubleshooting stuff I showed in the TPM attestation series

I will divide this blog into multiple parts

1. The issue
2. How to troubleshoot TPM attestation issues
3. How to retry the Pre Provisioning
4. Test-AutopilotAttestation
5. Conclusion

1. The Issue

First, let’s start with the issue that starts occurring again today. We were (trying) to enroll 30 new Lenovo devices into Autopilot for pre-provisioned deployment.

Of course, we made sure we have the latest Win10 21h2 Build KB5007253 which fixes the Intel Tiger Lake attestation issue like I am describing in this blog

But this time, the devices didn’t have a firmware-based Intel (11th gen), AMD, or Qualcomm TPM but one from Nuvoton! So we should expect no issues with that one, right?

Think again! We ended up with the error: TPM attestation failed! 0x81039001 !

So no deployments for us today, let me explain how to start troubleshooting

2. How to troubleshoot TPM Attestation issues

I already did some blogs about this topic… but let me summarize how you could detect what is going on.

1. TPMTool
2. Certreq
3. TrustedTPM File
4. Mdmdiagnosticstool
5. Determing if the EKCert is available
6. Firmware

2.1 TPMTool

Of course, we need to determine first if Attestation is even possible and if the device has the proper TPM version. To do so enter this command: TPMtool getdeviceinformation. This will give you a simple overview of the TPM capabilities

Now we are sure everything is good to go, let’s go forth!

2.2 Certreq

As shown in my other blogs, I am using the certreq tool to determine if it’s possible to start the AIK enrollment. So let’s start with that one by entering this command: certreq -enrollaik -config “”

Take a look at the screenshot above. I am going to explain it some more. Normally It will show you the AIK enroll url it is using.

Please note: You need to enter the “” after -config, if you define something else (Like ”), the AIK attestation URL is not going to work! You will end up with a screen giving you the error: 0x80072ee5 (WinHttp: 12005 ERROR_WINHTTP_INVALID_URL)

2.3 TrustedTPM File

After running the certreq tool, we finally fetched the AIK URL. But we still need to check if the AIK URL is a valid one. To do so please download the trustedtpm.cab file from the Microsoft site

https://go.microsoft.com/fwlink/?linkid=2097925

Please note: In the screenshots above you could have noticed the NTC-KeyID .NTC (Nuvoton), INTC (Intel), AMD or STM (STMicroelectronics) are all just TPMS vendors. It depends on your hardware vendor which KeyId you will get.

When you have downloaded the file, extract and open the version.txt. Just simply search for the part after NTC-KeyId-.

As shown above, it’s in the version.txt file.. so we can be sure the url is a valid one because that url is very important… if it’s not in the file…. AIK enrollment will fail!

Another important note to add: When you have found the AIK URL, please check if that AIK Cert is NOT “removed” as shown below!

It looks like when Microsoft determines that somehow that AIK CA URL is used to deliver AIK certificates for vulnerable firmware versions, it will pull back that AIK URL even when it’s also used for not vulnerable firmware! In the example above, I guess Microsoft decided to shut down the AIK CA for that specific AMD fTPM .

When trying to re-enroll a previous working device with Autopilot for pre-provisioning deployments, you could run into this error: 0x800705b4 at the securing your hardware Phase when that AIK CA is withdrawn!

What did we learn from this nice error: Even when it worked before, it doesn’t guarantee that it will work in the future!

2.4 Mdmdiagnosticstool

So when we do have a valid (not vulnerable) and working TPM and we know that the AIK enrollment url is fine so let’s get some more TPM information.

Enter this nice command to get the required information: mdmdiagnosticstool -area TPM -cab c:\temp\tpm.cab

Normally you won’t get an error… but this time… you can guess what is going to happen

We are receiving 0x80190190 AKA -2145844848 error HTTP_E_STATUS_BAD_REQUEST. Luckily it will still create the cab file within in the certreq_enrollaik.txt file. Please open that one and search for errors!

As shown above, we are prompted with the error: “Failed to parse SCEP request”. The error will tell us the Simple Certificate Enrollment Protocol request failed during the verification phase on the certificate registration point.

Normally when everything is fine, you will notice the PkiStatus: SCEPDispotionSuccess. Sounds way better than the error we got

In this file, you would again notice the AIK url but as we know by now the AIK url isn’t the issue… let’s continue

2.5 Determining if the EK cert is available

When you have read my other blogs, you will know that the EK certificate (EKCert)is very important, if we don’t have the possibility to fetch that one and its intermediate certificate we could have a problem.

When you want to be sure you have a working EKcert, the easiest ways to check out if you have a working EK cert are these 2 options

*Registry

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tpm\WMI\Endorsement\EKCertStore\Certificates\

*get-tpmendorsementkeyinfo

As shown above, we have got the requirements set up. No problems with the EKCert here!. After spending some time troubleshooting, I noticed on Twitter that a lot of people were suddenly experiencing TPM issues. So I decided to quit for today and start over tomorrow. And yes…!!! after a night of sleep, it was working!

2.6: Firmware

It sounds pretty obvious, but it’s also easily forgotten! When experiencing TPM attestation issues it’s always and I mean always!!! best practice to determine if there is new firmware available!

Because sometimes, even when the device tells you that it’s ready for attestation it doesn’t mean it’s ready for attestation. In one of my latest blogs, I showed you the fact that Microsoft also maintains a list of TPMs that have vulnerable firmware. Guess what Microsoft does with these naughty TPMs…. They will be blocked

Ready For Attestation False and the 0x81039001 TPM time-out (call4cloud.nl)

3. How to retry the Pre-Provisioning

If you end up with a Red Autopilot Screen mentioning that TPM attestation failed, you now know how to troubleshoot those attestation issues. If you have solved them, I assume you want to retry the Pre-Provisioning, right?

A possible solution is to reset the device but if you don’t want to wait, just open this registry key

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\AutopilotSettings

In this registry key you need to delete 2 REG_SZ keys:

DevicePreparationCategory.Status

DeviceSetupCategory.Status

After you deleted those 2 registry keys, you need to run the “AikCertEnrollTask” as shown below

In a couple of seconds, the device will restart the Aik Certificate Enrollment process in the background. If the scheduled task finishes without any errors, you can press the retry button again to retry the Autopilot pre-provisioning

If you want to read more about this wonderful “AikCertEnrolltask” scheduled task and TPM attestation please read this blog below

Ready For Attestation False and the 0x81039001 TPM time-out (call4cloud.nl)

4. Test-AutopilotAttestation

When you don’t want to go through the hassle to try to solve it manually, you could always try out this PowerShell script. This PowerShell Script will try to test and remediate some attestation issues

PowerShell script to troubleshoot TPM attestation issues (call4cloud.nl)

Of course, it doesn’t solve “throttling” or “latency” issues at the service side at Microsoft. The latency issue is described in this Microsoft in this incident: IT431147

Conclusion:

Knowing how to troubleshoot can give you some insights into what’s happening or what could be wrong. I was expecting to see a Service warning in the Service Health and Message center…. but unfortunately, nothing was mentioned about this issue

Sometimes it’s the Intel 11^th gen issue, sometimes it’s just the TPM not supporting attestation, sometimes the EKCert can’t be retrieved, and sometimes Microsoft withdrew an AIK ca, and sometimes it’s just the need for patience…