Co-Management Devices Won’t Enrol – Stuck In Co-Existence Mode – This device is enrolled to an unexpected vendor, it will be set in co-existence mode.

I’ve been looking at co-management enrolment problems for a customer and for a chunk of these devices the comanagmenthandler.log, on each device, was reporting that it was in co-existence mode.

Well this was interesting, since the company was not using any 3rd Party MDM solution at all. The devices were unable to run applications, packages and task sequences and this is by design. If you look at the docs it states:

When the Configuration Manager client detects that a third-party MDM service is also managing the device, it automatically deactivates certain workloads in Configuration Manager. This behavior allows the MDM service to take over these functions. It also prevents conflicting settings on the client that could adversely impact the device and user experience. The following workloads in Configuration Manager are deactivated in this case:

• Resource access policies for VPN, Wi-Fi, email, and certificate settings
• Application management, including legacy packages
• Software update scanning and installation
• Endpoint protection, the Windows Defender suite of antimalware protection features
• Compliance policy for conditional access
• Device configuration
• Office Click-to-Run management

I’ve read online about people having problems disabling co-existence mode but I was able to do this manually by removing some registry keys and reinstalling the ConfigMgr client restarting the SMS Host service (see Comments).

The challenge however was that I could not push the reg key removal via an application or package as the deployments sat in the unknown status for apps, or in progress for a package – co-existence mode had turned this functionality off.

Luckily, scripts were not disabled so I was able to tap into this ConfigMgr feature to resolve the problem.

Initial searches on the warning message in the comanagementhandler log to Reddit This device is enrolled to an unexpected vendor, it will be set in co-existence mode. : SCCM (reddit.com) where my MVP buddy Bryan Dam (@bdam555) / Twitter references a blog post about disabling co-existence mode manually Disabling SCCM MDM Coexistence Mode (Unofficial Workaround) (jamesachambers.com).

I followed the steps by checking the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\ and looked for a subkey containing DMClient. None of the subkeys did, as expected since the customer was not using 3rd Party MDM.

I also read another Reddit somewhere in the ether, where an admin had been advised to remove the enrolments key to fix his problem by Microsoft.

I didn’t want to be so gung-ho, so I decided that my compromise would be to remove the keys with SIDs and leave the rest of the subkeys intact.

Here’s what the enrolments key looked like on the device.

I also found that just removing the keys did not resolve my problem, I had to re-install the ConfigMgr client and then things looked as they should with the client now co-management enabled and enroled into Intune. Note in the comments, however, that a simple restart of the SMS Host service should do the trick!

During my investigations of enrolment errors (difference error BTW), I came across this great blog post FIX FOR: Azure AD join error code 8018000a – This device is already enrolled – Inspired Techs which has a script that checks the HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows\EnterpriseMgmt\<SID> value and then scrolls through the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\ key and removes the corresponding value. The script requires input from the end user. So I decided to ‘beg, steal and borrow’ and modify this script to remove input and just remove all the SIDS from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollmentsl.

Here’s the script:

# $sids = Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked' -name |where-object {$_.Length -gt 25}


$sids = Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Enrollments' -name |where-object {$_.Length -gt 25}

Foreach ($sid in $sids){

$enrollmentpath = "HKLM:\SOFTWARE\Microsoft\Enrollments\$($sid)"
#$entresourcepath = "HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\$($sid)"

 
$value1 = Test-Path $enrollmentpath
If ($value1 -eq $true) {
 
write-host "$($sid) exists and will be removed"
 
Remove-Item -Path $enrollmentpath -Recurse -confirm:$false
#Remove-Item -Path $entresourcepath -Recurse -confirm:$false
 
}
Else {Write-Host "The value does not exist, skipping"}
 }

Go to your ConfigMgr console and under the Software Library\Scripts. Right-click and Create Script.

Give it a name and click Import. Select your PS1 file with the script. Click Next.

As with any imported script, it will need approval, so ask another admin to check this over and approve.

When approved, select the devices or collection, right-click and choose Run Script.

Highlight your script, and click Next through the wizard. Keep an eye on the script status in the Script Status Monitoring section.

On the device itself, you’ll notice that some enrolment SIDS are left. These SIDS are in use and cannot be removed.

As stated, I had to re-install the ConfigMgr client to get my devices enrolling successfully. Use whatever method is best for you to achieve this.

Hope this helps.