Managing client systems over the Internet has never been easy for enterprises. Expensive infrastructure is often required, and there’s always the risk of exposing a greater footprint for your corporate network on the Internet. This has now changed in the Current Branch of Microsoft System Center Configuration Manager (SCCM) with the introduction of a new feature called Cloud Management Gateway (CMG). To learn more about it I’ve asked Gerry Hampson an expert in the field to provide us with a brief overview of the features, benefits, use cases and costs of CMG. Gerry is a Senior Consultant for Ergo Group based in Dublin, Ireland, and is a specialist in Microsoft consultancy and implementations, particularly in the area of enterprise client management. He has co-authored a number of books on System Center Configuration Manager, most recently the latest in the ConfigMgr Unleashed series. Gerry was first awarded Microsoft MVP in 2015 and is a regular speaker at MMS. Gerry has a blog called Gerry Hampson Device Management, and you can also find him on Twitter @GerryHampson.
Microsoft System Center Configuration Manager (Current Branch) is the industry leader in systems management. It allows organizations to manage their server and desktop estates centrally and provides functionality such as operating system deployment, software update patching, software distribution and inventory.
In 2018, Microsoft added the Cloud Management Gateway role to SCCM. With this revolutionary new feature, organizations can now manage SCCM clients over the Internet without the need for a VPN back to the corporate network.
That’s nothing new, I hear you say. We can do that already using SCCM Internet-based client management (IBCM). That is true. IBCM has been around for many years and is a good technology, before it’s time in a way. For IBCM we would configure secure Internet-facing site systems so that Internet-based clients could communicate. Unfortunately, there were some disadvantages with this solution:
Now we can use the Cloud Management Gateway to manage these clients. It consists of a Microsoft Azure cloud service and an SCCM site system role that communicates with that Azure service. Internet clients can then use the Azure service to communicate with SCCM. This is amazing technology and gives us many advantages over traditional Internet-based client management.
There are a few points to note, though.
These are three typical CMG scenarios. The first is the most common scenario. We can manage our Active Directory-joined Windows clients over the Internet. Windows 7, Windows 8.1 and Windows 10 devices are supported with the communication channel secured by PKI certificates. The easiest way to do this is with an internal Certificate Authority with the devices configured for auto-enrollment.
Secondly, we can manage Azure AD-joined Windows 10 devices. In this case we can use Azure Active Directory to authenticate rather than PKI. It’s easier to set up and maintain this scenario, but it only supports Windows 10.
Finally, CMG allows us to install the Configuration Manager client on Windows 10 devices over the Internet.
The CMG allows us to manage the following over the Internet:
You can deploy multiple CMG instances in an SCCM hierarchy. Microsoft recommends creating at least two instances for high availability. Each CMG instance supports up to 96,000 clients. This isn’t a hard limit. These are simultaneous connections and performance starts to degrade if you go higher.
Currently, the Cloud Management Gateway supports the management point and software update point roles. But what a great start that is. This would allow you to keep all your Internet-based clients fully patched. As a bonus, in conjunction with a cloud Distribution Point, you can deploy software to these clients over the Internet. The cloud DP and CMG can be co-located at no extra cost.
Cost is an important factor to consider when planning a CMG deployment. Charges will be incurred on the Azure subscription. However, I have deployed a CMG for several customers and the cost has proven to be minimal. Several elements contribute to the cost.
Virtual machine — The first cost element is for Azure virtual machines. An Azure standard_A2 Virtual machine is created automatically when you deploy a CMG. The default is 1, but you can select up to 16 VMs. Each VM supports up to 6,000 clients, hence the supported total of 96,000. It’s important to note that Azure Virtual machine costs vary by region. Microsoft publishes an Azure pricing calculator to help determine potential costs.
Outbound data transfer — You are charged for data egress. This is data flowing out of the service. Microsoft estimates that to be approximately 100MB to 300MB per client per month for Internet-based client refreshing policy every hour. Other actions like deploying applications will increase the amount of outbound data transfer from Azure.
Content storage — Internet-based clients managed with the Cloud Management Gateway get software update content directly from Windows Updates and there is no charge for content storage. All other content (applications, for example) must be distributed to a cloud-based distribution point. And if you are worried about the cost, you can also create alerts to notify you when the CMG traffic reaches a certain data threshold.
In the SCCM console, you can monitor clients and network traffic. The cloud management dashboard provides a centralized view for CMG usage:
The dashboard also displays data about cloud users and devices:
I highly recommend the Cloud Management Gateway and my customers love it because:
I hope you find this information useful.
Featured image: Shutterstock
If you want to check VM sizes available to any given region, Azure Portal is…
If you have open network shares on your network, you are opening the door to…
A spear-phishing email has resulted in a U.S. gas pipeline ransomware attack. Making the attack…
To really lower your Azure costs, you need actionable information. Get info on flexibility groups…
Data stolen from breaches often live on forever, as appears to be the case with…
If you have set up an Azure DevOps Wiki, there are two ways to organize…