This blog explores what happened when a device enrolled with Autopilot pre-provisioning got stuck at “Please Wait while we set up your device” for 10 minutes, ending with error 801c03ed / Invalid Token the moment it should have re-joined Entra Id /Azure AD.

We’ll break down the Microsoft Entra ID Join process, what caused the delay, and how to fix it. But before we do, we need to thank Ákos for reaching out and bringing up this issue.

Introduction

After completing the Autopilot pre-provisioning process and resealing the device, the expected Entra Rejoin / Azure Ad Join process failed unexpectedly. Instead of completing the enrollment, the device was stuck at the “Please Wait while we set up your device” screen for 10 minutes straight.

After waiting exactly 10 minutes, the “Please wait while we set up your device” screen changed to a nice error page showing the 801c03ed error with the Invalid Token server message.

This 801c03ed error code often refers to administrator policies preventing devices from joining Microsoft Entra ID (the user is not allowed to enroll the device), but trust me, that wasn’t the issue in this case. The registration setting specifies which users may join devices to Microsoft Entra was set to All.

After ruling out this simple issue, things got more interesting, especially since the error message also mentioned the “Invalid Token.” Let’s dive in!

Why the Device is Unjoined Post-Reseal

Before diving into the Token failure, let’s clarify why the device needs to join Entra again after finishing the Autopilot pre-provisioning process. It’s pretty simple: The device needs to join Entra again because before resealing, it got an Entra unjoin. Let me explain why the unjoin needed to happen.

Fake User Account (e.g., FooUser or Autopilot User):

During Autopilot pre-provisioning, the device uses the Autopilot@domainname fake user account to enroll in Entra. From then on, the device uses the FOOuser@domainname account to enroll in Intune. (The device needs to join Entra to enroll in Intune)

At this stage, the device is enrolled in Intune, but the actual user has not signed in, and the device’s identity is tied to the pre-provisioning session and with it tied to the foouser@ and autopilot@ user.

Unjoin Before Reseal:

Before the device is resealed, it must be unjoined from Microsoft Entra ID (Azure AD). This step clears the device’s association with Entra ID to prepare it for a clean Entra Join when the actual user signs in.
Conflicts could arise during the next enrollment if the device remains joined to Entra ID, as the device would still be tied to the pre-provisioning autopilot@ identity rather than the new user.

State After Reseal:

Once resealed, the device unjoins Microsoft Entra ID/Azure AD. Since it is no longer Entra Joined, it is also no longer associated with the temporary fake user.
This ensures the Entra Join / Azure Ad Join process occurs correctly when the actual user signs in, enabling the device to register with the correct user and policies.

For more context on what happens before the reseal, refer to my earlier blog on the Autopilot pre-provisioning process: FooUser Autopilot Pre-Provisioning Fake User.

Now that we know why the device needs to join Entra again after Autopilot pre-provisioning let’s return to the issue.

10-Minute Delay before the Invalid Token

After the device Autopilot for pre-provisioned deployment was finished, we booted up the device again. At this point, we needed to authenticate again to enroll the device in Entra, but this time with our own user credentials. After entering our credentials and waiting on the 10-minute delay, the Entra enrollment failed with the 801c03ed error.

Breaking Down the 10-Minute Delay

Besides the 801c03ed error code, it also told us that the token was invalid. At this stage, the device should have progressed toward Entra Join. Instead, users were stuck staring at the “Please wait while we set up your device” screen for 10 minutes, only to see the enrollment fail with the error code 801c03ed. With the enrollment failing, I started to wonder why….

The Entra Join Flow: What Should Happen

Let’s examine the technical architecture of what should happen during the Entra Join. By understanding the flow well, we can spot where it breaks in combination with the MDM Diagnostics Logs and Fiddler traces.

1. User Signs In:

The process begins when a user signs into the device with Microsoft Entra ID (Azure AD) credentials and retrieves the token for the device join.

2. Device Discovers Tenant:

The device queries the discovery endpoint to identify the associated Entra ID tenant.

3. Device Contacts DRS:

The Device Registration Service (DRS) returns the required tenant configuration and endpoints for the registration process.

4. Device Sends Registration Request:

A registration request is sent using a Transport Token to authenticate the device.

5. Transport Key Creation:

If required, the TPM generates a new Transport Key through the following steps:

Any existing Transport Keys are deleted.
Parameters for the new key are validated.
If an AIK Certificate is required, it is generated and validated alongside an attestation statement.
If the key creation fails, errors are logged, and the process exits.
A valid Transport Key is returned.

