This blog will show you how you could make sure, your existing Azure Ad Joined devices (Devices that are not yet enrolled into MDM / Intune) are going to be automatically enrolled into Intune.

I will divide this blog into multiple parts

1. The issue
2. Solving it
3. The Results
4. Troubleshooting the Enrollment

1. The Issue

A lot of customers will start their cloud journey by making use of Azure Ad as their Identity Provider. Most of the time, Intune wasn’t yet part of that journey. But what if you want to make sure your devices are being managed and the devices are already enrolled into azure but not into Intune?

Today I spend some time enrolling existing Azure Ad joined devices into Intune. These devices were Azure Ad joined butt without MDM/Intune enabled or configured.

This company started off with only Microsoft 365 Business standard licenses. We all know that this license type is missing the possibility to enroll the devices into Intune.

2. Solving it

When you want to enroll your existing Azure Ad joined device into Intune, there are multiple options available to make sure the device will be enrolled into MDM/Intune. Of course, when enrolling an existing Azure Ad Joined device into Intune there is 1 major requirement. You will need to have the right privileges (local administrator) to perform that operation! Otherwise, you will end up with some nice errors

If the permissions aren’t going to be an issue we still need to check out some other settings. To make sure users could enroll their device we need to configure the MDM scope in Intune. As shown below we made sure only users with a proper license (Business Premium) could enroll their device into MDM.

Please note: Before enrolling the device, also make sure there are no enrollment restrictions(Block Personal Devices) configured!

If we have the prerequisites configured we could start enrolling the device into MDM/Intune. To do so we have multiple options at our disposal.

Option 1: Group Policy:  

You can open the group policy object editor and browse to

Computer Configuration > Administrative Templates > Windows Components > MDM.

And configure this setting like the picture below:

*Enable: “Automatic MDM enrollment using default Azure credentials“

*Credential Type to use: User credentials

Option 2. Registry:

Instead of changing a GPO setting, we could also change the corresponding registry setting ourselves. So just import this reg file with the required enrollment information in it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM]
"AutoEnrollMDM"=dword:00000001
"UseAADCredentialType"=dword:00000001

It does the same as the GPO as a GPO is nothing more than a bunch of registry changes… 🙂

Option 3. PowerShell

And of course, you could also just deploy this PowerShell script to your devices to make sure the device will start enrolling into MDM/Intune/Endpoint Manager

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM"
New-Item -Path $registryPath

$Name = "AutoEnrollMDM"
$Name2 = "UseAADCredentialType"
$value = "1"


new-ItemProperty -Path $registryPath -Name $name -Value $value -PropertyType DWORD -Force | Out-Null
new-ItemProperty -Path $registryPath -Name $name2 -Value $value -PropertyType DWORD -Force | Out-Null

3. Results:

When you applied one of these options I described above, you will notice a new Task will be created in the task scheduler. A new nice Category: EnterpriseMgmt will be created with a task named: “schedule created by enrollment client for automatically enrolling in MDM from AAD” in it. This task runs every 5 minutes for a duration of 1 day and has the arguments /c /AutoEnrollMDMUsingAADUserCredential

Give it some time because sometimes it could really take long before the device will be enrolled into Intune successfully. In the meantime, you could notice the error Auto MDM Enroll: Failed 0x8018002b (event 76) popping up in the DeviceManagement-Enterprise-Diagnostic event log.

Sometimes it could take over more than a few hours, also putting the device to sleep or logging out the user will keep you waiting. After some time of waiting you will notice the event 75 with the message that Auto MDM Enroll: Succeeded

4. Troubleshooting the Enrollment

When you don’t want to wait until you are an old person, and you want to speed it up.

Please enforce enrollment by running this command:

C:\Windows\system32\deviceenroller.exe /c /AutoEnrollMDM

But unfortunately, sometimes running this command isn’t helping. When it isn’t helping, there could still be some leftovers in the registry and you could end up with the famous error: “Your device is already managed by your organization”

I will divide this part into multiple subparts!

The first part will show you how to fix the enrollment when it was MAM enrolled instead of MDM enrolled.

The second part will show you how to fix the error 80190026 when a device was previously enrolled with SCCM

The third part will show you how to fix the 0x80180026 error when the scheduled task is executed

The fourth part will show you how to fix the 0x8018002a error when the scheduled task is executed

The fifth part will show you how to fix the MDM enrollment when everything else fails!

4.1 MAM Instead of MDM

When your device was previously enrolled with MAM instead of MDM, you could clean up the registry first and run the deviceenroller.exe afterward.

$EnrollmentsPath = "HKLM:\SOFTWARE\Microsoft\Enrollments\"
 
$Enrollments = Get-ChildItem -Path $EnrollmentsPath
  
$DiscoveryServerFullUrls = @("https://wip.mam.manage.microsoft.com/Enroll")
 
Foreach ($Enrollment in $Enrollments) {
      $EnrollmentObject = Get-ItemProperty Registry::$Enrollment
      if ($EnrollmentObject."DiscoveryServiceFullURL" -in $DiscoveryServerFullUrls ) {
            $EnrollmentPath = $EnrollmentsPath + $EnrollmentObject."PSChildName"
            Remove-Item -Path $EnrollmentPath -Recurse
            &  "C:\Windows\System32\deviceenroller.exe /c /AutoEnrollMDM"
      }
}

4.2 Previously SCCM Enrolled

When you have a device that was previously enrolled SCCM you could end up with a situation where there is still one lingering registry key that could block the enrollment. When that specific key is stuck, you will end up with the error 80190026 and of course, as always the message indicating that something went wrong!

Open the registry and open this key: SOFTWARE\Microsoft\Enrollments

Please make sure the “ExternallyManaged” key doesn’t exist or is configured to zero and NOT to 1 as shown above!

4.3 Fixing the 0x80180026 Error

Most of the time this nice 0x80180026 error is only occurring at HAADJ devices. As shown below, it will show you the error that it failed to enrolled with RegisterDeviceWIthManagementUsingAADDeviceCredentials

This error can be resolved easily by making sure the “Disable MDM Enrollment” is not preventing your MDM Enrollment. I guess the name says it all

4.4 Fixing the 0x8018002a Error

As shown below, when trying to enroll your existing Azure Ad Joined device into Intune you could end up with the 0x8018002a Error.

This error is probably due to some Conditional Access rules you configured to make sure MFA is always required.

As shown above, this Conditional Access rule is targeted at “All Cloud Apps”. When we fix this error, we need to make sure we EXCLUDE the “Microsoft Intune Enrollment” Cloud app.

4.5 If everything else fails

And if that ain’t working…. please take a look at part 2 of this blog below… It will remove all the existing enrollments, device Intune certificates, and tasks. When everything is removed it will try to enroll into Intune again

Alice and the Intune MDM Device Certificate

Conclusion:

When your devices are already enrolled in Azure Ad, it doesn’t mean you will need to reinstall the devices to make sure those devices are enrolled into Intune/MDM. Sometimes enrolling a device into Intune sounds easier than it is… hopefully the troubleshooting part showed you how to deal with those kinds of situations!

Please Note: Wiping the device and enrolling it with Autopilot is the path you will need to take… but sometimes that path isn’t always available!