Configuration Manager 1610 – Cloud Management Gateway Setup guide


Configuration Manager 1610 introduced a new feature to manage clients on the internet – the Cloud Management Gateway. The Cloud Management Gateway service is deployed to Microsoft Azure (an Azure subscription is required), and connects to your Configuration Manager site via the Cloud Management Gateway connection point – a new site system role also introduced in 1610. This allows Configuration Manager clients to access your Configuration Manager site system roles even if they are not on the intranet.

The attached guide will walk through the full process of setting up the Cloud Management Gateway with Configuration Manager current branch 1610.

configuration-manager-cloud-management-gateway(PDF download)

Like internet based client management, for clients to access site system roles using the Cloud Management Gateway, SSL certificates are required to authenticate computers and encrypt communications between the different layers of the service. To encrypt traffic between Configuration Manager clients and the site system server hosting the Cloud Management Gateway connector, Software Update Point, and Management point roles, you will also need to create a custom SSL certificate on the CA for the site system. An Azure management certificate is required to deploy the Cloud Management Gateway as well as the Cloud Distribution Point.

In the 1610 release, the Cloud Management Gateway only supports the management point and software update point roles. If you will be deploying anything other than software updates to clients managed via the Cloud Management Gateway, you will also need to configure a Cloud Distribution Point for clients to download content from.

The guide below covers the full process of creating the required certificates on the Issuing CA server, creating the Cloud Management Gateway and Cloud Management Gateway connection point, uploading management certificates to Azure, configuring the site system roles to accept cloud management gateway traffic, and verifying that clients on the internet can connect to the cloud management gateway. The last section also covers creating the Cloud Distribution Point.

More information on the Cloud Management Gateway, including prerequisites, can be found here https://docs.microsoft.com/en-us/sccm/core/clients/manage/plan-cloud-management-gateway

The process for deploying Cloud Management Gateway includes the following steps:

  1. Create and issue a custom SSL certificate for the Cloud Management Gateway (and optionally, the Cloud Distribution Point).
  2. Create a client authentication certificate
  3. Export the client certificate’s root
  4. Verify a unique Azure cloud service URL
  5. Request the Cloud Management Gateway certificate from the Certification Authority
  6. Upload the Cloud Management Gateway (and optionally, the Cloud Distribution Point) management certificate to Azure.
  7. Create the Cloud Management Gateway in the Configuration Manager console
  8. Install the Cloud Management Gateway connection point in the Configuration Manager console
  9. Configure Site System Roles to accept cloud management gateway traffic
  10. Verify Client Communication with the Cloud Management Gateway
  11. Configure a Cloud Distribution Point (optional)

 

Check out the attached guide, and please feel free to add your comments!

 

configuration-manager-cloud-management-gateway(PDF download)


Comments (4)

  1. Eji says:

    Is HTTPS mode required on SUP/WSUS to support clients connected through CMG ?

    1. @Eji – Yes the MP and SUP should be configured for HTTPS; you could put the cloud management gateway connection point, MP and SUP on a separate server, and configure HTTPS for that server. The site will need to be configured to support both HTTP and HTTPS connections if the other site servers are not yet configured for HTTPS/if your clients do not have a PKI cert.

  2. Alexey Semibratov says:

    So here is some feedback. On page 19 it says to verify cloud service. The purpose of that, I assume, to make sure that the DNS name under cloudapp.net you’re planning to use is not taken. Good point, but I just struggled when I created blablablaproxy.cloudapp.net in East 2, and in the wizard did not pay attention that it was saying just “East” by default. The error it gives in this case is pretty ridiculous, that the name should be “alphabets” or numbers only from 3 to 27 characters. Which my blablablaproxy was perfectly meeting, but the real reason was unmatched region.

  3. Matt says:

    Great blog post, Teju! Thanks for putting it together.

Skip to main content