Introduction
Again, continuing the Co-management and flipping the switch journey, and moving the brand new Device Configuration workload to Intune MDM. This is the latest addition to the co-management world introduced in Configuration Manager 1806 (released 2 days ago at time of writing) and it’s absolutely amazing.
- Flipping the switch, part 1: How to enable Co-management in SCCM Current Branch (System Center Configuration Manager)
- Flipping the switch, part 2: Moving Endpoint Protection workloads to Intune MDM (Co-management with SCCM)
- Flipping the switch, part 3: Moving Software Updates workload to Intune MDM (Co-management with SCCM)
This means we finally (almost) can ditch group policies altogether and do our device configurations with Intune MDM. I will give you how to and an excellent example in this post. Read on. 🙂
Configuration Manager
Before being able to do anything in this regard, we have to move the new workload into Intune. This is done in the Configuration Manager console, in the Administration work space in Cloud Services -> Co-management. See below illustration.
Note: I also need to mention, that in order for this to work on the Co-managed device, the SCCM client of course needs to be running a 1806 version.
Once above changes has been done, the Configuration Policy will be updated with a new revision and as of such, the clients needs to have their machine policies refreshed (everything standard SCCM behavior). Once refreshed, you can monitor the addition of the new workload in ComanagementHandler.log on the client.
In below snippet, my workload capabilities are moving from 55 to 63, which is indicating the switch of the new workload has been picked up.
Intune MDM
Now, moving over to Microsoft Intune, we are now able to create custom Device Configuration profiles and assign those to the Co-managed devices. A perfect first choice here is to have a look at the CSP policy called MDMWinsOverGPO.
In short, it will make sure that MDM wins if an equivalent settings is set through group policies. This is EXTREMELY useful when slowly moving to modern management. More on the new setting, which is unique for Windows 10 1803 here: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-controlpolicyconflict#controlpolicyconflict-mdmwinsovergp
MDMWinsOverGPO
- Create a new custom Device Configuration in Microsoft Intune and assign in to your Co-managed computers.
- Give it a suitable name and description
- Platform: Windows 10 and later
- Profile type: Custom
- Name: ControlPolicyConflict/MDMWinsOverGP
- Description: MDM settings will win over Group Policies
- OMA-URI: ./Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP
- Data type: Integer
- Value: 1
Now, PRIOR to SCCM 1806 this was not possible and if tried, you would see a Not applicable deployment status in Intune as illustrated below:
Today, and POST SCCM 1806 we see this. Yay!
What else?
As a final note I want to make you aware of following setting on Configuration Baselines in Configuration Manager:
Always apply this baseline even for co-managed clients
If you switch the Device Configuration workload into Intune MDM, and still want your baselines to be applied onto your computers, remember to enable this.
Oh, and by the way. Now you can visually see the Co-management configuration policies in the Configuration Manager applet in the Control Panel. Nice!
References:
https://docs.microsoft.com/en-us/sccm/core/clients/manage/co-management-overview
https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1806
Great post – appreciate this.
Would you elaborate any further on your Intune policy naming convention?
Great post
But I have an issue:
I have SCCM 1806 environment.
I have enabled the device configuration policies to be managed by Intune but from the logs it seems to be still managed by SCCM
Even in Intune the policies assigned shows a status not applicable.
Can you please help in this issue…
Is the SCCM client in question upgraded to 1806? You have to make sure the SCCM client is running version 5.00.8692.1003
Actually the client was not upgraded properly. After upgrading it is working fine.
Thank you