Remember, remember, the Hybrid Device, the MDM only enrollment Treason and The EPM Agent

Are you dealing with Hybrid joined, Intune enrolled devices and wondering why the EPM agent isn’t showing up on your device after activating the Intune Suite and assigning an EPM policy? If so, this blog is for you. I will explain why your MDM only enrollment might be causing the issue.

1. The Issue

Last week, I noticed a question on Reddit. In this question, the OP had some issues with the Endpoint Privilege Management (EPM) agent getting on his hybrid joined devices.

He activated the Intune Suite and targeted the EPM policy to his hybrid joined devices, but nothing happened.

His devices were all Intune enrolled and didn’t show any issues…

But that’s where I come in. I started asking the OP some questions, and within a few minutes, it became clear the device wasn’t getting onboarded to the MMP-C infrastructure.

Well, if you look at the enrollstatus (4) AKA Enrollment succeeded, we could think otherwise, but noticing the lasterror: 0x8018000b, tells the opposite.

This MMP-C enrollment is a hard requirement for installing the EPM agent. Without a working MMP-C/linked/dual enrollment, the EPM agent isn’t getting installed. This sounds like a fun issue! Shall we continue and start digging?

2. The weird errors:

It would be best to break some things first to get to the bottom of some issues. You can’t bake an omelet without breaking some eggs, right?

So, I asked if the OP had a test device that he could use to do some stupid things. Luckily, the OP had a few he could mess up. I asked him to walk through this blog post and try to manually onboard the device to MMP-C.

EPM Enrollment | DeviceHealthMonitoring | Error | MMP-C (call4cloud.nl)

Why? At that point, the schedule to start the dual enrollment will kick in, and we will have a specific timeframe that can be used to pinpoint the corresponding errors.

The first one we got when that schedule was kicked off showed us the same error we got in the last error status (0x8018000b). Nothing new here. But at that exact second, a different error was logged in the Operational logs

As shown above, this one mentioned that there is ‘No active AAD enrollment. ‘ Well, that’s a weird one. When I got this error, I wondered what the dsregcmd /status output would tell us.

When looking at the output, it is evident that the device was AzureAdJoined and DomainJoined, AKA Hybrid, and not workplace joined. Before I started asking some more questions, I decided to open IDA and open the deviceenroller.exe

3. Checking with the IDA Tool

I opened the IDA tool and the device enroller. Once I opened the deviceenroller.exe, I started searching inside the DualEnrollMmpcAAdCredential function.

I guess the function name is already spoiling the pleasure, but this function is responsible for dual enrolling the device to MMP-C using the AAD credentials. This dual enrollment will link itself to the Intune enrollment.

When looping through the function, we will notice that it will eventually lead to the same error we saw in the event log: No active AAD Enrollment

I pressed F5 to get me some more readable information. This disassembled code pointed me to the “IsAlreadyEnrolled” namespace.

This IsAlreadyEnrolled, imports an external function called: GetDatabaseManagerInstance. This function is an exported function from the Dmenrollengine.dll

Since the disassembled code did not tell me anything useful, I just kicked off Rundll32 with the dmenrollengine.dll,GetDataBaseManagerInstance parameter.

Before kicking off the command, I watched Procmon Go. When I looked at how it kicks off the device enroller with the autoenrollmdm parameter, it showed me that it was looping through the enrollments database.

With this information, I started wondering how the hybrid device was enrolled into Intune and if it may also have some lingering enrollments

4. Checking the enrollments DB

I asked the OP if he could check the registry to determine what the Intune enrollment looked like and if it was the only one.

The moment he sent me the picture below, I started having a lot of questions.

1. The DiscoveryServiceFullUrl, doesn’t mention the auto enrollment uri : enrollment.manage.microsoft.com that I expected.
2. The Enrollmenttype configured was zero, which I was expecting to be 6?
3. The ForceAadToken was also zero, which I was expecting to be 1.
4. It mentioned the SID, which generally shouldn’t be in it as the device did the enrollment, not the user. If the device did the enrollment, we the AADTenantID should be in the enrollment registry

Combining these details, things started becoming clearer. The enrollment type 0 corresponds to a UserEnrollment.!!!!!

Noticing that enrollment type brought back memories! As in this blog, I was showing you some issues with the Intune Certificate.

Intune | MDM-only | Enrollment | Missing Device Certificate (call4cloud.nl)

The outcome of this blog was that the OP enrolled his devices with the MDM-only option, AKA Enrol only in device management

This MDM only enrollment caused many issues because it is a user based enrollment and not using the DeviceToken .

