The 0xd000000d Job 2: Nutty by Intune

In this blog post, a fellow Dutchman (Jos Lieben) asked me if I could assist him with a weird error that occurred during the Intune/MDM enrollment. The first moment he mentioned the error 0xd000000d, I was interested, as I didn’t know what that error meant.

1. Introduction

Jos Lieben, who also works in IT, contacted me to see if I was interested in looking at a weird error they had while trying to enroll their devices into Intune.

After talking for a few minutes, it became clear that they wanted to migrate their devices from WorkSpace One (AirWatch) to Intune. Let me see where it all started first:

They did so by using these scripts provided by Steve (which are more focused on tenant-to-tenant migration)

GitHub – stevecapacity/IntuneMigration: Tenant to tenant Microsoft Intune device migration

In these scripts the device would unjoin Azure and all enrollments will be cleaned up, from there on it will use a provisioning package to enroll back into Azure, and with it, it should also enroll into Intune.

So far, so good. Their devices were Unenrolled, and successfully, Entra joined again in the same tenant. After logging in with a user licensed for Intune, they expected the device to start enrolling in Intune.

You can take a wild guess what happened, the device didn’t enroll into Intune. So the fellow Dutchman used a script that I published on my website to enroll the already Entra manually joined device into Intune

Enroll existing Azure Ad / Entra joined Devices into Intune (call4cloud.nl)

From there on, he contacted me.

2. The 0xd000000d error

I was able to remotely log in to one of the test devices using Teamviewer. After logging in, I decided to download the Intunesyncdebugtool to remove all the MDM leftovers.

Within a minute or 2, the tool exited with an error. The device wasn’t enrolled into Intune, and the required Intune MDM device certificate wasn’t received.

First, I checked if the device had a valid AzureAdPRT. As shown below, no problems here

While looking at the output of the dsregcmd command, I noticed the 0xd000000d error. This error was mentioned in the section: WamDefaultSet

When the DSREG tool needs to find the WamDefaultSet value, the tool will ask the Web Account Manager if it has a default sign-in account available for the current user who is logged in. When we have an ERROR in the output, it would mean that somehow the API failed to retrieve the settings or the user didn’t successfully authenticate to Azure Ad when signing in.

To ensure the login provider and all the corresponding registry values were configured, I opened the registry and the IdentityStore registry node. In a normal situation, it needs to look like this

(I didn’t take a screenshot of that particular setting on his device… sorry)

When I looked at the same registry keys on his device, I didn’t detect any issue. From there, I decided to look at some device management event logs. Luckily, all of them showed me the same 0xd0000000d error.

The funny thing is that during the Windows Hello enrollment, the same error popped up.

Luckily one of them showed me the culprit! Auto MDM Enroll Get AAD Token: Device Credential.

WAM and AADToken….

3. AAD.BrokerPlugin

When combining the WAM (Web Account Manager) with token errors, it became obvious where to start digging: the AAD.BrokerPlugin! A nasty issue occurred a while ago in which some necessary system apps malfunctioned.

Startmenu not responding | Broken Store Apps | 0xc000027b (call4cloud.nl)

In the blog above, I have also mentioned the fact that the AAD.BrokerPlugin was also having issues, and OneDrive couldn’t authenticate itself.

When I looked at the appx deployment event logs, I didn’t find anything weird, which was weird. Everything seemed to have finished successfully.

The AAD.brokerplugin seemed to be in a good, healthy state. I wanted to remove some files from the AAD.BrokerPlugin folder to ensure that it would try to fetch a new token after a reboot. To do so, I needed to delete some files from the settings.

C:\Users\username\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

I opened Explorer and browsed to the AppData\Local\Packages\ folder to look at the contents of the Microsoft.AAD.BrokerPlugin_ folder. I was like, uhhhh, what? Something quite important seems to be missing.

That’s not good! That AAD.BrokerPlugin needs to be in the user’s local AppData folder because if we enroll in Intune, the device will query this folder.

Guess what happens when the TokenBroker is not at home! The 0xd0000000d will be thrown at us!

4. Fixing the AAD.BrokerPlugin

One thing is for sure: we need to have a working Microsoft.AADBroker, if we don’t have one we are pretty much screwed.

Luckily, the simple fix was already in my possession.

$manifestpath = (get-appxpackage -Name "Microsoft.AAD.BrokerPlugin").InstallLocation + "\Appxmanifest.xml"; Add-AppxPackage -Register $manifestpath -DisableDevelopmentMode -ForceApplicationShutdown; get-appxpackage -Name "Microsoft.AAD.BrokerPlugin"

After entering this command, the dsregcmd output was also showing the WamDefaultSet being configured to yes!

With the WamDefaultSet configured and the Intune enrollment triggered using deviceenroller.exe, the device immediately started enrollment! Whoop!

I need to add a small note here because you will need to run the C:\Windows\system32\deviceenroller.exe /c /AutoEnrollMDM from the system command and you must be logged in once with the Azure Ad /Entra User. If you didn’t have logged in with a valid licensed AAD user you will end up with a new error.

As shown above, you will receive the error 0xcaa10001 and cannot enroll the device into Intune, which we don’t want! So ensure you run this command from the system and are logged in as an AAD user to receive the token!

5. What happened?

Now we had fixed the problem, I was curious about what could have caused this to happen. I decided to manually delete that Aad.brokerplugin from my test VM and after triggering the enrollment I noticed that a repair of the aad.brokerplugin was initialized and within a couple of seconds the AAD. BrokerPlugin arrived back in the user’s localappdata packages folder

Mmm, that’s weird… After talking a bit with my fellow Dutchman, we concluded that something in the script was deleting the AADbroker plugin folder from the user’s local app data.

We decided to take a closer look at the scripts he was using and within a couple of seconds of searching for “AAD.broker”, it showed us this.

As shown above, if we need to migrate our devices from Tenant A to Tenant B, we need to ensure no lingering tokens! This is obvious, but somehow, that one caused the AAD BrokerPlugin to be broken!

Conclusion

If you encounter wamdefault not set and the corrosponding error, you now know what to do! Check the AAD.BrokerPlugin and see if it’s still on the device.