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.
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. This issue caused the enrollment process to fail 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 UTC 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).
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.
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.
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.
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.
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.
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. UTC Fix
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!
After a couple of weeks, the status was changed, and it was now mentioning the fact that this issue was resolved in July 2024
Uhhh, that’s weird, as I didn’t notice any Intune Management Extension update coming down to my device. The Bootstrapperagentcore.dll still has the same version as before
Well, I guess it’s safe to assume that Microsoft fixed this issue on the service side without updating the IME! With Microsoft fixing this UTC issue, we can all start enrolling our non UTC devices.!
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!