This blog will again be about Autopilot, but this time, it will not be a deep dive into Autopilot itself but more of an “un petit peu” deep dive into the “allow Autopilot Pre-Provisioning option” in your Autopilot Profile.
1. Introduction
Today, a colleague tried to enroll a new device in a tenant we took over with Autopilot Pre-Provisioning. This shouldn’t be an issue in a normal situation, but this time, he stumbled upon the well-known 0x80180005 error you could get at registering your device for mobile management enrollment status page step.
After a couple of seconds, a nice red error page was shown with the same error in it and mentioned, “We couldn’t finish MDM enrollment” Error 0x80180005
We all know by now that this error is caused by a setting in your Windows Autopilot Profile. That setting would be the “Allow pre-provisioned deployment” that has been set to “NO”
As shown above and also as shown below, with this setting being set to “NO” (blocked) we will end up with that same error message 0x80180005
As we took over the tenant, we somehow forgot to change this setting. An easy fix you could say! After changing the settings to yes, the device almost immediately continued enrollment. We didn’t need to reboot or download the Autopilot profile again.
At that exact moment, that same colleague asked me a question: Could I explain how a device is allowed to be pre-provisioned with that setting enabled? I was speechless.
2. When it works
Before we examine the details and the real flow, let me explain what happens from a broader perspective when pre-provisioning your Autopilot device.
I am explaining this whole flow in this blog below but I guess I need to give you a small summary before we can take a closer look at the flow
FooUser meets the Cosmic Autopilot@ user – Call4Cloud
After pressing the windows logo 5 times, the device would start downloading the Autopilot profile. With the Autopilot profile in possession, we could start the Autopilot pre-provisioning. At that moment, the device would perform the TPM attestation to enroll the device into Azure.
The device will be Azure ad Joined with the autopilot@domainname account
After the device is enrolled into Azure Ad, it will try to enroll itself into Intune/MDM by using the “FakeUserEmail” foouser@ account to fetch the discovery service URLs
If the device is enrolled into Intune, it will ditch the Azure Ad Join and continue to the next steps in the Enrollment status page, and after a while, your device should be pre-provisioned with Autopilot
3. When it doesn’t work
Now we know what should happen when pre-provisioning your device with Autopilot, we need to take a look at some details when it doesn’t work.
When you are blocking the possibility to use Autopilot pre-provisioning by flipping this switch and try to use pre-provisioning the device will still be able to start the enrollment.
As mentioned before, the device downloads the Autopilot profile before you can start the real enrollment. Maybe you have the idea that when downloading the Autopilot Profile, it tells the device to block the Pre-provisioning because that setting is configured in your Autopilot profile, right?
I guess I have some bad news!
That isn’t true! Looking at the Autopilot profile itself, we couldn’t spot that “Allow Pre-provisioned deployment” setting in it.
The only settings that we could spot are the “CloudAssignedOobeConfig”. This property is a bitmap that shows which Autopilot settings were configured.
So maybe it is somewhere hidden in the CloudAssignedOobeConfig? When taking a closer look and converting that 286 number we noticed in the Autopilot profile, this is what we would get.
As shown above, again, that Allow Pre-Provisioning or White glove is nowhere to be found. Okay, that’s weird, how else does the device know it is allowed to be enrolled with Autopilot pre-provisioning? Let’s continue for now with the enrollment.
If you have started the pre-provisioning, the device will enroll in Azure Ad by relying on TPM attestation. As shown below, at the moment the device would start enrolling itself into MDM, the device will be Azure Ad Joined but is missing its MDM URLs
Let me give you a small summary.
With the allow pre-provisioned deployment set to no, we will still be able to
-Downloading the Autopilot profile and start the Autopilot Pre-Provisioning
-The TPM attestation would start, and your device would still get Azure ad Joined
When looking at the ETL trace at that point, we will indeed notice the same behavior
For now, let’s assume that the “Allow pre-provisioned deployment” doesn’t block the “Join” but blocks the MDM enrollment. By the looks of it, it happens service-side as the setting isn’t in the Autopilot Profile…. With all the assuming we did, let’s try to find proof for it.
4. The details
As we noticed in the last part, it’s all about MDM enrollment. When in doubt, open your favorite technical document. I opened the MS-MDE one and started looking for answers.
Even when Microsoft renamed White Glove to Pre-Provisioning, that name still exists everywhere. I opened the technical document and started searching for WhiteGlove instead.
That’s weird, as I was expecting some results when searching for WhiteGlove. I guess that was a bit of an “oopsie,” as there are, of course, 2 versions, and I needed to open the second version.
MS-MDE2 indeed showed me some more results!
When searching through the correct MS-MDE technical document, guess what I spotted
The context items “ZeroTouchProvisoning” and “WhiteGlove” mentioned above were in the “RequestSecurityToken” examples.
That one sounds familiar, right? In one of my latest blogs, I also mentioned using this token to fetch the Autopilot Profile.
The Token Games: The Ballad of Autopilot and Profiles – Call4Cloud
When scrolling and reading through that document, trying to find out more, I stumbled upon this sentence: be a boolean value that indicates whether the device is in “WhiteGlove” mode.
That sounds exactly like what I was looking for! So, when a device reaches out to the Intune service after being Azure Ad Joined, it will request the security token. This request will define whether the device is a White Glove device.
With this information, the Intune service would determine if the device is a white glove device. This information will be compared with the information Intune has by looking at the Autopilot profile (that has been assigned to the device)
If the pre-provisioning setting was set to NO in that assigned Autopilot profile, the Intune service would reject the Intune enrollment triggered by the fake FOOUser.
5. Checking it in real life
Before starting the enrollment, I installed Fiddler and configured the required settings. After the TPM attestation, the device would indeed start the MDM enrollment and would reach out to manage.microsoft.com
Now we know where to look, I unfolded the “RequestSecurityToken” and immediately spotted the “WhiteGlove” and ZeroTouchProvisioning” context items. Besides these 2 context items, it also contains the HWDevID. By passing along this Device ID, the Intune service could query if that device has an Autopilot profile attached and if it is allowed to perform the White-Glove
When combining this information with this information from the trace, we now know for sure that the Intune Service has its “Firewall service” enabled and is blocking the Intune Enrollment from the device if it doesn’t have the WhiteGlove configured to “TRUE”
As shown above, when looking back at the ETL trace, we could also spot the fact that the Zero touch Profile VALIDATION failed because WhiteGlove is disabled for that specific device
Conclusion
You could have the idea that configuring the “allow pre-provisioning” setting to no would prevent Pre-provisioning, but that’s not the case!
It “only” blocks the MDM enrollment. Guess what happens when the Intune service is blocking the MDM Enrollment because your device told the service it is a “whiteglove” device while that “allow” setting is configured to NO
The MDM enrollment would fail, and with it, your Autopilot pre-provisioning. Isn’t that just delightful?
Nicely done, but I am a bit confused. Are you saying “Allow pre-provisioned deployment” should be set to No?
i have it set to NO, but I still, I sometimes see this error, but only on devices already in intune. When we reset those devices and try to use to later, it will give that error. The only option we have been using to fix it is to delete the device and import the hash again.
If you want to use whiteglove/prepro that option should be configured to yes
Microsoft at its best… they would get the general idea right. Implement it badly, then leave things to the general public to troubleshoot. Then there will be the 1% like the writer of the article who explains things to them, and they’ll gradually improve it in the next 5 years. (from 35% viable to about 70%) only to replace it with the ‘next gen’ thing again at 35% and it’s a cycle…..
Now the question is – with the preview version of “Autopilot self deploying mode” where the option to allow pre-provisioned deployment is set to No. How would it work? In fact I’m here because I’m in a situation where as it doesn’t work.