6. Transport Token Validation:

Azure AD validates the Transport Token and associated device details. (of course, in this example below, the token is invalid and showed us the 801c03ed and the Invalid Token error…which is NOT expected behavior!)

7. Azure AD Creates Device Object:

A new Device Object is created in Azure AD to represent the enrolled device.

8. Device Receives Registration Response:

The device receives enrollment data, including the Entra certificate and provisioning details.

9. Device Enrolled with Transport Key:

The device is successfully enrolled with the Transport Key and associated cryptographic key.

10. Device Obtains PRT:

The device obtains a Primary Refresh Token (PRT), enabling single sign-on (SSO) for Azure AD-integrated apps.

11. Device is Entra Joined:

The device completes the join process and is fully onboarded to Entra ID (Azure Ad Joined)

Fiddler Trace Analysis: Spotting the Issue

Looking at the Fiddler traces showed us a critical insight into the delay and failure. Let me explain first before looking at a nice flow again:

1. Token Expiration:

The bearer token sent to enterpriseregistration.windows.net for the enrollment request was identical to the one obtained earlier from login.microsoftonline.com. However, decoding the expires_on field revealed that the token had already expired when it was sent to Azure AD.

2. HTTP 400 Error:

The EnrollmentServer/device/Enroll endpoint responded with a 400 Bad Request, logging Invalid Token in its JSON response. This clearly indicated that the expired Transport Token had caused the enrollment to fail.

3. 10-Minute Delay:

Comparing the timestamps in Fiddler, we observed a gap of approximately 10 minutes between the token acquisition and its usage. This delay aligned with the logs showing stalled Transport Key creation tasks.

As shown above, the bearer token expiration highlighted the root cause: the request sent to the enterprise registration service was not completed in time. Something interfered with the TPM’s ability to complete its operations after resealing the device. But what? At this point, we suspected that some background process wasn’t running when it should have

ETL Logs Analysis: Diving Deeper into the Invalid Token

With the Fiddler trace showing the timeframe and pointing us toward a token issue, we opened the ETL trace that we got to find out more. When looking at the ETL trace with the Windows Performance Analyzer, we also noticed the 10-minute window.

Examining ETL traces provided further clarity on the 10-minute delay before sending out the domain join request:

1. Transport Key Deletion:

RegistrationController::DeleteTransportKey executed successfully, clearing the old transport key.

2. Transport Key Creation

The logs revealed repeated attempts to create a new Transport Key via RegistrationController::CreateTransportKey. However, the process only kicked off after 10 minutes.

This confirmed that some funny stuff was interfering with the TPM’s ability to complete its operations during the reseal phase—specifically, its ability to create the Transport Key. To understand the root cause, it was time to dig deeper into the dsreg.dll code and TPM task handling.

Dsreg.dll and the Entra Join

By analyzing the dsreg.dll code with the IDA tool, we started understanding the mechanics of Transport Key creation. Please believe me… this is something you don’t do for fun (well, I do.. but you get the point)

We started by looking at the Initialize Join Request function. This function is responsible for creating the certificate request and joining the device to Entra Join.

When looking closer at this function, we spotted the exact same steps as we noticed in the Fiddler trace, from finding discovery metadata (discovery URLs) to performing the actual join. While looking through the code, I noticed the one I was looking for.

As shown above, the Join request function also holds the CreateTransportKey function.. this is where it got interesting.

As shown above, the createtransport key also checks If an AIK Certificate is required. If the AIK is required, the function should trigger an API ( to kick off the AIKCertEnroll) to retrieve it. In this scenario, the delayed execution of dependent tasks disrupted the Transport Key creation, leaving the Autopilot enrollment flow stuck.

What Are the Transport Key (Token) and AIK Certificate?

To fully understand the issue and its impact, it’s pretty important to break down two key components in the Entra Join process: the Transport Key and the AIK Certificate. These play critical roles in securely establishing the device’s identity during enrollment.

1. Transport Key: The Backbone of Secure Communication

As we also noticed in the ETL trace and Fiddler output, the Transport Key is pretty important. This transport key is a cryptographic key pair generated by the TPM (Trusted Platform Module) that forms the backbone of device authentication. Here’s what it does:

Public Portion: The public part of the Transport Key is wrapped in a secure payload (the Transport Token) and sent to Azure AD as part of the device’s enrollment request. (what we also seen in the Fiddler trace)
Device Authentication: This key proves to Azure AD that the request originates from a legitimate and trusted device.
Expiration: If the Transport Token expires before validation, the device fails to join Entra ID. Timely creation and transmission of the key are critical.

