[New post] Autopilot White Glove and the lost Azure Ad Join
Rudy Ooms posted: "A quick blog but about a weird issue we encountered today. This blog will be about an Autopilot White Gloved device that ended up in Intune but without an Azure Ad Join even while it showed us a nice green screen before sealing it!I will divide this blog "
A quick blog but about a weird issue we encountered today. This blog will be about an Autopilot White Gloved device that ended up in Intune but without an Azure Ad Join even while it showed us a nice green screen before sealing it!
When a customer orders a new device, we are making sure we wipe it first and reinstall it with the latest Windows 10 build. While doing so we are also checking if everything is good to go before we start the white glove. As an example, we need to determine if key attestation is possible.
As we all know, TPM attestation is required when you want to perform a white glove. Also beware, when you have a tiger lake chipset, you will need to use 21h2. But none of the normal issues that could occur during the white glove was noticed.
First I need to show you what the exact issue was, I was trying to solve. Take a look at this nice Windows Login Screen.
The only option we had, was logging in with the local admin account that was created during the white glove?
That's odd because normally you end up with a nice login screen to log in as a user from your company but this time…. Not! So no Azure Ad login possibility on the device for us.
First, let's check out if the device ended up in the Azure Ad portal.
Okay…? So Azure and Intune are detecting the device as Azure Ad joined? As the device is not used, we can just send a remove command to perform an Autopilot reset.
If you want to know more about all the possible options you have to start wiping your device please visit this blog
But even after an Autopilot reset, the device still ended up with only the local admin on the login screen. Let's dig a little bit deeper.
Again we opened the Intune portal to check out the last time it contacted Intune. As shown below… the device last contacted Intune, while we were trying to solve the issue.
But still, it wasn't azure adjoined? What happened. It's a good thing we have an additional local admin with LAPS implemented. I guess the first thing you need to do, when you need to start troubleshooting an Azure Ad join failure would be DSREGCMD /status. So we did!
Okay… The device isn't Azure Ad joined even while Azure and Intune think differently. And no, trying to enrol the device with the /Join switch isn't going to work!
Before I wanted to try to enrol the device into Azure, I needed to know if Intune was working. The first thing I wanted to know was if the Intune MDM device ca is present and if the Intune Management Extension service was running.
As shown below the CA certificate was present, like expected on a working Intune device. If you want to read about my experience with an invalid certificate please read my blog about it.
Now, let's check it out if the Certificate is present.
As shown above, it was present and still valid for about a year and even the Intune service was running like expected…. We even could force a sync from the Intune Management Portal?
So the issue is totally Azure Ad related and nothing more. Of course, we checked out the Settings page to determine if there was a school or work account attached. But I guess you already know the outcome. No account was configured
So the AAD event log should be your next step to investigate.
We were only noticing one error… and nothing more… Try to google the error "AAd Cloud AP plugin call GenericCallPkg returned error" and 0xc0048512. You will notice there is no information about what the error means.
Of course, when you are not blocking enrollment of personal devices and don't have conditional access for requiring compliant devices configured you could do it manually but this time I wanted to know if I could do the same with the AAdinternals module. So I installed the module and tried to Join it
No weird, red errors… but the device was still not Azure Ad joined..(rebooting also didn't helped) Okay, screw it… I can't find any errors which could point me to the real problem, so let's fix it.
We changed the possibility to enrol private-owned devices to Allow… because we normally restrict it…
Now, let's join the device manually. Maybe a new nice error could pop up?
Duh… Of course, the device was already present in Azure ad and we got the 8018000a error.
So we removed the device in Azure… And now I need to repeat myself, we removed the device in azure.
Did you ever tried to remove an autopilot device in Azure? You will be prompted with a notification you can't delete a windows autopilot device here.
Another funny fact, normally you only have 1 device in your Azure portal with a nice autopilot icon attached to it
But this time we noticed another exact same device but with a normal icon? Maybe it was because we tried the AADInternal solution first? I am not sure but we choose to remove the device to see what happened.
After the device was removed in the Azure Portal and only the Autopilot device was present we tried to perform a manually Azure Ad join again. Within a few minutes, the device was Azure Ad joined and also dsregcmd /status finally showed us, it was AzureAdjoined
And pretty please with sugar on top… don't forget to block the intune enrollment of personal devices again.
I still don't know what happened…. I guess that's the conclusion and nothing more… I'm done
But luckily the customer can start working now and that is also very important.
If you want to know more about all the possible options you have to start wiping your device please visit this blog
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.