MDM Only = Enrollmenttype = 0 AKA UserEnrollment

Where it should have been Intune enrolled during AADJ = Enrollmenttype = 6 (Using the DeviceToken)

So, I was curious about how the OP enrolled those hybrid devices in Intune in the first place.

5. What happened

After reaching out to the OP and asking for some background information, it became obvious that many users suddenly needed to start working from home some time ago (something to do with Corona). At that point, they wanted to manage the device, but because they didn’t have a VPN in place, they sent the user an email with a deep link. This link would enroll the device into Intune without causing trouble for the users.

Why? Many articles on the internet told them it was user-friendly and would simplify the enrollment process for Windows 10 devices.

Well, when you have hybrid devices and want to enroll them in Intune, you must follow the official path. This path will show that you must configure a GPO to enable automatic MDM enrollment using the default AAD Credentials.

This is the way!! The MDM-only option is NOT supported and will lead to weird errors in the future. If you are enrolling an existing hybrid device to Intune and using the MDM-only option, it will be a user-based enrollment, not a device-based one.

If we don’t have a device token, the MMP-C enrollment will not happen!

So, if you are doing it this way… please don’t

6. Fixing It

I asked the OP if it could delete the lingering Intune Enrollments. He could do so by kicking off this PowerShell script, which would remove the registry and certificate keys.

# Find Intune CurrentEnrollmentId and remove enrollment if one exists...
Try { $enrollment = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Logger CurrentEnrollmentId -ErrorAction Stop }
Catch {}
If ($enrollment) {
$enrollmentId = $enrollment.CurrentEnrollmentId
# Get Tasks and delete...
$scheduleObject = New-Object -ComObject Schedule.Service
$scheduleObject.Connect()
$TaskFolder = $scheduleObject.GetFolder("\Microsoft\Windows\EnterpriseMgmt\"+$enrollmentId)
$Tasks = $TaskFolder.GetTasks(1)
ForEach($Task in $Tasks){ $TaskFolder.DeleteTask($Task.Name,0) }
$rootFolder = $scheduleObject.GetFolder("\Microsoft\Windows\EnterpriseMgmt")
$rootFolder.DeleteFolder($enrollmentId,0)
# Remove old registry keys...
Remove-Item HKLM:\SOFTWARE\Microsoft\Enrollments\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\Enrollments\Status\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\PolicyManager\Providers\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Logger\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions\$enrollmentId -Recurse -Force -ErrorAction SilentlyContinue
Remove-ItemProperty HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Logger\ -Name CurrentEnrollmentId -Force -ErrorAction SilentlyContinue
# Remove old and new style Intune certificates...
$certNew = Get-ChildItem Cert:\LocalMachine\My\ | Where-Object { $_.Issuer -Match "CN=Microsoft Intune MDM Device CA" }
If ($certNew) { $certNew | Remove-Item -Force -ErrorAction SilentlyContinue }
}

After wiping the registry nodes and the certificate, the GPO that was put in place to ensure the device was getting enrolled to Intune in a supported way started doing its job. With the GPO doing its work, the enrollment registry node began looking at what it should look like

Within a couple of minutes, after the device was Intune enrolled, the device could fetch the device token and be onboarded to the MMP-C infra.

With the MMP-C requirement being met, the EPM agent also started showing up on his device. With the EPM agent installed, the OP could now finally elevate his process with EPM.

7. The DEM Account

After writing this blog and before posting it, James tagged me in a conversation (WinAdmins Discord Channel) when someone was asking why the Endpoint Privilege Management Client did not appear on his device after configuring the requirement.l

I decided to step in… as that’s what I do. After talking in private with him and asking for some screenshots, it became obvious what the error was.

1. I was missing the Tenant ID
2. The EnrollmentType is also 0!
3. The ForceAadtoken is also 0!

With this screenshot, I asked him if he was also noticing the event 4022 error that mentions that it failed to enroll MMP-C for dual enrollment mode (0x8018000b)

As shown above, he was getting the same error but was NOT using the enroll in MDM-only option. Guess what he was using? A Device Enrollment Manager (DEM) account

I asked him to perform the steps I mentioned in part 6. Take another guess at what happened! After a successful Intune enrollment, the device also received the Linked enrollment, and with it, the EPM agent arrived on the device!

Conclusion

Don’t use the “Enroll in Devicemanagement only” or a “Device Enrollment Manager” option to enroll your device to Intune with hybrid devices! This could haunt you for the rest of your life. Do you want to hear about another side issue with this enrollment option?

It also could cause your Intune Management Extension to be uninstalled out of nowhere!