This blog focuses on Windows Autopilot, specifically taking a closer look at the ‘Allow Autopilot Pre-Provisioning‘ option in your Windows Autopilot profile. We’ll explore how this setting could trigger the 0x80180005 error during enrollment
1. Introduction
Today, a colleague tried to enroll a new device in a tenant we took over with. We couldn’t finish MDM enrollment 0x80180005. 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 the blog below, but I guess I need to give you a small summary before we can take a closer look at it.
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 block the possibility of using Autopilot pre-provisioning by flipping this switch and trying 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 with the enrollment for now.
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 two 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 WhiteGlove.
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.
6. The MS365 Admin Center
When looking back at people who ran into this issue, most of them had pre-provisioning disabled except a few others. Let me tell you what happened to those others. The moment you upload the hash from the MS365 admin center instead of Intune and assign the device the profile, the whole white-glove option is missing.
Guess what happens the moment you upload the device from the ms365 admin center and change the white glove option in the Autopilot profile that has been assigned to it?
During the autopilot enrollment, you will get the same error, and in the event log, you could notice this error: The ZTD profile was not assigned to the ZTD device. This confirms that it has been recognized as an autopilot device, but somehow, there was a mismatch in the profile the device should get.
With the profile not assigned to the device, the mdmenrolling step will finish unsuccessfully with the error 0x80180005
Conclusion
You might think 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.