.matrixpost

Marcus Rath

Co-Management with System Center Configuration Manager (SCCM 1910) and Azure Intune

To be able to manage your clients not only with System Center Configuration Manager and internal, you can setup co-management in SCCM.

With co-management you can still manage your clients with SCCM but also with Azure Intune for Mobile Device Management (MDM).

With Intune you can do the following remote actions:

  • Factory reset
  • Selective wipe
  • Delete devices
  • Restart device
  • Fresh start

Futher you can orchestrate with Intune the following workloads:

  • Compliance policies
  • Resource access policies
  • Windows Update policies
  • Endpoint Protection
  • Device configuration
  • Office Click-to-Run apps
  • Mobile apps


But before we setup co-management in SCCM, first we must setup the prerequisites Azure Services and Cloud management gateway in SCCM.

You can also manage clients with SCCM over the internet without a vpn connection and without co-management and intune.

SCCM provides here two ways which will be described below. Cloud management gateway is one of them and also required and a prerequisite for co-management so that clients on the internet can download the SCCM Client and register it to the SCCM Server.




Manage clients on the internet with Configuration Manager

https://docs.microsoft.com/en-us/configmgr/core/clients/manage/manage-clients-internet

Typically in Configuration Manager, most of the managed computers and servers are physically on the same internal network as the site system servers that perform management functions. However, you can manage clients outside your internal network when they are connected to the internet. This ability doesn’t require the clients to connect via VPN to reach the site system servers.

Configuration Manager provides two ways to manage internet-connected clients:

  • Cloud management gateway
  • Internet-based client management


Cloud management gateway

The cloud management gateway provides management of internet-based clients. It uses a combination of a Microsoft Azure cloud service, and a new site system role that communicates with that service. Internet-based clients use the cloud service to communicate with the on-premises Configuration Manager.

Advantages

  • No additional on-premises infrastructure investment required.
  • Does not expose on-premises infrastructure to the internet.
  • Cloud virtual machines that run the service are fully managed by Azure and require no maintenance.
  • Easily set up and configured in the Configuration Manager console.


Disadvantages

  • Cloud subscription cost.
  • Management data sent through cloud service.

For more information, see Plan for cloud management gateway.


Internet-based client management

This method relies on internet-facing site system servers to which clients communicate for management purposes. It requires clients and site system servers to be configured for internet-based management.


Advantages

  • No cloud service dependency.
  • No additional cost associated with a cloud subscription.
  • Full control of servers and roles providing the service.


Disadvantages

  • Require additional infrastructure investment.
  • Overhead and operational cost of additional infrastructure.
  • Infrastructure must be exposed to the internet.

For more information, see Plan for internet-based client management.

How To Configure Internet-Based Client Management (IBCM) in Microsoft SCCM
https://www.youtube.com/watch?v=GbIOxNhJ9lU



Now let’s start with our setup!

Co-management will cover two scenarios:

  • external only Azure AD joined devices auto-enroll into Intune and with Intune deploy the Configuration Manager Client through Cloud Management Gateway to get it enrolled co-managed into Intune and Configuration Manager.
  • internal on-Prem only domain joined devices managed in Configuration Manager will auto-register to Hybrid Azure AD joined and auto-enroll into Intune to be co-managed with Configuration Manager and Intune.


First as mentioned we need to create the Azure Services and the Cloud management gateway.

Setup Cloud Management Gateway (CMG) in Microsoft SCCM
(is now including the Cloud distribution point)

https://www.youtube.com/watch?v=kTOPhVHyZtE



Be sure to enable the following Cloud Services section within the Client Settings.

Allow access to cloud distribution point, otherwise clients won’t be able to download content from the cloud distribution point and internet.

Set Enable clients to use a cloud management gateway to yes. Further check that Automatically register new Windows 10 domain joined devices with Azure Active Directory and Allow access to cloud distribution point is also set to yes.


Configure Azure services for use with Configuration Manager
https://docs.microsoft.com/en-us/configmgr/core/servers/deploy/configure/azure-services-wizard



