Last Updated on December 14, 2023 by rudyooms

In this blog post, I was asked by a fellow Dutchman (Jos Lieben) 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.

I will divide this blog into multiple parts:

1. Introduction
2. The 0xd000000d Error
3. AADBroker.Plugin
4. Fixing the AADBroker.Plugin
5. What happened?

1. Introduction

Jos Lieben who is also working in IT contacted me if I was interested in taking a quick look at a weird error they had while trying to enroll their devices into Intune.

After talking for a couple of minutes, it became clear that they wanted to migrate their devices from WorkSpace One (AirWatch) to Intune. Let me 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 into 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 manually enroll the already Entra 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 by using Teamviewer. After logging in, I decided to download the Intunesyncdebugtool to make sure all the MDM leftovers were removed.

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

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 0xd0000000d 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 be sure the logon provider and all the corresponding registry values were configured, I opened the registry and opened 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 looking at the same registry keys on his device, I didn’t detect any issue. From there on I decided to spend some time looking 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! Some time ago a nasty issue occurred in which some necessary system apps were malfunctioning.

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 with it, OneDrive couldn’t authenticate itself.

When spending some time at the appxdeployment event logs, I didn’t find anything weird in it, which was weird… everything finished successfully as it seems.

With the AAD.brokerplugin in a good healthy state, as it seemed, I wanted to remove some files from the AAD.BrokerPlugin folder to make sure the AAD.BrokerPlugin 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 our into 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 AAD.Broker, 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 triggering the Intune enrollment by using the deviceenroller.exe, the device immediately started the 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, the error 0xcaa10001 will be thrown at you and you will not be able to enroll the device into Intune and that is something we don’t want! So make sure you run this command from system and logged-in with 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 its packages folder

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

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 make sure there are no lingering tokens! Which is obvious but somehow that one caused the AAD.BrokerPlugin to be broken!

Conclusion

If you even come across the error 0xd0000000d, you now know what to do! Take a look at the AAD.BrokerPlugin and if it’s still on the device or not!