Change co-existence behavior between ConfigMgr and 3rd Party MDM
Recent changes in co-management support on CB 1902 when using 3rd party MDM providers limits SCCM functionality that was previously available.
https://docs.microsoft.com/en-us/sccm/comanage/coexistence
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
Features such has application management should still function in the co-management scenario at the administrators discretion.
Andrew Bashore
shared this idea
Admindjam
(Product Director, or Executive, Microsoft Endpoint Configuration Manager)
responded
This is the way co-existence works. Details here: https://docs.microsoft.com/en-us/sccm/comanage/coexistence
ConfigMgr cannot safely interact with random 3rd Party MDM agents that are simultaneously attempting to manage the machines. ConfigMgr and Intune were designed together to interop safely together.
7 comments
-
Greg
commented
I agree with the original post as well--there should be a supported means to disable this behavior. If it's "by design," the design is poorly thought-out. Making this a default behavior would be fine, but without the flexibility to turn it off, you are essentially breaking customers' environments and forcing substantial changes (i.e., either remove MDM from the picture or figure out how to migrate the entire software deployment and software update process into the MDM) in order to fix it. I'm sure I'm not alone in having an environment where MDM was brought in initially to serve specific, targeted needs, and is nowhere near ready (nor was it ever intended) to take over all the functions currently handled by SCCM. I suppose if we had purchased Microsoft's MDM, we wouldn't be in this dilemma. Perhaps that is at the root of this "design." Prove me wrong--please provide a way to override this behavior.
-
Jason
commented
I agree with the original post. Administrators should have the option to enable or disable certain workloads as needed. I understand SCCM doesn't have insight into what's being deployed from the 3rd party MDM, but the admin should be trusted to be able to not duplicate workloads in both environments to avoid conflicts.
-
Anonymous
commented
We are in the exact same situation. Please include the ability to override this behavior
-
Adam
commented
Maybe you could make an option available where an admin can override this behaviour.
-
Jarrod
commented
I could understand certain features being disabled for concern of conflict, but why not allow an administrative override so the customer can decide. Its only an issue if there are conflicting values. Additionaly, how can software deployment be an issue? We can deploy software manually or via group policy, why not via MDM as well? The same could be said of Windows Update, group policy and SCCM exist in a somewhat coexistent state where it can be overridden by GPO but still can be configured by SCCM. Since third party MDM solutions leverage built in windows MDM APIs, could this not be addressed by the Operating System team?
-
Ryan Manly
commented
This is a problem for several reasons not the least of which is that our SCCM software deployment has over 300GB in it. Our MDM provider does not provide that much space and paying for supported third-party cloud storage to distribute that much software is not an option. We are a high school district with multiple schools.
This was a really poor decision.
-
Ben
commented
We are experiencing this issue first hand first when we went to 1902 and also in 1906. We currently use AirWatch as our MDM, and since moving to 1902, SCCM has been completely cut off at the knees after the update. 1902 disabled all of our deployments, and also set all of our software in the software center to state "you do not have permissions to download the software".
This is a HUGE issue for anyone with a 3rd party MDM, as any SCCM version after 1810 will break all of your software distribution methods.