2. AIK Certificate: Proving the Device’s Trustworthiness

The TPM issues the Attestation Identity Key (AIK) Certificate and attests to the device’s identity and integrity. Azure AD uses this certificate to validate the Transport Key.

Device Integrity: The AIK Certificate ensures the TPM is functioning correctly and has not been tampered with.
Validation Role: Azure AD cross-checks the AIK Certificate during the enrollment process to confirm that the Transport Key comes from a trusted source.
Dependent Tasks: The AIK Certificate generation often relies on TPM tasks like the Aikcertenroll scheduled task. Any delay in these tasks can disrupt the entire enrollment flow.

Why Are These Components Critical?

Failures in either the Transport Key creation or the AIK Certificate generation disrupt the Entra Join process. Without a valid Transport Key, Azure AD cannot authenticate the device. Without an AIK Certificate, the integrity of the Transport Key cannot be validated. And now you are thinking…. What on earth could possibly interfere with this process? Well, just hang on a bit… almost there!

The AikCertEnrolltask

The moment I spotted the AIK requirement… things started to make sense. Normally, a scheduled task should kick off these tasks, starting with the TPM maintenance task. As I pointed out in an older blog, this TPM maintenance task also kicks off the AikCertEnrolltask.

The AIK Cert enroll task! I kept an eye on those tasks while booting up after the device was sealed, but nothing happened with them! Even entering my credentials and waiting for 10 minutes before the 801c03ed showed up didn’t trigger those tasks.

Doing the same kind of enrollment but from a different (working) tenant showed me that Windows.Management.Service (Autopilot) kicked off those tasks, once the device boots up after it was pre-provisioned.

From there, I had a stupid idea: What if I just manually executed those tasks before entering my credentials? I reinstalled the device, pre-provisioned it with Autopilot, and sealed it.

After turning it on, I manually kicked off the TPM maintenance task… which took about 6 minutes to complete, which was pretty weird. From there on, I also executed the aikcertenrolltask to be sure the device got the AIK.

With the scheduled tasks completed successfully, I again entered my credentials. Instead of now staring at the please wait while setting up your device welcome screen, we were greeted with the Enrollment Status Page for a couple of seconds (Skipping the Account Setup) and the Windows Hello enrollment setup!

So, triggering the TPM Maintenance task (which also triggers the AikCertEnrollTask) seems to have triggered the Entra join to be successful by fetching the AIK on forehand.

The Culprit: Energy Saver Policy

After doing some more extensive testing and comparing the Autopilot Pre-Provisioning enrollment flow with a working one, it started to look like background tasks were queued somehow. We traced the issue back to a funny Energy Saver policy applied to the device during White Glove to ensure the devices were carbon neutral.

As shown above, setting these two settings to 100 will ensure the device is always in energy-saving mode. Guess what happens when a device is in energy-saving mode?

As shown above, Microsoft’s Energy Saver documentation highlights that task execution is restricted in this mode, which explains the behavior of the TPM-Maintenance task. Inside this TPM Maintenance task, we will spot the IdleSettings, which caused the issue.

Delayed TPM Tasks:

The policy delayed non-critical scheduled tasks, including the aikcertenroll and tpm-maintenance tasks, until the device exited Energy Saver mode.

Token Expiry / Invalid Token:

The resulting delay caused the Transport Token to expire before Azure AD could validate it. With the token expired we ended up with the 801c03ed error and the Invalid Token message.

The 801c03ed Fix: Adjusting the Policy

To resolve the issue, we implemented a simple change:

As shown above, reassigning the Energy Saver policy to users instead of devices ensured it didn’t affect the pre-provisioning stages.

Lessons Learned

Policy Impact:

Seemingly unrelated policies, like Energy Saver, can screw up your Autopilot Pre-Provisioning pretty good

2. Logs Are always important:

Use tools like Fiddler and ETL traces to find out why you got the 801c03ed / Invalid Token error.

3. Device Reseal State:

A resealed device is unjoined and highly dependent on TPM functionality. Ensure workflows account for this state.

4. Manual Intervention:

Temporarily triggering tasks manually can mitigate immediate issues during testing.

Wrapping Up

This case highlights how even minor policy changes can disrupt complex workflows like Entra Join. By understanding the flow, analyzing logs, and NOT enabling energy savers during Windows Autopilot for pre-provisioned deployments, you can avoid similar issues in the future.

Table of Contents