In order to walk you through the entire process of setting up the co-management feature, I am going to break this down into a number of parts;
- How to setup Co-Management – Part 1 (Roles and Certificates)
- How to setup Co-management – Part 2 (Create Certificates)
- How to setup Co-management – Part 3 (Cloud Management Gateway)
- How to setup Co-management – Part 4 (Management point and Software Update point)
- How to setup Co-management – Part 5 (Cloud Distribution point)
- How to setup Co-management – Part 6 (Setup Co-management in ConfigMgr)
- How to setup Co-Management – Part 7 (Deploy ConfigMgr client to Azure AD joined devices from Intune) – This post
There are two main paths to reach to co-management. One is Configuration Manager provisioned co-management where Windows 10 devices managed by Configuration Manager and hybrid Azure AD joined get enrolled into Intune. The other is Intune provisioned devices that are enrolled in Intune and then installed with the Configuration Manager client reach a co-management state
In this post I will show you how to use Intune deploy ConfigMgr client to Azure AD joined devices.
If you are using internal certificates, you need to deploy your root certificates to Azure AD joined machines with Intune.
Deploy Root CA to clients
You need to deploy your Root CA what we exported in Part 2 to clients via Intune.
- Click on Intune – Device configuration – Profiles – Create profile
- Fill out the following information, and add you Root CA to computer certificate store – Root
- Assigned the profile to users and devices.
Prepare ConfigMgr client installation
- Copy ccmsetup.msi from “Your ConfigMgr installation path\bin\i386” to another folder, example: D:\ConfigMgr
- Log on Azure Portal
- Browse Microsoft Intue – Mobile apps – Apps, Click on Add
- Choose App type: Line-of-business app
- Click on App package file – Select file.
Browse the folder where you save the ccmsetup.msi, and add it.
- Prepare ConfigMgr client installation command-line
You can copy those command line arguments from Co-management properties.
CCMSETUPCMD=”/nocrlcheck /mp:https://SMSBOOTCMG.CLOUDAPP.NET/CCM_Proxy_MutualAuth/72057abcdefg CCMHTTPSSTATE=31 CCMHOSTNAME=SMSBOOTCMG.CLOUDAPP.NET/CCM_Proxy_MutualAuth/72057abcdefg SMSMP=https://CM02.ZIT.local SMSSiteCode=ZIT AADTENANTID=960c58f5-7770-4b97-b5f4-abcdefg AADTENANTNAME=SMSBOOT AADCLIENTAPPID=eeab5468-2322-471d-ab30-123456789 AADRESOURCEURI=https://ConfigMgrService”
/nocrlcheck – If you didn’t publish your CRL to internet
/MP – Download source. Set to CMG, because we are deploy client from internet.
CCMHTTPSSTATE=31 – Same as no CRL check. Base on my test, without this argument client failed communicate with server.
CCMHOSTNAME – The name of your Internet management point.
You can find this by running gwmi -namespace root\ccm\locationservices -class SMS_ActiveMPCandidate from a command prompt on a managed client.
SMSSiteCode -The site code of your Configuration Manager site.
SMSMP – The name of your lookup management point – the management point can be on your intranet.
AADTENANTID, AADTENANTNAME – The ID and name of the Azure AD tenant you linked to Configuration Manager.
You can find this by running dsregcmd.exe /status from a command prompt on an Azure AD joined device.
AADCLIENTAPPID – The Azure AD client app ID. You will find that from Azure Portal
AADResourceUri: The identifier URI of the onboarded Azure AD server app. You will find that from the Azure Portal
You can also find some of those information in the Admin Console
- Click on App information – Configure, input Command-line arguments:
- Click OK, then Add.
- Assign this ConfigMgr Client Setup Bootstrap to a User group, as required deployment.
It is done. Now login to the Azure AD joined machine, and let’s see what happen.
- Go to the Access work or school page, Click on Info. (Noticed that this looks different than Hybrid Azure AD joined device)
- Click on Info, then Sync policy
- You should soon see ccmsetup.exe running. Open ccmsetup.log
- After ConfigMgr Client is installed, check LocationServices.log, you should see in the end said “Successfully created context from the raw certificate”
- Check ClientLocation.log, it should said “Workgroup client is in Internet”. Don’t worry about those red error.
- In Configuration manger Properties, Client certificate is Self-signed, Connection Type is Currently Internet.
- Application shows on Software Center, Click Install.
- Check CAS.log, you should see it found content from cloud distribution point. (You need to distribute application content to cloud distribution point)
I have been testing these for over two months now, sometimes it works, sometimes it doesn’t, even today! Maybe because things changes fast and we couldn’t catch up?
So the information is as-is, tested with ConfigMgr TP1711, Windows 10 version 1709 Enterprise. (Nov.23, 2017)
- Content download. As you see above ccmsetup.log, client didn’t download ccmsetup contents from CMG, it downloaded from cloud DP.
- Boundary group. I thought I didn’t need to assign clould DP to any boundary groups and the internet client should have been able to download content from the cloud DP automatically. I was wrong in this case.
Once when I assigned the cloud DP to default site boundary group, it started to work immediately.
This is how it looked before I assigned the cloud DP to the boundary group.
“Failed to get DP locations as the expected version from MP ‘https://SMSBOOTCMG.CLOUDAPP.NET/CCM_Proxy_MutualAuth/7205759xxxxxxx’. Error 0x87d00215
- This is how it looks in Intune after installing ConfigMgr on the Azure AD joined device:
Client02 is Azure AD joined
Client02 is Managed by MDM/ConfigMgr Agen, but See ConfigMgr for Compliance. Because I didn’t add Client02 to Pilot Co-Management collection.
- I add Client02 to Pilot Co-Management collection
- Run ConfigMgr client Machine policy, CoManagementHandler.log will show workload is changed.
- Client02 shows in Intune portal Compliance – Compliant
Hope you enjoy this!
Sandy is an Enterprise Mobility MVP since 2018. She has been working in the IT industry since 2009, primarily dealing with device management solution planning and implementation. Sandy has worked with SCCM, MDT, Group Policy, software packaging, problem solving. Sandy currently works for a large Finnish company with several thousand endpoints as system architect. In 2016, Sandy founded the https://thesccm.com blog and is now a guest blogger on SCConfigMgr.