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;

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.

IMPORTANT:

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.

  1. Click on Intune – Device configuration – Profiles – Create profile

  2. Fill out the following information, and add you Root CA to computer certificate store – Root

  3. Assigned the profile to users and devices.

Prepare ConfigMgr client installation

  1. Copy ccmsetup.msi from “Your ConfigMgr installation path\bin\i386” to another folder, example: D:\ConfigMgr
  2. Log on Azure Portal
  3. Browse Microsoft IntueMobile apps – Apps, Click on Add

  4. Choose App type: Line-of-business app

  5. Click on App package file – Select file.
    Browse the folder where you save the ccmsetup.msi, and add it.
    Click OK.

  6. Prepare ConfigMgr client installation command-line
    You can copy those command line arguments from Co-management properties.

    Command-line arguments:

    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

  7. Click on App informationConfigure, input Command-line arguments:

  8. Click OK, then Add.
  9. 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.

  1. Go to the Access work or school page, Click on Info. (Noticed that this looks different than Hybrid Azure AD joined device)

  2. Click on Info, then Sync policy
  3. You should soon see ccmsetup.exe running. Open ccmsetup.log

  4. After ConfigMgr Client is installed, check LocationServices.log, you should see in the end said “Successfully created context from the raw certificate”

  5. Check ClientLocation.log, it should said “Workgroup client is in Internet”. Don’t worry about those red error.

  6. In Configuration manger Properties, Client certificate is Self-signed, Connection Type is Currently Internet.

  7. Application shows on Software Center, Click Install.
  8. Check CAS.log, you should see it found content from cloud distribution point. (You need to distribute application content to cloud distribution point)

 

NOTE:

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)

  1. Content download. As you see above ccmsetup.log, client didn’t download ccmsetup contents from CMG, it downloaded from cloud DP.
  2. 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

 

Co-Management:

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

  2. I add Client02 to Pilot Co-Management collection
  3. Run ConfigMgr client Machine policy, CoManagementHandler.log will show workload is changed.

  4. Client02 shows in Intune portal Compliance – Compliant

Hope you enjoy this!

(6131)

Sandy has been working in the IT industry since 2009. Primarily dealing with SCCM, MDT, Group Policy, software packaging, workstation problem solving. Sandy currently works for a large Finnish company with several thousand endpoints. In 2016, Sandy founded the http://thesccm.com blog and is now a guest blogger on SCConfigMgr.

