Deploying the ConfigMgr client via Microsoft Intune

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.

Introduction

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:

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.

Prerequisites

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;

Configuration

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.

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.

Result

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.

More information

For more information about deploying the ConfigMgr client via Microsoft Intune, please refer to the following articles.

Hi Rkast,
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.
Regards, Peter

Good guide!
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?

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.

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.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!