This week is all about deploying the ConfigMgr client via Microsoft Intune. Like last week, this is also a nice addition in combination with Windows AutoPilot. The idea is to install the ConfigMgr client next to the MDM agent and to create a co-management scenario. The main use case to do something like this is when an organization is making the transition from traditional management to modern management. In that scenario the organization can use co-management to make a phased move to the cloud. For example, use ConfigMgr for patch management and use Microsoft Intune for configurations and compliance. In this post I’ll provide a short introduction to co-management, followed by the prerequisites for the ConfigMgr client installation and the end result.
Starting with Configuration Manager, version 1710, co-management enables organizations to concurrently manage Windows 10, version 1709, devices by using both Configuration Manager and Microsoft Intune. There are two main paths to reach to co-management:
- Configuration Manager provisioned co-management where Windows 10 devices managed by Configuration Manager and hybrid Azure AD joined get enrolled into Microsoft Intune;
- Microsoft Intune provisioned devices that are enrolled in Microsoft Intune and then installed the Configuration Manager client to reach a co-management state (focus of this post).
I can continue with a long story about co-management and the capabilities that it provides, or how co-management is the bridge between traditional management and modern management, but the following picture shows close to all of that.
Note: Picture is coming from this co-management overview article.
Now let’s start by having a look at the prerequisites that must be in place to enable the second path to co-management, which is deploying the ConfigMgr client to Microsoft Intune enrolled devices. The following technical prerequisites must be in place:
- MDM authority set to Microsoft Intune;
- Device is Azure AD joined;
- Windows 10, version 1709 or later;
- Configuration Manager, version 1710 or later;
- Cloud Management Gateway (CMG);
- Cloud Distribution Point (CDP);
- Co-management enabled;
- Management Point (MP) set to HTTPS;
- Synchronization of Azure AD users enabled;
Let’s continue by having a look a the configuration. I’ve divided the configuration in three steps. The first step is to get the required command line, the second step is to explain the command line (and add some additional parameters) and the third step is to actually deploy the ConfigMgr client.
Step 1: Get the command line
The first step is to get the required command line. The following three steps walk through the easiest method to get the required command line.
Step 2: Explain the parameters
The second step is to look at the command line and to explain the parameters that are used. The following parameters are used in the command line.
- /mp: The download source, which can be set to CMG, to bootstrap from internet;
- CCMHOSTNAME: The name of the Internet management point, which can be set to CMG;
- SMSSiteCode: The site code of the Configuration Manager site;
- SMSMP: The name of the lookup management point (can be on the intranet);
- AADTENANTID: The ID of the connected Azure AD tenant;
- AADCLIENTAPPID: The ID of the client app in Azure AD;
- AADRESOURCEURI: The URI of the server app in Azure AD;
- SMSPublicRootKey: Specifies the Configuration Manager trusted root key.
Note: As I’m using certificates from my internal PKI-environment, and I’ve not published my CRL on the Internet, I also needed to use the following parameters.
- /nocrlcheck: The client should not check the certificate revocation list;
- CCMHTTPSSTATE: Specify 31 to prevent certificate revocation list check.
Step 3: Deploy the ConfigMgr client
The third step is to actually deploy the ConfigMgr client via Microsoft Intune. Simply follow the next three steps and assign the created app to a group.
Note: As I’m using certificates from my internal PKI-environment, I also needed to deploy the root certificate of my environment to the Trusted Root Certification Authorities store of the devices. That could be easily achieved by using a Device configuration profile and using the Trusted certificate profile type option.
Now let’s end this post by looking at the end result. The first place to look, after the ConfigMgr client installation, is Microsoft Intune. Below is an overview of my Azure AD joined devices that are managed by MDM and ConfigMgr. By looking at the compliance state, it’s clear that my workload for compliance policies is set to Intune.
The second place to look, after the ConfigMgr client installation, is the Configuration Manager console. Below is an overview of the same devices from a ConfigMgr perspective. By looking at the device online information, it’s clear that those devices are connecting over the Internet via CMG.
For more information about deploying the ConfigMgr client via Microsoft Intune, please refer to the following articles.
- Plan for the cloud management gateway in Configuration Manager: https://docs.microsoft.com/en-us/sccm/core/clients/manage/plan-cloud-management-gateway
For more information about the installation of the prerequisites (CMG, CDP, Co-management) there are some nice step-by-step guides available, see
12 thoughts on “Deploying the ConfigMgr client via Microsoft Intune”
Can we target co-mgmt to only a subset of computers? Like pc1 to pc10 use configmgr/ad gpo and pc11 to pc20 use Intune/policies/oma-uri?
At this moment (ConfigMgr version 1710) you can create one co-management policy that can set workloads (compliance policies, resource access policies, windows update policies) to either ConfigMgr, Pilot Intune or Intune.
When we set this up, Intune looses control of the device after the SCCM agent is installed: New profiles and apps can not be deployed from Intune, yet everything is compliant and no errormessages. The device will never get new assignments.
Can you confirm this is working for you?
Thank you, Ola!
Straight from the docs (https://docs.microsoft.com/en-us/sccm/core/clients/manage/co-management-overview): After you enable co-management, Configuration Manager continues to manage all workloads. When you decide that you are ready, you can have Intune start managing available workloads.
A simple example is when you open the Company Portal app, it will refer to Software Center for apps.
Thanks for your reply Peter.
Unfortuately it’s not that easy.
We have switched all the workloads to Intune, yet when we create a New Device Configuration (for example a simple exclusion of a process in the antivirus scan), this profile never gets assigned to any of the devices that are comanaged.
If we enroll a device without comgmt (without sccm agent), the profile is assigned and takes effect.
So the profile itself works, but it does not get applied to any devices in a comanagement setup, even with all the workloads set to Intune.
Have you done this successfully in your environment?
What I was trying to refer to is that, according to the docs, not everything can be switched to Intune in a co-management scenario. At this moment only compliance policies, Windows Update for Business policies and resource access policies.
I just tested this with a compliance policy and I’m seeing the results coming in my Intune dashboard.
Thanks for your reply Peter.
Premier Support just confirmed that my scenario is a known issue that multiple customers have problems with at the moment, which should have worked. The product group is working on a fix.
Thank you for letting me know Ola!
Hi, Can you please provide more information on how this is done
“Note: As I’m using certificates from my internal PKI-environment, I also needed to deploy the root certificate of my environment to the Trusted Root Certification Authorities store of the devices. That could be easily achieved by using a Device configuration profile and using the Trusted certificate profile type option.”
That can be achieved by using a Trusted certificate profile.
Hi, do these steps install the ccm client during autopilot or after? Thanks
That’s a possibility. For the latest parameters, see also: https://docs.microsoft.com/en-us/mem/configmgr/comanage/how-to-prepare-win10#install-the-configuration-manager-client