Here we need to create a web app and a client app which will created in Azure and are responsible for the authentication to on-Premise components. You must use here an Azure global admin account.




At this point you can enable that SCCM can discover cloud identities.




In Azure Active Directory under App registrations you should see the just created two applications.



To enable the applications to communicate with our SCCM Site, we must grant permissions as following.

Modify Default Azure Active Directory Graph Permissions from User.Read to Directory.Read.All for the Client App.







Modify Default Azure Active Directory Graph Permissions from User.Read to Directory.Read.All for the Server App if not still enabled. In my case the permissions was per default to Directory.Read.All





Now let us create the Cloud Management Gateway (CMG).




Login again with your global Azure admin account which also have to be an owner of the subscription.


Here you configure the cloud management gateway settings. The first thing to do here, is to upload the webserver (IIS) certificate for our VM Instance in Azure which represents the cloud management gateway. Therefore you must upload an *.pfx File which contains not only the certificate with the public key but also the private key.

In my case I use a wildcard certificate, so I must also specify the sudomain of the service name, in my case cmg.

Please be aware that the subdomain must be unique as you get a domain in the public cloudapp.net domain space. The setup assistant will unfortunately not verify this. Also the local logs on the SCCM will not warn you about this. The only way to see if the demployment fails because of a subdomain which is in use by someone else is at the Activity log in Azure for the ressource group or cloud service. I will show you this logs later at troubleshooting.




The external FQDN for this Cloud Service is the subdomain you put in + cloudapp.net.


cmg.cloudapp.net

So you have to create a CNAME record at your DNS provider who points this internal Service Name FQDN to the public Cloud Instance FQDN.





In the above configuration I forgot one thing, if we use certificates from our internal PKI for the clients certificates to authenticate against the CMG, we also must tell the Cloud Management Gateway (the VM Instance with IIS) that he should trust this PKI.

We can add the root certificate on the properties of the created CMG.


You have to wait a couple of minutes till the VM Instance is created.





Troubleshooting if deployment fails.

You will find the logs of the Cloud Management Gateway in the installation directory of SCCM and there under Logs you will find the CloudMgr.log file.

To view the Logs you can use a normal text editor but better use the SCCM Trace Log Tool
in the tools directory from SCCM.


Furhter you can check the Logs in Azure under Activity log of the cloud service or resource group.


As I told you that you must use an unique subdomain for the cloud management gateway, you can see here in the Activity log of the ressource group, that my subdomain cmg is already in use, which is not really suprising. 😊

In the local logs I only get error messages like

WARNING: Exception Hyak.Common.CloudException:Failed to start deployment slot

ERROR: Exception occured for service bccmg : Hyak.Common.CloudException: Failed to start deployment slot at Microsoft.ConfigurationManager.AzureManagement.ResourceManager.GetStorageServiceKey(String resourceGroupName, String storageServiceName)at Microsoft.ConfigurationManager.CloudServicesManager.AnalyticsCollectionTask.Start(Object taskState).


But in the end only the DNS name (subdomain) cmg was already in use. Error Messages like the above also appears if you have missing API permissions of the server and client app. Don’t forget to set them to Directory.Read.All as mentioned above.

Now we come to the configuration of the cloud management gateway connection point. This will act as proxy between the CMG in Azure (VM) and the management point and software update point in SCCM. Therefore external client can use this channel for things like scanning and getting policies.

So go to Site ConfigurationServers and Site System Roles and add the Site System Role Cloud management gateway connection point for your primary site server.







You can see that it automatically detect the CMG instance from Azure here.




Now we must enable that Management point and Software update point can use the cloud management gateway and therefore the CMG VM in Azure is using it for the external clients to establish a connection to our SCCM site.

So open the properties from the Management point. Check that Client connections use HTTPS and check Allow Configuration Manager cloud management gateway traffic.

Under https://www.youtube.com/watch?v=nChKKM9APAQ you will see step by step how to configure SCCM to use HTTPS/PKI.


We also must define for the Software update point to allow the cloud management gateway. So be sure to check the Allow Configuration Manager cloud management gateway traffic.


