There never seems to be a shortage of issues when dealing with Hybrid Azure AD Joined + Intune Enrolling endpoints. Especially when you inherit a setup and have no history of what was implemented in the past. I encountered a new issue the other day and figured I’d made a quick post. In this situation, it was a smaller organization with around 60 devices. After configuring AD Connect and the GPO to auto enroll the endpoints, we only had around 12 devices enrolled in Intune after a few days. Most of the devices Hybrid Joined properly, but the Intune enrollment piece was failing.
Devices were Hybrid joining properly, and dsregcmd /status confirmed that. So, I turned my attention to the enrollment logs, scheduled tasks, and registry entries for device enrollment. If you work in HAADJ Intune environments often (and unfortunately, I do), I suggest you read this Enroll a Windows 10 device automatically using Group Policy – Windows Client Management | Microsoft Learn.
Right away I found some errors and interesting entries in the Device Management Admin log:
Manually running %windir%\system32\deviceenroller.exe /c /AutoEnrollMDM shows this in event logs:
And
And this, which indicates the device is already enrolled (Diagnose MDM enrollment failures – Windows Client Management | Microsoft Learn).
Next, I checked the scheduled tasks. I knew something was up here, because this was created well before the auto enroll GPO was implemented.
Looking at that Enrollments ID (the folder containing the scheduled tasks contains the enrollment GUID. In this case, starting with 163AF) in the registry, we are missing a bunch of values compared to a device that is properly enrolled (I know the enrollement GUIDs don’t match in the screenshot above and below. They were taken from different machines with the same issue ☺) . You can find the enrollment registry info under HKLM\Microsoft\Enrollments
I highlighted the values that differ on the problematic machine, but the big problems are the AADResourceID, DiscoveryServiceFullURL, EnrollmentType, and ProviderID. Those values clearly indicate this device was previously enrolled in MAM and the enrollment was never cleaned up.
A properly enrolled device shows the values we want:
So, now that we know our issue, we can take action. I confirmed this behavior on a few different devices, so I knew I was dealing with the same issue on all the problematic machines. Deleting the Registry key for that enrollment GUID, deleting the scheduled task, and running a gpupdate /force will manually fix this issue. However, when you have tens or hundreds of machines to correct, manually touching each machine is not feasible. Luckily, these machines all had an RMM installed where I could push PowerShell scripts in the system context. Since the Enrollment GUID is unique on each device, I needed a way to identify that GUID so the correct enrollment registry key was deleted. Since the scheduled task carries the name of the enrollment GUID, this was easy to identify on each machine. There are other ways to accomplish this, but this was the first thing that came to mind, and it made for a pretty simple PowerShell script:
$EnrollmentGUID = Get-ChildItem C:\windows\system32\tasks\Microsoft\Windows\EnterpriseMgmt | Select -ExpandProperty Name
$ScheduledTasks = Get-ScheduledTask -taskpath \Microsoft\Windows\EnterpriseMgmt\* | select -ExpandProperty TaskName
ForEach ($ScheduledTask in $ScheduledTasks)
{
Unregister-ScheduledTask -TaskName $ScheduledTask -Confirm:$false
}
Remove-Item -Path HKLM:\SOFTWARE\Microsoft\Enrollments\$EnrollmentGUID -Force -Recurse
start-Sleep 5
gpupdate /forceThe breakdown is outlined below. First, the script identifies the enrollment GUID based on name of the scheduled task. Next, it deletes the scheduled task and the registry enrollment GUID key (and all subkeys). Then, it runs gpupdate /force. That’s where we end up at this screenshot, with the newly generated scheduled task to run the device enroller:
A few minutes later, the device was enrolled and a new enrollment GUID was generated with scheduled tasks like so:
And our registry entried for that GUID look good now:
