Microsoft recently added a feature called MDM coexistence into SCCM. Basically this makes SCCM shut off most of it’s functionality when a third party MDM is detected on the machine. You will see errors such as “You don’t have permission to install this software” when coexistence mode is enabled.
This behavior is by design and will not be fixed. This has left a lot of organizations in a tough spot as the current version of SCCM will not work side by side anymore with third party MDM providers such as Airwatch. This post will outline a way I found to turn SCCM back on (with a caveat).
Imperfect Workaround
When you run this fix SCCM will turn back on no matter what version you have. However, MDM will stop reporting some types of telemetry. For example with Airwatch once I enable this fix it stops recording live telemetry in the Airwatch console until you turn it off.
This means that this isn’t really a workaround you can just deploy company wide that fixes it. It’s only a tool that will allow you to disable coexistence mode but if you don’t turn it back on eventually your MDM functionality will be impacted.
The ideal thing to do as a “workaround” is roll back to a version of SCCM before coexistence was introduced and not allow it to update to the latest version by blacklisting them in a device collection. I suspect this will cause problems over time as SCCM continues to be updated which is why I wanted to post this additional option/tool to help others who may be facing this have some options to temporarily reenable a new version of SCCM, etc.
Disabling Coexistence Mode Manually
Microsoft detects coexistence mode through the “Enrollment” registry keys. These are located at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\
Now look for the entries that have the little arrow next to them to expand. There should only be a few folders that are expandable like this. You are looking for one that contains a “DMClient” folder with a “AirWatchMDM” folder (or the name of the MDM you are using) inside it.
Highlight the folder that contains the DMClient/AirWatchMDM folder and right click and choose “Export” to export this folder. Name the file anything and just save a copy so you can restore your MDM functionality afterward.
Now delete the entire folder that you saved a copy of completely. It will ask you if you want to delete all keys and subkeys. Say yes.
Now run the following command in Command Prompt as Administrator:
WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE
That’s it. Now open SCCM and the permissions errors will be gone. The install button will no longer be disabled and SCCM activities will resume.
Restoring MDM Functionality
To restore MDM functionality just double click the .reg file you saved earlier before deleting the folder. Then run the policy reset command in Command Prompt as Administrator again:
WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE
That’s it. The workaround is now undone!
PowerShell Template
Here is a PowerShell template that is for the Airwatch example I gave above. You can modify this script to match the name of your MDM. The name you will use is the one that appears as ‘Provider ID’ from the manual steps above.
# Disable MDM coexistence and restore SCCM functionality # Warning: Airwatch stops sending certain telemetry while registry key is disabled # Backup key is saved to %PUBLIC% folder as "MDMbackup.reg" # James A. Chambers - https://jamesachambers.com $Enrollments = $null $AirwatchEnrollment = $null $Enrollments = Get-ChildItem -Path HKLM:\Software\Microsoft\Enrollments $AirwatchEnrollment = $Enrollments | Where-Object { $_.GetValue("ProviderID") -eq "AirWatchMDM" } if ($null -ne $AirwatchEnrollment) { $AirwatchRegPath = $AirwatchEnrollment.Name $AirwatchRegPath $AirwatchEnrollment reg export $AirwatchRegPath C:\Users\Public\MDMbackup.reg reg delete $AirwatchRegPath /f WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE }
And to restore (you can do this in either batch files or PowerShell, the restore script has no PowerShell specific commands):
reg import C:\Users\Public\MDMbackup.reg WMIC /Namespace:\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE
Conclusion
Since we know that this issue is by design none of this stuff is a permanent fix. For most organizations it’s going to be best to roll it back until you can implement a more permanent solution. For most places this is going to be removing the MDM client from laptops and managing them differently.
Until then hopefully this tool helps somebody work around this issue in a different way than I’ve really seen posted out there!
Hello James, thanks for your article.
I have a situation in which some clients have the issue but we haven’t never got any other MDM different from Microsoft Intune.
Indeed I cannot find any DM client folder inside the reg path that you suggested.
Could you help me in any other way?
Thanks in advance
Hey Lupo,
That’s very interesting! Are they getting the same “You don’t have permission to install this software” and other such shenanigans inside Software Center?
With only InTune installed you should only be subject to co-management instead of coexistence. This is what Microsoft had to say:
Here’s a thread about this issue with some different log files to check. This is one of the original threads that got me thinking about where I could find these registry keys that it is detecting coexistence with.
I’m curious if you pull some of these log files, particularly C:/Windows/CCM/logs/CCMSDKProvider.log, if you will see messages regarding co-existence or co-management. You’d be looking for lines like “Co-existence mode detected. this device is externally managed.” or some sort of indication that it is being put in this restricted mode. Let us know what you find!
Just had the same problem with MaaS360. Thanks for pointing me in the right direction.
After removing that reg key, Instead of running the WMIC command I just ended up restarting the SMS Agent Host service and all of the offending registry values referencing comanagement cleaned themselves up as far as I can tell.
Only thing left now is to figure out why machines that have gone through this are still showing up as “unable to verify the status” in the Device Compliance section of Software Center.
Hey Mike,
I’m glad to hear it helped! It seems like Microsoft definitely coded it to rely pretty much exclusively on that registry key. If you export the .reg and then import it again SCCM will lock up almost immediately!
I’m in the process of cleaning up a bunch of machines right now and I’ll have to make sure none of mine are also showing the “unable to verify the status” message. Thanks for the tip!
Hi Mike, could you please share the name of the folder for MaaS360? I was not able to locate in my computer. I found SCConfigMgr folder instead.
Thanks for this James. Had a device that wasn’t properly unenrolled from AirWatch when we were testing it as an MDM solution. Used this article to get it out and it is now updating properly via our SCCM.
I also had to change the regkey at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\ExternallyManaged from 0 to 1 and restart for the device to exit co-existence mode. Hopefully this is permanent for me since our AirWatch server is no longer active.
Glad to hear of some success out there Mark, thanks for letting us know about this additional registry key as well! I wasn’t sure if this was too niche to be of use to anyone but I figured I’d throw it out there and see!