Now we must distribute all applications which should be accessible from the internet to the new CMG distribution point.






After finishing the setup of the cloud management gateway, you should see at the clients the new internet-based management point (FQDN) in the properties of the configuration manager.


Be aware that it can take up to 24 hours, till you see this management point in the client. By default every 24 hours the client is going to do a content locator or a location request.

To speed things up and this will kick in immediately you can restart the SMS Agent Host service on the client.

About SMS Agent Host service 

Ccmexec.exe and Smsexec.exe are the processes for the agent for Microsoft Systems Management Server (SMS). The executable for the agent should not be on your computer unless you have SMS deployed. If you stop the service it will no longer report back to the SMS server. The newer versions of the Systems Management Server (SMS) are called System Center Configuration Manager (SCCM).



Further you can check the ClientLocation.log on the Client in the folder C:\Windows\CCM\Logs\


To check the logs on the client you can also use the Configuration Manager Trace Log Tool which is also available at the client in the folder C:\Windows\CCM\CMTrace.exe


Here you can see that it picked up the new management point.


If you want to check if the client is talking to the internal or external management point, you can view the CcmMessaging.log. Here you can see that the client is talking to the internal management point.


Now I checked my external internet clients to which they talking. Unfortunately I saw that they couldn’t connect to the external management point.


For troubleshooting I enabled Remote Desktop for the cloud service with the CMG VM instance.








At this point the RDP connection is stucking. So it needs a restart.


After the restart I could connect with RDP into the CMG VM instance of the Cloud management gateway.

First thing here is to determine where the CMG components are installed, so open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\CMGSetup

Here you can see that it is in the E:\approot\ folder




To check what happens here, first I copied the CMTrace.exe Tool into the CMG VM over RDP.

As you see above the logfiles are located under E:\approot\logs. To check if the CMG components are running you can dig into the CMGService log.


That looks good!


Next is checking the IIS logs.


From the IIS Logs I can’t see any error.

So I checked the CcmMessaging.log again and now it looks good. I suppose the restart of the CMG VM was the solution. Now the client can talk to the external management point.




Now after finishing the setup of the Azure Services and Cloud management gateway, we finally can configure and setup co-management in SCCM.

How to Set Up Co-Management in Microsoft SCCM
https://www.youtube.com/watch?v=rTapalSHv6U


First check some prerequisites for co-management in Azure under Azure Active DirectoryDevicesDevice Settings.

Users must be able to join devices to Azure AD, so switch to All or Selected and add the users who should be able to join.



Also check under Azure Active DirectoryMobility (MDM and MAM)Microsoft Intune, that users are able to auto-enroll into Intune.

https://docs.microsoft.com/en-us/mem/intune/enrollment/windows-enroll#enable-windows-10-automatic-enrollment



Users must be able to auto-enroll into Intune, so switch to All or Some at MDM user scope and add the users who should be able to auto-enroll into Intune.


For BYOD devices, the MAM user scope takes precedence if both MAM user scope and MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users). The device will use Windows Information Protection (WIP) Policies (if you configured them) rather than being MDM enrolled.

For corporate devices, the MDM user scope takes precedence if both scopes are enabled. The devices get MDM enrolled.



To get devices auto-enroll into Intune, the user also needs an enabled license. In my case you see the Enterprise Mobility + Security E3 licence which also includes Intune and a separate Intune licence.






After checking all prerequisites we can start setup co-management in SCCM. So goto AdministrationCloud Servicesco-management





Before enrolling Intune to all clients you can first use a Pilot Group with a few clients to do some testing.

You can see here the previously created Cloud management gateway in the comman line. You need to copy the command line and upload it into Intune as an application for the MDM Agent on the client in the internet to know how to enroll back to our site through the cloud management gateway over the internet.

So copy this for later!

For Intune auto-enrollment the clients must be windows 10 1709 or later.

Internal only on-Prem domain joined devices first needs to auto-register to Hybrid Azure AD joined .



Next you can set which workloads should be handled from Intune.