comments
  • PhilB
    Posted at 10:30 April 26, 2018
    PhilB
    Reply
    Author

    In MDM/Intune Scenario… Do you need to upgrade your Client Setup App (ccmsetup.msi) each time you upgrade your SiteServer to a new CB (from 1710 to 1803 for example) ?

    • Zeng Yinghua
      Posted at 21:44 May 1, 2018
      Zeng Yinghua
      Reply
      Author

      I upgrade my ccmsetup.msi everytime. It’s not mention in any official doc, but that’s how I do, always make sure machines gets same version client as server, because new feature won’t work if client is not updated.

    • Nickolaj Andersen
      Posted at 12:03 May 16, 2018
      Nickolaj Andersen
      Reply
      Author

      Hi Phil,

      Since the ccmsetup.msi is basically just a boot-strapper, I’d say that it’s safe to not update it whenever there’s a new servicing release available. It’ll pull down the latest staged version of the ConfigMgr Client (ccmsetup.exe) and run that. However, it might be a good idea to once in a while make sure it’s up-to-date.

      Regards,
      Nickolaj

  • Wouter
    Posted at 12:56 May 18, 2018
    Wouter
    Reply
    Author

    Hi,

    Earlier this year i tested co-management and it worked really well. Now after a new install all software is pushed from intune (Office, CompanyPortal) only the sccm client won’t install. The strange thing is, when i use the command from the app information (ccmsetup.msi) out of the intune console, directly on the machine where the client won’t install. It will be installed fine. Only not directly from Intune

    Regards,
    Wouter

  • Henki
    Posted at 16:24 May 29, 2018
    Henki
    Reply
    Author

    Hello Zeng

    Congrat’s for your great blog, that helps me a lot. But i have a (simple) question about an on-premise SCCM infra where i want to use Co-management.

    Are the PKI certificate mandatory ? i mean, i have already an infrastructure where SCCM & W10 is working but if i propose the co-management, i wanted just to add the co-management function but after searching everywhere (on google) it’s not very clear that i can only use co-management without PKI.

    • Zeng Yinghua
      Posted at 10:41 May 30, 2018
      Zeng Yinghua
      Reply
      Author

      Hello Henki.

      Co-Management feature itself doesn’t not required setup PKI. For now PKI certificate is mandatory for Cloud management gateway with Mangement Point, not Co-management itself.
      How ever, many people would like to use Cloud Distribution Point and cloud management gateway together with co-management, that’s why has mentioned used PKI. These three features are not dependence of each other.

      In Technical Preview 1805, there are some new changes about PKI for CMG with Management point, but I am not sure when will they come to production or will they. See more details here. https://docs.microsoft.com/en-us/sccm/core/get-started/capabilities-in-technical-preview-1805#improved-secure-client-communications

      • Henki
        Posted at 15:27 May 30, 2018
        Henki
        Reply
        Author

        Thank you very much !!! one last question : does the Cloud Management Gateway mandatory for Co management SCCM feature ?

        • Zeng Yinghua
          Posted at 20:31 May 30, 2018
          Zeng Yinghua
          Reply
          Author

          Co-Management is that you can use ConfigMgr and Intune to manage Windows 10 machines. Cloud management gateway is like a proxy, it let machine can communicate with ConfigMgr over internet without VPN. Cloud distribution point is a distribution point in Azure. Mandatory or not, it just depends on your environment.

          1. If you want your domain joined machines can be managed by ConfigMgr and Intune from internet without VPN, you will need Co-Management, CMG and CDP.
          2. If deploy ConfigMgr client to Azure AD joined machines, you will need Co-Management, CMG and CDP. (I suppose those Azure AD joined machines are not using VPN)
          3. If your domain joined machine are always using VPN (like mandatory VPN, always on VPN), then you don’t need CMG or CDP for co-management.

          Hope I explain these clearly. šŸ™‚

          • Henki
            Posted at 21:50 June 1, 2018
            Henki
            Author

            Very clear and thank you VERY MUCH !!
            Using the 1802 of SCCM with Windows 10 v1803, i succeed to make co management work with AND without PKI !!!
            Right now :
            – If i plan to use PKI, just follow your guide letter by letter šŸ˜€
            – if i plan not to use PKI, i have done a lot of experimentation and what i may remind is to keep some points

            But maybe one or two points about Hybrid join :
            – I have configured on my DC, the device Writeback with AD Connect
            – if not using PKI, it seems the CMG is not necessary and the only thing we may have to use is the Azure Service (+ co management) on SCCM console.

  • Rob
    Posted at 21:47 September 20, 2018
    Rob
    Reply
    Author

    I can’t get this to work. My log is full of SSL and certificate errors and eventualy the following error pops up:

    CcmSetup failed with error code 0x87d00455

    I can’t find any info about this error.

    The clients are Hyper-V VM’s with Windows 10 1803. I followed this total guide multiple times now and always got this error… hope someone can shed a light on this.

  • Maarten
    Posted at 14:28 October 18, 2018
    Maarten
    Reply
    Author

    Hi,

    I’ve followed your instrunction and it helped me a lot. But now we are installing the client to the internet clients by intune.

    But the logging keeps nagging me with the install failure

    client certificate is not provided. ccmsetup 18/10/2018 11:39:45 4184 (0x1058)

    When i try to manually open the CMG url over HTTPS it tries to authorize thru a certificat.

    Do you know what goes wrong? or why i don’t get a client certificate on the machine?

  • Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.