This blog post is a follow-up on this earlier post about deploying the ConfigMgr client via Microsoft Intune. In this post I want to look more at the behavior of the ConfigMgr client in a co-management scenario. I want to show the available configurations and, more importantly, I want to show the behavior of the ConfigMgr client. I want to show the corresponding configuration and the messages in the different log files.
Co-management configuration
Now let’s start by looking at the different configuration options of co-management and the configuration values. To look at the available configuration options, simply follow the next three steps (assuming the initial co-management configuration is already created).
| 1 | Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Co-management; |
| 2 | Select CoMgmtSettingsProd and click Properties in the Home tab; |
| 3 |
Note: Looking at the current Technical Preview version, the number of available workloads will quickly increase. |
ConfigMgr client behavior
Now let’s make it a bit more interesting and look at the behavior of the ConfigMgr client. By that I mean the configuration changes of the ConfigMgr client that can be noticed in the log files. The co-management configuration related log file is the CoManagementHandler.log (as shown below). That log file shows the processing of the configuration and the MDM information related to the device.
The values in the CoManagementHandler.log are shown, after a configuration change, in both hex and decimal. These values relate to the following workload distribution.
| Value | Configuration Manager | Microsoft Intune |
| 1 (0x1) | Compliance policies, Resource access policies, Windows update policies | – |
| 3 (0x3) | Resource access policies, Windows Update policies | Compliance policies |
| 5 (0x5) | Compliance policies, Windows Update policies | Resource access policies |
| 7 (0x7) | Windows Update policies | Compliance policies, Resource access policies |
| 17 (0x11) | Compliance policies, Resource access policies | Windows Update policies |
| 19 (0x13) | Resource access policies | Compliance policies, Windows Update policies |
| 21 (0x15) | Compliance policies | Resource access policies, Windows Update policies |
| 23 (0x17) | – | Compliance policies, Resource access policies, Windows Update policies |
Compliance policies
When co-management is enabled, the ConfigMgr client will verify if it should apply compliance policies. Before applying them. That information is shown in the ComplRelayAgent.log (as shown below). It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the compliance policies. After that it will perform an action on the policy. In this case it won’t report a compliance state.
Resource access policies
When co-management is enabled, the ConfigMgr client will also verify if it should apply resource acces policies. Before applying them. That information is shown in the CIAgent.log (as shown below). As that log file is used for a lot more operations, it might be a bit challenging to find the information. It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the resource access policies. After that it will perform an action on the policy. In this case it will skip the related CI.
Windows Update policies
When co-management is enabled, the ConfigMgr client will also verify if it should apply Windows Update for Business policies. Before applying them. That information is shown in the WUAHandler.log (as shown below). It shows the current configuration (for a translation of the workload flags see the table above) and what it means for the status of the Windows Update for Business policies. After that it will perform an action on the policy. In this case it will look for assigned policies.
Hi Peter, I have a question I hope you can answer. If we have on-prem AD joined Windows 10 device and have setup co-management do we have to configure (1) “hybrid Azure Active Directory joined devices” or (2) configure the GPO “Enroll a Windows 10 device automatically using Group Policy” or (3) does the ConfigMgr client do this and registers the device?
Secondly when we have on-prem AD joined Windows 10 device and have setup full co-management with client management gateway and cloud distribution point, and the device is off network for more than 30 days does the computer account/password expire or is this mitigated by the management gateway/internet facing?
Hi RKast,
About the first question, nowadays the co-management policy will trigger the device registration.
About the second question, the computer account/password expiration is Active Directory related and is not something that is controlled by ConfigMgr.
Regards, Peter
Thanks Peter for your swift reply.
This is interesting material and architectural wise a challenge 🙂
So setting up hybrid azure ad devices or using the GPO register the device in MDM is not necessary, good to know. So the co-management configuration/policy will register the device. Do you know if it is an MDM registration that the co-management policy does or an AAD join or an AAD registration like AD Connect does when Hybrid AAD joined devices is configured?
So for devices joined to on-prem AD and registered in MDM and thus in co-management cannot be offline&offsite longer than 30 days. Solution for this would be to do an AAD join on the Windows 10 device and install the ConfigMgr client in co-management mode like in your last blog? Then devices can be offline&offsite more than 30 days, correct?
Hi RKast,
Yeah, I should have been a bit more clear. It’s the MDM-enrollment that will be triggered by the co-management policy.
AAD join is the way-to-go. Having said that I don’t know what the exact implications are with the hybrid devices. That’s worth some investigations.
Regards, Peter
Ok, so the co-management policy sets the “Auto MDM Enrollment with AAD Token.” policy on the client in the local secpol/gpedit.
Not joining on-prem AD but AAD join indeed means you can encounter problems accessing on-prem workloads.
But accessing on-prem UNC path and/or accessing an AD member web server with IWA authentication can be accessed because an AAD joined devices get an PRT token for Azure AD, and a TGT token for AD. So these workloads are mititgated. For printing we can implement microsoft hybrid cloud printing. But i agree not all workloads are ‘covered’ like GPO’s etc.
There is still a ‘gap’ for offsite/offline devices that are offline/offsite for more than 30 days in combination with traditional management (sccm). But Modern management (intune) does not have all device management options of Traditional management (sccm).
Agree, not every scenario is completely covered. Often devices that are offsite that often are an ideal use-case for Intune (with or without co-management).
Regards, Peter
Hi Peter,
We configured co-management and also CMG and CDP. Client connects successfull to the CMG and client on Internet can successfully install/get package from the CDP, so this all works. But we have enabled co-management but the AD joined devices are not getting registered in Azure AD and thus Intune. Device is member of the collection, user is licensed with EMS any tips or suggestions?
Hi RKast,
I would start by looking at the CoManagementHandler.log as it should provide information about the enrollment.
Regards, Peter
We found the cullprit. Customer did not configure AAD Hybrid Devices as per https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup
Its one of the prereqs for AD joined devices! #fliptheswitch only 4 click…. 😉
It’s all about the details 🙂
Thanks for the log file value mapping Peter, but I was needing to perform a bitwise calculation for validating certain workloads so I kept searching for an official list of flag values for each workload. Below is the list in case anyone else needs it, borrowed from this Microsoft Blog: https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-configuring-workloads-in-a-co-managed-environment/ba-p/707221
Workload
1 (0x1) – Inventory. It simply means co-management is configured
2 (0x2) – Compliance policies
4 (0x4) – Resource access policies
8 (0x8) – Device Configuration
16 (0x10) – Windows Update policies
32 (0x20) – Endpoint Protection
64 (0x40) – Client apps
128 (0x80) – Office Click-to-run apps
Thank you for the information Darin!
Regards, Peter