Co-management and the ConfigMgr client

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

ComanagementPropertiesNavigate to the Workloads tab, which provides the option to switch the following workloads from Configuration Manager to Intune:

  • Compliance policies;
  • Resource access policies (this contains VPN, Wi-Fi, email and certificate profiles);
  • Windows Update policies.

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.

Log_ComanagementHandler

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.

Log_ComplRelayAgent

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.

Log_CIAgent

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.

Log_WuaHandler

10 thoughts on “Co-management and the ConfigMgr client

  1. 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?

  2. 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

  3. 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?

  4. 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

  5. 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).

  6. 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?

Leave a Comment