Now we must create the Intune App mentioned above so that the clients on the internet can enroll and register through the cloud management gateway. Therfore the app will deploy the Configuration Manger including the management point URL to the external internet clients.

Create a Line-of-business app


Upload the Configuration Manager MSI File located on the SCCM Server in the installation directory under \bin\i386\ccmsetup.msi


Also insert the CMG command line arguments which we copied above.




After uploading the app you must assign a group or users to which it should deployed.



As mentioned already at the beginning, with co-management we have two scenarios:

  • 1. external only Azure AD joined devices auto-enroll into Intune and with Intune deploy the Configuration Manager Client through Cloud Management Gateway to get it enrolled co-managed into Intune and Configuration Manager.
  • 2. internal on-Prem only domain joined devices managed in Configuration Manager will auto-register to Hybrid Azure AD joined and auto-enroll into Intune to be co-managed with Configuration Manager and Intune.


If you now join a new device from external to Azure AD (Scenario 1 – external client) with an user who is in the MDM user scope, the client is auto-enrolled into Intunes and the Configuration Manager client will be downloaded and installed on the client over the previous created Line-of-business app.


You can also check this process in the ClientIDManagerStartup.log file under C:\Windows\CCM\Logs

Here you can see the Configuration Manager values from an external Azure AD joined computer.

Co-management is enabled and the Co-management capabilities are set to 1.


Co-management capabilities: 1 means that there are no workloads in Intune enabled for this device. This is because at the moment I use a pilot group/collection on which the workloads are enabled and assigned to ConfigMgr or Intune and this external Azure AD joined device with the hostname xps15 is not assgined to this pilot group/collection.

Summary of values which shows what workloads enabled in ConfigMgr or Intune


ValueConfigMgrIntune
1 (0x1)Compliance policies, Resource access policies, Windows update policiesNo Workloads
3 (0x3)Resource access policies, Windows Update policiesCompliance policies
5 (0x5)Compliance policies, Windows Update policiesResource access policies
7 (0x7)Windows Update policiesCompliance policies, Resource access policies
17 (0x11)Compliance policies, Resource access policiesWindows Update policies
19 (0x13)Resource access policiesCompliance policies, Windows Update policies
21 (0x15)Compliance policiesResource access policies, Windows Update policies
23 (0x17)No WorkloadsCompliance policies, Resource access policies, Windows Update policies




So I added the device to my pilot collection MDM Intune on which compliance policies workload over Intune is enabled.


After a few minutes later or after a restart we check the Co-management capabilities value again and now it is switched to 3 for compliance policies workload managed by Intune which is correct.


You can now manage this device with ConfigMgr or Intune. For Intune you can use the new Microsoft Endpoint Manager admin center portal under the URL https://endpoint.microsoft.com/






Or Intune itself in the Azure Portal


If the device is enrolled into Intune you can also see under SettingsAccountsAccess work or school an info button at the Azure AD connection. This will show the Intune MDM connection.





You can also check the device registration state with Azure and the command-line tool dsregcmd.exe located in C:\Windows\system32




Now we come to Scenario 2 – internal on-Prem only domain joined devices and auto-registered to Hybrid Azure AD joined

To be able to auto-enroll into Intune, the internal domain joined windows 10 devices first have to register into Azure AD (Hybrid Azure AD joined). This can be automated through the Configuration Manager Client Settings in SCCM.

Therefore we enabled at the beginning under the Cloud Services section from the Client Settings Automatically register new Windows 10 domain joined devices with Azure Active Directory and set it to yes. Also the other two options we set to yes.


To check if an internal domain joined device is registered automatically with Azure AD and therefore in Join Type Hybrid Azure AD joined, you can goto the Azure Portal under Azure Active Directory – Devices – All devices and search for the device.

But before the device will be shown in Azure, we first have to tune our Azure AD Connect settings to be sure, that not only on-Prem Active Directory users will be synchronized to Azure AD but also the on-Prem Active Directory domain joined windows 10 computers.


So open the Azure AD Connect Tool.


First we must customize the synchronization options


Select your OUs with the users and computers you want to synchronize to Azure AD.


Also we need to configure the device options to configure device registration (Hybrid Azure AD join) and synchronisation (device writeback)




Check the Forest and add an Enterprise Admin Account in order to create an additional service connection point (SCP) in your on-Prem Active Directory who points to your Azure AD. Therefore your internal on-Prem computers will automatically discover your Azure AD.





Now if this device is in our Intune Auto Enrollment Collection in SCCM, the device will be enrolled into Intune.


Please be aware that this process will take some time. Under Devices and in my case the Intune Auto Enrollment Collection MDM Intune you can see my Hybrid Azure AD joined device BRAIN51. Co-managed is enabled.


On the Hybrid Azure AD joined client you will see the following settings.





That’s it!




Azure AD registered vs Azure AD joined vs Hybrid Azure AD joined

https://docs.microsoft.com/en-us/azure/active-directory/devices/overview

  • Azure AD registered
    • Devices that are Azure AD registered are typically personally owned or mobile devices, and are signed in with a personal Microsoft account or another local account.
      • Windows 10
      • iOS
      • Android
      • MacOS
  • Azure AD joined
    • Devices that are Azure AD joined are owned by an organization, and are signed in with an Azure AD account belonging to that organization. They exist only in the cloud.
      • Windows 10
      • Windows Server 2019 (Server core is not supported)
  • Hybrid Azure AD joined
    • Devices that are hybrid Azure AD joined are owned by an organization, and are signed in with an Azure AD account belonging to that organization. They exist in the cloud and on-premises.
      • Windows 7, 8.1, or 10
      • Windows Server 2008 or newer



Links

Official product documentation for Microsoft Intune https://docs.microsoft.com/en-us/mem/intune/

CCMClean – Uninstalling Configuration Manager Clients https://blog.techygeekshome.info/2013/11/ccmclean-uninstalling-configuration-manager-clients/

SET UP HTTPS CLIENT COMMUNICATION WITH SCCM
https://gmarculescu.com/?p=81

How can I configure System Center Configuration Manager in HTTPS mode (PKI) – Part 1
https://www.windows-noob.com/forums/topic/16300-how-can-i-configure-system-center-configuration-manager-in-https-mode-pki-part-1/

How can I configure System Center Configuration Manager in HTTPS mode (PKI) – Part 2
https://www.windows-noob.com/forums/topic/16301-how-can-i-configure-system-center-configuration-manager-in-https-mode-pki-part-2/

PKI certificate requirements for Configuration Manager
https://docs.microsoft.com/en-us/configmgr/core/plan-design/network/pki-certificate-requirements

Apps registration API permissions co-management
https://techcommunity.microsoft.com/t5/premier-field-engineering/importing-apps-to-set-up-cloud-management-gateway-cmg-for/ba-p/740011

How To Configure Microsoft SCCM to Use HTTPS/PKI
https://www.youtube.com/watch?v=nChKKM9APAQ

How to Set Up Co-Management in Microsoft SCCM
https://www.youtube.com/watch?v=rTapalSHv6U

How To Setup Cloud Management Gateway (CMG) in Microsoft SCCM
https://www.youtube.com/watch?v=kTOPhVHyZtE

Part 7 Cloud Management Gateway – ConfigMgr CB and the Microsoft cloud platform
https://www.youtube.com/watch?v=Ti6CNRcaUkQ

Part 11 Co-management – ConfigMgr CB and the Microsoft cloud platform
https://www.youtube.com/watch?v=6ZNMQsJXY9E

Troubleshooting MDM Enrollment https://social.technet.microsoft.com/Forums/en-US/66902c9e-9337-47a1-8bab-ea25043934a7/azure-ad-registered-ampampamp-hybrid-aad-joined-but-no-mdm?forum=microsoftintuneprod

Configuring Intune MDM User Scope and MAM User Scope for Windows 10
https://allthingscloud.blog/configuring-intune-mdm-user-scope-and-mam-user-scope/

Windows 10 Intune enrollment methods
https://www.petervanderwoude.nl/post/tag/configmgr/

Leave a Reply

Your email address will not be published. Required fields are marked *