Deploy Cloud Management Gateway (CMG) on MECM 2002 — Single Wildcard Cert Method
Just some notes on my experience deploying this via the Single Wildcard cert method. This is the simplest, preferred method of deployment. Using your own Internal PKI for this is not inherently “more secure”. It just makes CMG more involved to deploy, and exposes your internal infrastructure to the open web. Enough on that. This is a lab environment, so I don’t mind exposing some of the information for illustrative purposes! I will probably have it torn down in a few weeks and redeployed anyhow.
A Summary of what the single cert method this requires:
Hybrid Join for Devices (Device Registration enabled in on Prem Forest via Azure AD Connect)
Hybrid User Identity(Users being synced to Azure AD from On Prem AD, Password Hash Sync)
Wild Card Certificate for your domain (From GoDaddy, Digicert, etc.)
(an alternative here is to simply create a cert for the cloud app external name. eg. nbcmg2020.nathanblasac.com in this case)
Remember, NO SPECIAL CHARACTERS IN THE SERVICE NAME. Only user Letters and Numbers. Nothing else, period.
My lab domain is nathanblasac.com, so the cert will naturally be *.nathanblasac.com
For example, if my lab domain is labdomain.com, then my wildcard cert will be *.labdomain.com
Also, keep this in mind when dealing with a free trial:
You may have to register resource providers manually in the trial azure subscription.
I had to enable:
Microsoft.ClassicCompute
Microsoft.ClassicNetwork
Microsoft.ClassicStorage
Microsoft.Storage
Azure Subscription — For some notes on expected cost see this article:
Also, you will need an Azure Classic Cloud Service name that is not taken yet: To find one, go to portal.azure.com, click on new resources, and search for Cloud Service. Click Create (You won’t be creating the service, simply checking if the name is available. Once you find one that is not taken, write it down for later use.
For Example:
First, let’s enable Enhanced HTTP Enabled for Site systems to get this out of the way. This is necessary since we won’t be using PKI. Here is a screenshot of what that should look like:
Now Let’s Onboard Azure Services. This will create the needed app registrations in Azure AD.
I named my web app: ConfigMgr — Server App
Native Client App: ConfigMgr — Client App
For the purposes of this lab setup, I left everything default and clicked next.
Sign in with a global admin (or other delegated account) and authenticate.
Also, ensure you go to Azure AD, click on app registrations and approve any permissions related to the newly created app registrations:
Now’s let’s ensure the proper DNS entries are created. You will need one created on prem, and another at the provider level (godaddy, google, etc)
Here is my on prem cname:
Alias name: nbcmg2020
FQDN: nbcmg2020.nathanblasac.com
target host: nbcmg2020.cloudapp.net
Here is my google dns cname:
Before the fun part the actual CMG deployment, let’s get our Wild Card Cert out of the way:
The format of certificate that the CMG/Azure requires is PFX. I used the digicert tool to generate a PFX from my godaddy cert. You’ll need to generate a CSR (Certificate Signing Request). You’ll want to run this Digicert tool on the SCCM server. You can get it here:
You’ll upload/copy the CSR to godaddy or your external CA, and rekey/regenerate your certificate. Then download the cert, and reimport it into the digicert tool.
See instructions here
Now onto the fun part, let’s create the Cloud Management Gateway:
Sign in with your Global Admin (or delegated admin account)
The below settings worked for me. This may or may not work based on your region or needs. Also, you can use an existing resource group, or let the wizard create it for you. Finally, select the amount of CMG VM instances you will require based on expected total clients, etc. One CMG instance supports upto 6000 clients with caveats. More info here:
You may get the below warning when plugging in your wildcard cert. You can safely click ok
Next you have alert config for your CMG. I left the defaults. You will likely want to customize this based on your environment.
Click Next
Verify everything looks correct in your Summary, then click next.
Click OK to complete.
Now Ensure all proper roles are setup, and configuration options on existing roles.
First, the Cloud Management Gateway Connection Point
Go to Servers and Site System Roles, Right Click on your Primary Site, and click on Add Site System Roles.
Click Next, Next, and chose Cloud Management Gateway Connection Point.
Next ensure it lists your Cloud Service Name and Region appropriately
Click Next then you’re done. In about 5–10 minutes you should see the following under Cloud Management Gateway, Connection Points:
Management Point
Now Right Click on your management point and click on properties:
Ensure you check off the “Allow Configuration Manager cloud management gateway traffic” box.
Software Update Point
If you want Software Updates to flow through your CMG then ensure this setting is enabled. “Allow Configuration Manager cloud management gateway traffic”. To get to this setting, right click on your software update point role and click on properties:
Next we will verify Client settings. Specifically, under Cloud Services. These are usually enabled by default at this point, but it’s worth checking:
We are now ready to test our CMG.
I then ran Connection Analyzer to ensure everything was running as expected.
We can force any client to always go to the CMG with the following reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Security
ClientAlwaysOnInternet = 1
However, you also may want to configure your boundaries accordingly to ensure you add the new CMG as a site system and any clients you want to communicate with your CMG can.
Keep in mind this is a small lab setup.
Here is my test client. Notice ClientLocation.log It found the CMG
The client picked up the setting:
We will look at Co-Management, Tenant Attach and Deploying the CM Client via Intune in my next note dump.
