In this blog, I will discuss how I found out a specific entra setting was interfering, AKA breaking my Windows Autopilot device preparation deployment. In addition to this bug, I will tease you about a new OOBE screen I noticed!
1. Introduction
The last few weeks have been all about Autopilot Device Preparation. If you missed that news, I guess you have some reading to do!
Autopilot Device Preparation | Technical Flow | APv2 (call4cloud.nl)
With Windows Autopilot Device preparation being released, Microsoft also added a link to the known issues list. This Known issue list mentions a known issue where a user could get to the desktop without the required applications installed.
This was a weird one because if you weren’t paying attention to the enrollment, you would end up with this screen mentioning that the required setup is complete.
Also, looking at the Autopilot Deployment Monitor, you wouldn’t notice anything weird… at first sight.
As shown above, it mentions that the agent installation is a success. If you don’t pay attention, you could miss the whole enrollment, which only took 4 minutes.
I guess it’s time to find out how we discovered this issue and the culprit. I will take you with me from the first steps to finding out what was causing it!
2. Deploying the Apps with Patch My PC
Before starting the Autopilot Device Preparation enrollment, I needed some apps to test with. To do so, I used Patch My PC. If you are cloud-native (only using Intune) and not already using Patch My PC, you want to check out the new Intune Apps for Cloud from Patch My PC.
Even though it does not have all the features (yet)we got with the Patch My Pc Publisher, this looks really really great.
Once I successfully onboarded my tenant to the Intune Apps by following this guide: Onboarding to Intune Apps | Getting Started (patchmypc.com), I needed to deploy some apps to my tenant.
Within just a couple of minutes, 7-zip was deployed to my tenant and from now on I can be pretty sure that it will be automatically kept up to date.
For the whole demo and how to deploy your first apps with the Intune Apps for Patch My PC, please take a look at this YouTube video
3. Configuring the Device Preparation Profile
After the apps are uploaded to my tenant and assigned to the proper just-in-time enrollment group, I need to define them as required apps in the Device Preparation profile.
As shown above, I added some apps. Now that the apps are configured in the Device Preparation profile, it is time to start the Autopilot Device Preparation enrollment.
4. Starting the Device Preparation Enrollment
With the apps configured as required and assigned to the just-in-time group, It was time to fire off the autopilot device preparation enrollment.
After installing the Intune management extension, it should start installing the required apps and scripts. At least, that’s what should have happened because this is what happened.
In the video, the device preparation enrollment moves from 7% to 100% in 1 second and ends with the message the required setup is complete.
One thing is for sure: This should not have happened and is unanticipated behavior. Let’s take another look at the device deployment monitor, but this time, we will click on it.
Within a few seconds, It became clear that no apps were installed, and only the agent (ime) was installed. So what happened?
5. What happened with the initialprovisioning
While reenrolling the device again, I made sure I got cmtrace up and running. Within a couple of seconds, it showed me something weird.
Within a few seconds (2) after the initial provisioning began, APv2 mode was successfully disabled. Well, that’s weird. That shouldn’t happen. I also tried to put the Intune Management Extension in verbose logging, but even that didn’t show me anything useful.
From there on, I decided to open the bootstrapper agent because it should show me something. When the IME is installed, it will register the bootstrapper event log provider. This event log provider should mention the steps the device preparation will take.
Somehow, the bootstrapper log provider was not active or doing its job at this point. My gut feeling was telling me that it should show something. I reinstalled the device but this time I changed a couple of things. Before enrollment, I manually recreated the Intune Management Extension Folder and put all files in a place that belonged to the bootstrapper to log provider. Once those files were in place, I manually registered the bootstrapper event provider using the wevtutil utility.
I started the device preparation enrollment with the bootstrapper event log provider manually registered. I guess I always need to trust my gut because this time, it showed me way more than the first time.
At 11:48:47, it started the standarduserprovider: execute provisioning call, but it seems it skipped it just two seconds later. At the same time, the enrollment moved to 100% completed.
I decided to open up the bootstrapper agent dll itself in IDA and dot-peek to find out what was happening. I usually start with IDA and start searching for keywords. The results will show me the function to look at. Depending on the dll type, I will stick with IDA or move to dotpeek. As this is a dot net dll, I moved to dotpeek.
Within a couple of seconds of browsing through the bootstrapper agent, I noticed this
LocalAdminGroupName and the UserSid. This brings back memories because some years ago, I wrote down the whole flow of how a user becomes a member of the local administrator group on a device.
Autopilot | Enrolled User | Standard vs Administrator (call4cloud.nl)
That got me thinking… Device Preparation should do the same, right? To be sure I was getting in the right direction, I decided to take a look at the device preparation profile
As shown above, my current profile shows that I am a standard user. Let’s change it to administrator instead to see what happens
After reinstalling the device and going through the same exact steps, it showed me a completely different flow!
It now proceeded with installing the apps and scripts! Cool, right? Let’s dive further
6. StandardUser Provider
With Autopilot v1, when the device is getting entra joined, depending on the returnclientsid, the user becomes an administrator or not. This flow is different with Autopilot Device Preparation. With Autopilot Device Preparation, the user will generally become an administrator and stay in the administrator group for a couple of minutes until the IME is installed.
With the IME installed, the device would begin the initial provisioning; one of the first steps Is launching the standarduserprovider. Let’s take a look at what happens when this standarduserprovider is being executed
For everyone who can’t read code:
The ExecuteAsync method takes a user ID from providerContext and tries to remove that user from the “Administrators” group on the local machine. If it succeeds, it saves the changes and logs the completion, returning ProvisioningComplete. If the user isn’t in the group, it logs this and returns Skipped. If an error occurs, it logs the error and returns ErrorOccurred.
If the user is not in the group, it will return skipped. Where did I see that before?
Oh yeah, that’s where I have seen it! Thanks.
I guess it’s pretty evident that something was happening with the administrator group and my user. Wait a second. Do you remember that fancy new entra setting that was finally put in production a couple of months ago?
7. The Fix and the root cause
After noticing how the standard provider did its job, I realized that new Entra settings could interfere with this process. With this setting, you could now define who is allowed to become an admin during the Entra join.
I assume that everyone changed that setting to none or selected after reading my blog about this.
Local Administrator Settings | Autopilot Profile | Entra (call4cloud.nl)
If that’s the case, you will run into the same issue as we did. Luckily, Microsoft added this bug to their list of known autopilot device preparation issues
So, if you are using autopilot device preparation, we need to change that setting again to ALL until MSFT comes up with a resolution. Selecting that setting to NONE or Selected will break the whole enrollment!!! Make sure you set it to All
8. What’s Next?
After identifying the culprit and providing feedback to MSFT, I changed the Entra setting back to administrator for now and started testing a bit more.
Something unexpected happened after my device installed all the required apps and finished the enrollment.
Somehow, the Application report in the Autopilot Device Preparation Monitor was showing me that the status of all of the win32apps was showing ” In Progress”
If you want to know more about this Autopilot Device Preparation issue, please register for the Patch My PC Patch Tuesday webinar. From there on, watch for the corresponding Patch My PC blog about how to troubleshoot Autopilot Device Preparation issues!
Conclusion:
Hopefully, this blog showed you how I stumbled upon the Entra Bug. After this blog, I will start writing an Autopilot Device Preparation blog, which could be useful in the future! Oh, and do you like the new Windows Update Experience? Well, I did 🙂