Last Updated on September 12, 2022 by rudyooms

Using Autopilot will give you a lot of benefits, especially when combining it with Autopilot White Glove/ Pre-Provisioning.  When you have got new devices, you are good to go but when you want to enroll existing “older” devices into Autopilot White Glove/ Pre-Provisioning you can run into some problems.

This blog will show you how to deal with the TPM Attestation error : 0x81039024

I will divide this blog into multiple parts

1. Introduction
2. The 0x81039024 error
3. Troubleshooting the 0x81039024 error
4. Solving the 0x81039024 error

1. Introduction

When we were enrolling a lot of new devices at a customer site no problems were encountered, because we previously enrolled them with Autopilot for Pre-provisioning deployments. After that first batch of new devices was done, the customer asked us to enroll some existing older devices. No problem at all, we took all the older devices with us to be reinstalled at our company.  

First, we checked if the devices had TPM 2.0 enabled as it is one of the requirements. Before we reinstalled the device we opened the TPM.msc and device manager to check if TPM 2.0 was available

-Starting: Tpm.msc (sorry for the blurry screenshot, but it says version 2.0)

-You could also make sure if the device has a TPM 2.0 by opening the Device Manager as shown below

After we checked if TPM 2.0 was available, we uploaded the device hash into Intune and waited for it to be assigned. After the deployment profile was assigned, we reinstalled the device with the latest Windows build available to be sure everything works.

2. The 0x81039024 error

No problems were encountered with the whole bunch of devices. The devices were all the same, at least that’s what we thought. After the first 10 devices, on the next one, we started encountering some weird issues.

After pressing the Windows logo key 5 times and starting the pre-provisioning deployment, within a few seconds it failed. At the first ESP step: Securing hardware we received the error: 0x81039024 and the famous autopilot red error screen appeared.

When installing the device with Windows 11, you will get a similar kind of error but this screen is mentioning the failed TPM attestation!

3. Troubleshooting the 0x81039024 error

The first thing we did, we try to google it. But not a lot of results at that time I can tell you. Luckily there are a lot of troubleshooting tools available to get some more information.

So we pressed Shift + F10 and opened PowerShell to take a look at the event logs to start some troubleshooting.  The first place to look when the first step fails will be the Microsoft-Windows-ModernDeployment-diagnostics-Provider event log.

As shown above, it’s obvious what the problem is. The TPM is not configured for hardware TPM attestation.

First, some backstory of the TPM.

Microsoft uses the Microsoft Platform Crypto Provider Key Storage Provider (KSP) to support the protection of the user’s private key by a TPM. This protection is done by using the ability of the entity requesting a certificate to cryptographically prove to a CA that the RSA Key in the certificate request is protected by a TPM.

Autopilot White glove needs TPM attestation to prove the device is, who he says it is to Azure. There needs to be a check if the device is the same device you have registered within Intune Autopilot. I guess you want to be sure no other devices can enroll with Autopilot into your tenant.

When you have some brand new devices, this normally will not be a problem because all devices released after 2016 should support TPM attestation.

But then there was a little vulnerability because the Infineon RSA library did not properly generate RSA key pairs and the devices with the Infineon TPM needed patching.

VU#307015 – Infineon RSA library does not properly generate RSA key pairs (cert.org)

And of course, companies not using the TPM did not update the firmware. So back to the devices that weren’t working. When opening the TPM.msc module again we noticed the Nuvoton TPM Version number: 7.2.0.1

And we realized this was a version that definitely needed to be patched.  To be sure we opened a PowerShell session to get some more information about the TPM: “Tpmtool getdeviceinformation” and “tpmtool gatherlogs c:\install\”

Windows 11 is even giving us way more information when running the getdeviceinformation command.

• TPM Firmware Vulnerability: 0x0000000A
• ADV190024 – ECDSA key generation (tpm.fail)
• TPM2_GetTestResult – TPM enter failure mode

4. Solving the 0x81039024 error

So we made sure we downloaded the right TPM firmware for this device from the Dell site

https://dl.dell.com/FOLDER07395932M/1/DELLTPM_NPCT750_7.2.2.0_64_v1.exe

Please Note: When upgrading a TPM, you could run into some issues if you didn’t clean the “owner” first. To make sure Windows wasn’t going to start auto-provisioning the TPM again and we again need to clean the owner, we first executed this command: disable-TpmAutoProvisioning

After this command was successfully executed we started the Firmware Update Utility to start upgrading the TPM its firmware

After the TPM was successfully updated, we made sure we enabled the TPM auto-provisioning again by entering: enable-tpmautoprovisioning

As shown above, the version is successfully updated to 7.2.2.0. Looking at the screenshot you will also notice AutoProvisioning is Enabled again. After taking these steps, we could enroll the device with Autopilot for pre-provisioning deployment with no problems at all.

Conclusion:

When you want to make use of Autopilot Pre-Provisioning deployments AKA White glove, please check some important items:

• Always use the latest Windows 10 /11 build

• Always check if the device has a TPM 2.0 and TPM attestation is enabled and ready!

• Please note: If you want to know more about TPM stuff, please read my blog series about TPM attestation

https://call4cloud.nl/category/attestation-and-compliance-series/