Die Hard with a UTC: Fixing Autopilot Device Preparation

Last Updated on July 9, 2024 by rudyooms

Enrolling devices into Windows Autopilot Device Preparation should be straightforward, but sometimes unexpected issues require a deeper dive into the core DLLs. Recently, I encountered a problem that caused device enrollment to fail when devices were configured with non-UTC time zones. This blog post details the issue, the investigation process, and a practical workaround until an official fix is available.

I will divide this blog into multiple parts.

  1. Introduction
  2. The Problem
  3. The BootStrapper agent
  4. EmitProgress/ConverToWinrt
  5. Solution
  6. Microsoft?

1. Introduction

Enrolling devices into Windows Autopilot Device Preparation should be a streamlined process to simplify device provisioning for end users. However, I encountered a peculiar issue where the enrollment process failed on devices configured with non-UTC time zones. This blog post outlines the problem, my steps to diagnose it, and a simple solution until Microsoft fixes it.

2. The Problem

Last week, I noticed a question popping up on Reddit. The OP mentioned how their device constantly failed the Autopilot Device Preparation Enrollment, no matter what they did or changed. They always received the message “Something Went Wrong” (but then in German).

A screenshot of a computer

Description automatically generated

After ensuring the Enrollment Time Group was configured correctly in the APv2 Profile and had the proper owner, things started to get weird. Even while all off the Win32apps were installed on the device, it still waited for the timeout to show the “Something Went Wrong” screen. After digging through the MDM logs and confirming that the IME log didn’t mention anything unusual, I decided to take a look at the Bootstrapper log.

3. The BootStrapper Agent

The bootstrapper agent is one of the most critical components of Autopilot Device Preparation. It is part of the Intune Management Extension(IME), which Microsoft can update much easier and faster than waiting for the regular Windows update. After opening the bootstrapper log, I immediately noticed that something was breaking apart while the bootstrapper was emitting progress.

The first log mentioned that the Bootstrapper agent was reporting a new state. This new state shows the progress of the Win32 app installations.

A screen shot of a computer

Description automatically generated

The bootstrapper should have reported the status of the batch workloads to the service, but somehow, it failed to do so with the German build.

A screenshot of a computer

Description automatically generated

Here is the translated German error message:

System.ArgumentOutOfRangeException: The UTC time represented when the offset is applied must be between year 0 and 10000.

This error suggests that the processed DateTime value was outside the valid range for DateTime in .NET. To understand the root cause, I decompiled the Microsoft.Management.Services.BootstrapperAgentCore.dll using the JetBrains decompiler. My investigation focused on two main areas: the EmitProgress method and the DeploymentWorkloadConverter class, specifically how they handle DateTime.

4. EmitProgress and ConvertToWinRT

EmitProgress Method

The BootstrapperAgent class’s EmitProgress method reports the batch workload deployment progress during the device enrollment process. This process relies on the DeploymentWorkloadConverter class to convert DeploymentWorkloadDto objects into DeploymentWorkload objects.

A screenshot of a computer program

Description automatically generated

DeploymentWorkloadConverter Class

The DeploymentWorkloadConverter ensures that deployment Workloads are compatible with the WinRT API. This conversion is crucial for consistent and interoperable reporting and handling of deployment workloads. The ConvertWinRT process ensures that date and time values are correctly handled in UTC, essential for accurate progress reporting and logging within the EmitProgress method.

A screenshot of a computer code

Description automatically generated

Proper handling of DateTime values in UTC by the DeploymentWorkloadConverter ensures that the EmitProgress method operates smoothly, preventing errors and providing reliable progress updates during device enrollment.

After spending more time on it, it seemed that the ConvertToWinRT process could not handle the time/date correctly when it was not set to UTC.

With this information, I decided to retry the enrollment, but this time in several different languages, such as Dutch and Spanish. Guess the outcome!

5. Solution

I decided to start over, but this time, I needed to ensure that the device operated in UTC. I could do so by manually opening the settings and changing my UTC +1:00 to UTC.

Besides manually changing the device to UTC, we could also use PowerShell. With Powershell, we can set the system time zone to UTC on my device that was installed with the German language:

Set-TimeZone -Id “UTC”

This command configures the system to use Coordinated Universal Time, avoiding issues related to local time zone differences. With this simple change, the device was now able to enroll successfully.

A screen shot of a computer

Description automatically generated

This indicates a significant issue because every device that did not use the UTC would fail. It feels like a massive issue if you ask me!

6. Microsoft

When I spotted this issue, I immediately reported it to the Autopilot/Enrollment team. This is what happened:

Windows Autopilot device preparation known issues | Microsoft Learn

Microsoft updated the Windows Autopilot Device Preparation known issues list and added the UTC time zone issue!

I will update this part of the blog as I stumble upon new information. Luckily, the power of this process lies in the bootstrapper agent, which is part of the IME and can be updated quickly. With that power, I hope Microsoft can fix the UTC fix issue in the code very soon.

Conclusion

Hopefully, Microsoft will fix this UTC issue as soon as possible. It’s great that the Bootstrapper holds all of the Autopilot Device Preparation Power to fix it on the fly. In the meantime, if you want to use a different language and it does not use UTC time, changing it to UTC before enrollment is your workaround!

Leave a Reply

Your email address will not be published. Required fields are marked *

6  +  1  =