Setting up devices using Windows Autopilot Device Preparation should be straightforward. To do so, we need to configure the policy, assign apps and scripts, and let the Windows Autopilot handle the rest. Whether a user should be a Standard User or an Administrator is just another setting in the Autopilot profile. But what happens when that setting is ignored?
What if Autopilot Device Preparation finishes, yet the user remains an Administrator? That’s exactly what happened in this case, and finding out why led to an unexpected discovery.
Autopilot Device Preparation and the Account Type
Autopilot Device Preparation is the perfect solution to streamline your Entra and Intune enrollment during the OOBE process, ensuring that all policies and required applications are deployed to the device. With a Device Preparation policy, we can define up to 10 apps and 10 scripts to be deployed automatically. Additionally, we can configure whether the user should be assigned as a local administrator or a standard user.
But what if that doesn’t work? Everything worked as expected on an EN-US Windows build. However, on a German Windows build, the enrolled user remained an administrator after provisioning despite the Device Preparation profile being correctly configured.
The Issue: Standard User Configuration Didn’t Apply
This was unexpected. The device had gone through the full Autopilot Device Preparation process, yet the user still had administrative privileges. As shown below, the user was still a member of the “administratoren” group.
First Assumption: The UTC Timing Issue
Given my experience with Autopilot timing issues, I suspected UTC-related problems. If tasks run at unexpected times due to time zone misalignment, certain provisioning steps could fail silently (as detailed in this blog: https://call4cloud.nl/autopilot-device-preparation-utc-issue/).
I tested this theory by adjusting the device’s UTC settings, manually forcing time synchronization, and ensuring all timestamps aligned. The result? No change. The user was still an Administrator. Time to move on.
Second Assumption: The Entra Administrator Group Issue
Next, I suspected that the Entra local administrator assignment was interfering. Autopilot DPP-enrolled devices did have some issues with this new Administrator setting in Entra.
As covered in this blog: So, I decided to check the Entra settings to be sure it wasn’t the culprit.
But that wasn’t it either. Autopilot Device Preparation was completed successfully, and there were no conflicting Entra policies assigning admin rights. The issue had to be elsewhere.
Debugging with the Bootstrapper Agent Log Provider
Since the issue wasn’t related to UTC or Entra admin assignments, I copied the necessary bootstrapper files from an already enrolled device from the to-be-enrolled device. With the folder and four required bootstrapper files in place, I enabled the Bootstrapper Agent Log Provider using Wevtutil and monitored the provisioning process.
During deployment, I opened the BootStrapperAgent Event log, which now could hold more information because the event provider was already registered before enrollment.
With the event log in place before enrollment, I checked the execution of StandardUserProvider, which is responsible for removing the user from the Administrators group. That’s when I noticed this important message in the event log.
StandardUserProvider: Skipped
StandardUserProvider was skipped entirely. This explained why the user was never removed from the Administrators group. But why?
Digging through the Bootstrapper agent code
I opened the dot-peek tool and opened the bootstrapper agent dll file. With the bootstrapperagentcore.dll opened, I unfolded the standarduserprovider context
After analyzing the decompiled BootstrapperAgent code, the issue became clear. The code suggested five possibilities for why the standarduserprovider could be skipped.
(flight 7274 sounds interesting and deserves an additional blog)
Flighting Feature ID 7274 is Disabled
Provider Context is Null (Fails Initial Validation)
The user is Not in the Administrators Group
Invalid User SID Format
GroupHelper Fails to Remove User from Group
After looking at the possibilities, one of them stood out
The StandardUserProvider uses this logic to find the Administrators group: using (GroupPrincipal byIdentity = GroupPrincipal.FindByIdentity(context, “Administrators”));
When we use PowerShell to execute that same function, it ends up with no results on a German Windows OS (even when the administrators group contained the logged-in user).
When using that same code on a German device and a different working en-us Windows VM…..this is what it showed me!
As shown above… the left is the German one, and the right is the EN-US one. Shall I let you in on a secret?
Why the User Stayed an Administrator
This FindbyIdentity Function works on en-US OS builds but fails on a Windows device installed with the german language. Why? In the German language, the group is named “Administratoren” instead of “Administrators.”
Because the method was hardcoded to look for “Administrators”, it never found the group, and StandardUserProvider skipped execution. If we change the Samaccountname of the group to Administratoren, guess what it shows us?
This means the user was never removed from the Administrators group during Autopilot Device Preparation.
The Fix: They should use the Well-Known SID
Instead of relying on localized group names, the correct approach is to use the well-known SID for the Administrators group (S-1-5-32-544), which remains the same across all languages. The correct implementation should be: using (GroupPrincipal byIdentity = GroupPrincipal.FindByIdentity(context, IdentityType.Sid, “S-1-5-32-544”));
By using the SID instead of the hardcoded name, the group lookup works across all language versions, ensuring that StandardUserProvider executes correctly and removes the user from the Administrators group, no matter what language the OS is set to.
Looking back, this is not the first time, Microsoft seems to have made this mistake. With releasing the 23h2 security baseline, they also managed to break some stuff on non-english builds.
Microsoft Reference: IT773677
Conclusion: Localization Can Break Device Preparation
This issue highlights a critical flaw in using hardcoded names for system groups—localization can cause failures that don’t exist on en-US builds. If you’re troubleshooting Autopilot Device Preparation and find that a user remains an Administrator, check for:
1. Time synchronization issues (UTC problems)
2. Unexpected Entra admin assignments
3. StandardUserProvider skipping execution due to localization issues
The fix is simple: always use the well-known SID for system groups. Otherwise, the user won’t be removed from the administrator’s group when it is required.
If you want to know more about troubleshooting Autopilot Device Preparation, please read this blog: