Cloud management gateway (CMG) helps you to manage the configuration manager clients on the internet without any additional on-premise infrastructure.
Due to COVID-19, most of the workforce is working from home (with/without VPN), and managing the endpoints using Cloud Management Gateway (CMG) is immense. Many organizations have already implemented the CMG to manage the windows devices that are connected outside the office network or connected to an office network using VPN.
If you are yet to implement the cloud management gateway service in your organization and need assistance, please check here.
Implementation of CMG involves server authentication certification (PKI or Public) and client authentication (optional).
The server authentication certification is required to build a secure channel with CMG cloud service and the CMG cloud service creates an HTTPS service to which internet-based clients connect.
The server authentication certificate can be either public key infrastructure (PKI) or public providers such as DigiCert or other global providers.
Microsoft recommends public and globally trusted certificate provider but again, it depends on the organization to use PKI or public cert.
For more information about the Cloud Management Gateway choices, please refer Jason post here
Issue description:
I recently had a requirement to convert or redeploy the CMG cloud service from PKI to public cert.
If you want to make changes to the following configurations, then you need to consider to redeploy the CMG service.
- Classic deployment method to Azure Resource Manager
- Subscription
- Service name
- Private to public PKI
- Region
So how do you convert the existing CMG cloud service from PKI to public cert or redeploy the CMG cloud service?
Since the existing cloud service uses cloudapp.net and this domain is managed by Microsoft, we don’t a public cert matching that name.
The only possibility is to add another CMG cloud service with public cert and wait for the clients to be aware of the new CMG instance (both intranet and internet) before deleting the CMG with PKI.
In this blog post, I am going to use a certificate from DigiCert. There are various global trust providers, so please choose based on your organizational needs.
I recently published a blog post on how to secure a server authentication certificate for Cloud management gateway cloud service from DigiCert. For more details, please refer here.
This blog post assumes that you already have a server authentication certificate from a public provider. The server authentication certificate format should be .pfx and no other formats are supported at the time of writing this blog post.
How to verify if the CMG service is configured with PKI or public cert?
In the SCCM console, go to administration node, cloud services, cloud management gateway, on the right side, you will see service name ends with .cloudapp.net
Existing lab setup:
A very simple and plain hierarchy with 1 primary site hosted with SQL (server A) and all client-facing roles such as MP, SUP, DP, etc for intranet clients.
The site is enabled with eHTTP and I don’t use client authentication certs.
CMG cloud service is created with PKI cert.
CMG connection point, MP, and SUP for internet facing are installed on server B. This is to isolate from intranet clients and internet clients.
Build version is 2002 which means, all my clients can make use of token-based authentication.
In addition to token-based, I have also hybrid AAD/AAD, so clients have the option to choose one of the authentication methods (Token/Hybrid AAD/AAD) with CMG cloud service.
Server B (SG-CM02) hosts the CMG CP, MP, and SUP roles.
You can create multiple CMG services in Azure, and you can create multiple CMG connection points. Multiple CMG connection points provide load balancing of client traffic from the CMG to the on-premises roles.
With the existing SCCM setup that I have, I am able to manage both internal clients and also internet-based clients successfully.
How to redeploy the CMG service using the public cert?
Since we already acquired the public cert, we will setup the new cloud service. For this, follow the Microsoft article. This is very straight forward and all the instructions available in the documentation.
As you can see, the service name does not contain .cloudapp.net
After a while, you will see that the configuration update completed.
To troubleshoot CMG deployments, use CloudMgr.log and CMGSetup.log on your site server logs.
We now have 2 CMG cloud services, but we have only 1 CMG connection point installed on server B and this CMG CP is linked to PKI cloud service.
Do not make any changes to the existing CMG CP in the dropdown selection. Just leave it. If you make any changes, it is going to impact the clients and internet-based clients are cannot communicate .
It is recommended to keep at least one active CMG for internet-based clients to receive an updated policy.
Until now, we created a new CMG service with public CA but we do not have a CMG CP linked to the new CMG service. This is must for clients to be aware of the new CMG service.
At this point, on an intranet or internet client, run the following PowerShell command to see the internet MP details.
(Get-WmiObject -Namespace Root\Ccm\LocationServices -Class SMS_ActiveMPCandidate | Where-Object {$_.Type -eq "Internet"}).MP
As you can see, I have only 1 active MP which is PKI cloud service.
For clients to be aware of the 2nd cloud service that we recently created, we need to create additional CMG CP.
For this, build a new server or use the existing server to host additional CMG CP and link this with the new CMG cloud server (public CA).
From the console, Add a new site system role and select the CMG CP role.
In the cloud management gateway name, select the instance that we created with public cert (not with cloudapp.net).
Click next and finish.
To troubleshoot CMG service health, use CMGService.log and SMS_Cloud_ProxyConnector.log on the site server.
As you can see, we now have two CMG connection points and we have only 1 CMG MP.
We can also use CMG connection analyzer for real-time verification to aid troubleshooting.
The in-console utility checks the current status of the service, and the communication channel through the CMG connection point to any management points that allow CMG traffic.
As you can see below, the CMG channel for Management point is with server B. As I described in the beginning, server B (SG-CM02) holds the MP and SUP for internet facing clients.
At this point, we have 2 cloud services, 2 CMG CP and 1 MP, SUP to support internet-based clients. The internet support MP and SUP can be on any server and is independent of the CMG CP role.
Both intranet and internet clients will get the location of this new CMG service automatically in the next location request (every 24 hours) or when the SMS agent host service started.
Since we already have the working CMG, clients that are on the internet will receive information about the new CMG service in the above conditions.
As we are doing it in the lab, I don’t want to wait for longer, and to make this faster, restart the SMS agent host service on the internet-based client.
After the service restarted, wait for a few mins before we read the locationservices.log file.
As you can see in the log, the client has picked the new CMG cloud service.
Running the PowerShell script on the client shows that, there are 2 CMG cloud services that clients can pick any of them randomly for communication.
(Get-WmiObject -Namespace Root\Ccm\LocationServices -Class SMS_ActiveMPCandidate | Where-Object {$_.Type -eq "Internet"}).MP
Likewise, all the intranet and internet-based clients will know about the new CMG instance before we proceed to delete the old CMG instance. For this, we can probably wait for a couple of weeks assuming the device connects at least once to the internet to receive the new CMG info using the old CMG proxy.
If the old CMG service is removed, clients cannot communicate with the old CMG service to receive any new policies to get the information about the new CMG service.
If the internet clients are offline for a longer period and if they are not aware of the new CMG instance, then they can't communicate with a removed CMG and they must roam back to the intranet to know about the new CMG or reinstall the client with /mp parameter to specify the CMG's URL.
It is also important to distribute the content to the new cloud DP so that clients can get the location request from the CMG MP.
Now we will go back to SCCM console and do a search filter in the devices section with CMG proxy.
As you can see below, I have one device which is talking to new CMG service (online) and 2 devices were talking to old CMG service (offline).
It is good that we have got the new CMG service running and clients that are connected to the internet able to communicate with old CMG service, have got the information about new CMG service, but how do I know that all of my internet-based clients are aware of the new CMG service?
For this, you can create a collection or report based on the client's last policy request or hardware inventory or when was it last time online.
When you plan to delete the old CMG service, do not delete anything directly on the Azure portal, simply go to SCCM console and select the CMG instance and right click and delete. This will delete the VM instance, cloud DP and all other components from the Azure portal.
After you delete the old CMG instance, the clients that are aware of the new CMG service, they will automatically pick it upand continue to communicate . You don’t have to do anything for this, but clients that are not aware of the new CMG instance, must roam back to an intranet or install the client using internet-based client switches.
I hope this post has been informative for you.
The following are some of the blog posts on CMG for your reference:
Cloud Management Gateway Community Session with the Patch My PC Team
Managing remote machines with cloud management gateway in Microsoft Endpoint Configuration Manager
Managing Patch Tuesday with Configuration Manager in a remote work world
Mastering Configuration Manager Bandwidth limitations for VPN connected Clients
Get Azure IP Ranges for Your Cloud Management Gateway
Forcing Configuration Manager VPN Clients to get patches from Microsoft Update
Real-world costs for using a Cloud Management Gateway (CMG) with ConfigMgr