Using Autopilot will give you many benefits, especially when combining it with Autopilot White Glove/ Pre-Provisioning. When you have 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

1. Introduction

When we were enrolling many new devices at a customer site, no problems were encountered because we had 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

We encountered no problems with the whole bunch of devices—they were all the same, at least that’s what we thought. After the first ten devices, however, we started encountering some weird issues with the next one.

After pressing the Windows logo key five times and starting the pre-provisioning deployment, it failed within a few seconds. 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 error, but this screen mentions 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 more information.

So we pressed Shift + F10 and opened PowerShell to examine the event logs and start troubleshooting. When the first step fails, the first place to look is the Microsoft-Windows-ModernDeployment-diagnostics-Provider event log.

As shown above, the problem is obvious: 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 allowing 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 one you registered with 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.

However, 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 even gives 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’s 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/