Managing remote machines with cloud management gateway in Microsoft Endpoint Configuration Manager

In light of the global situation that has escalated over the past weeks regarding COVID-19 and the coronavirus; there has been a significant increase in the number people working from home. Indeed, myself and the rest of the Microsoft Endpoint Manager team are among 100,000+ Redmond based Microsoft employees who are entering our third week of remote work.

This increase in the global workforce working from home is unsurprisingly putting an added focus from organizations on remote functionality and management. Not to mention an increased load and strain on services that were implemented to accommodate lower concurrent numbers of remote working employees.

Naturally we have seen an increase in the number of queries, questions and tweets around the tools and features Microsoft Endpoint Manager can offer in the way of remote management of the workforce. One of the most common topics I have had to field enquiries is around the use of cloud management gateway (CMG), usually in conjunction with keeping traffic off the .

Firstly, let's clarify some terms….

Internet-based client management is a longstanding concept in Configuration Manager whereby servers are placed in the DMZ and published to the Internet to allow clients to continue to be managed when roaming on the Internet.

Cloud management gateway, or as I shall refer to it in the rest of the blog, CMG for short, is a cloud service hosted in Azure that acts as a proxy for clients. It greatly simplifies the configuration required to manage clients on the Internet.

The final concept is cloud distribution point, also a cloud service hosted in Azure, that allows clients to retrieve content. For the purposes of simplicity, and because cloud distribution point has been deprecated in favor of enabling content distribution from a CMG, I will use the term “CMG” to refer to a content-enabled cloud management gateway for the remainder of this blog

Secondly, let's talk about why clients will potentially still communicate over the when a CMG is deployed. Essentially, the Configuration Manager client has logic that looks at several factors, including being able to resolve a management point and the internal domain. When these factors are not met, the client will evaluate as IsInternet=1 and will communicate with resources published to the Internet.  When a client is connected to a it is likely that the client will meet enough criteria to consider itself IsInternet=0 which is why client traffic will go over the VPN and not the Internet even if split tunneling is configured to allow direct Internet traffic.

NOTE: Everything in this blog will require a split-tunnel VPN. If all the traffic is directed back to the corporate by the VPN client, then even if the Configuration Manager client is ultimately going out to cloud services, it won't be alleviating VPN traffic.

The good news is that there are a couple of configuration options that you can take to move traffic away from the VPN and directly to Internet sources. These options should hopefully free up some bandwidth for line of business traffic whilst ensuring clients remain managed and up to date.

When the VPN has a known IP range

If your VPN clients are sat neatly in a known IP range or ranges, then firstly you need to create boundaries in Configuration Manager to cover the VPN ranges:

Rob York_6-1584492420485.png

and then add them to a boundary group:

Rob York_1-1584492331636.png

Then you need to configure that boundary group to use cloud services. You do this on the references tab, to explicitly accommodate the CMG with the boundary group:

Rob York_2-1584492331659.png

And also on the options tab select  Prefer cloud based sources over on-premise sources

Rob York_3-1584492331671.png

This option will apply even if you don't have a CMG, so can offer some respite to your VPN by directing clients to Microsoft Update for content.

When the VPN doesn't have a known IP range

Admittedly this complicates matters, but we added the concept of default site boundary group in version 1610 as a replacement to the concept of fallback content location. This behavior means that if your VPN clients do not fall into a known boundary group, they can fallback to communicate with referenced site systems from the default site boundary group.

Again, add the CMG to the references tab

Rob York_4-1584492331682.png

NOTE: This will result in clients in the corporate , but not in a known boundary, to connect to the CMG.

Force the client to Always Internet mode

If networking or boundary configuration makes either of the first two options unviable, you can always force the client to always consider itself IsInternet=1, effectively overriding the logic I talked about earlier. Toggling the client back and forth from explicitly Always Internet is not possible, hence why we make the previous options available. If needed, as a matter of last resort, you could (re)deploy the client using the CCMALWAYSINF parameter to ensure your remote clients are always managed by the CMG.

Finally, I wanted to call out an implementation within the Configuration Manager client when it comes to Microsoft Updates. You do not need to deploy your Microsoft software updates packages to the CMG: If a client is on the Internet communicating to a CMG, it will instead retrieve updates from Microsoft Updates. As long as the client can download directly from Microsoft Updates it will never download Microsoft updates from a CMG. Although, a good practice is to not deploy updates packages to a CMG that contain Microsoft Updates.

We had previously blocked the deploying of update packages to CMG and CDP for this very reason, but we relaxed the restriction in order to facilitate third party updates.

To allow clients to use cloud sources for Microsoft Update content, ensure you select the “If software updates are not available on distribution point in current, neighbor or site boundary groups, download content from Microsoft Updates” check box on the updates deployment:

Rob York_5-1584492331712.png

Rob York


Program Manager

Microsoft Endpoint Manager


This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.