memdocs/plan-cloud-management-gateway.md at main · MicrosoftDocs/memdocs

title titleSuffix description ms.date ms.prod author ms.author manager ms.localizationpriority Plan for CMG Configuration Manager Plan and design the cloud management gateway (CMG) to simplify management of internet-based clients. 04/08/2022 configuration-manager configmgr-client conceptual aczechowski aaroncz dougeby medium highpri

Plan for the CMG in Configuration Manager

Applies to: Configuration Manager (current branch)

To simplify management of internet-based clients, first develop a plan for the cloud management gateway (CMG). Design how it fits in your environment and prepare for your implementation.

For more foundational knowledge of CMG scenarios and use cases, see Overview of CMG.

[!NOTE] Some sections that were previously in this article have moved: Hierarchy design : CMG hierarchy design

: CMG hierarchy design Performance and scale: CMG performance and scale

Planning checklist

The overall CMG planning process is divided into the following parts:

Components and requirements: This article summarizes the components that make up the CMG system. It also lists the system requirements.

Client authentication: Determine which authentication method you'll use for clients from potentially untrusted networks.

Hierarchy design: Plan where to place the CMG in your environment.

Supported configurations: Understand which Configuration Manager features you can support on internet-based clients that connect to the CMG.

Performance and scale: Decide how many service components you'll need to best support your number of clients.

Cost: Understand the cost of the Azure-based components.

CMG components

Deployment and operation of the CMG includes the following components:

The CMG cloud service in Azure authenticates and forwards Configuration Manager client requests over the internet to the on-premises CMG connection point.

The CMG connection point site system role enables a consistent and high-performance connection from the on-premises network to the CMG service in Azure. It also publishes settings to the CMG including connection information and security settings. The CMG connection point forwards client requests from the CMG to on-premises roles according to URL mappings. For example, the management point and software update point.

The service connection point site system role runs the cloud service manager component, which handles all CMG deployment tasks. Additionally, it monitors and reports service health and logging information from Azure Active Directory (Azure AD). Make sure your service connection point is in online mode.

The management point and software update point site system roles service client requests per normal.

The CMG uses a certificate-based HTTPS web service to help secure network communication with clients.

Internet-based clients connect to the CMG to access on-premises Configuration Manager components. There are multiple options for client identity and authentication: Azure AD PKI certificates Configuration Manager site-issued tokens For more information, see Plan for CMG client authentication.

The CMG creates an Azure storage account, which it uses for its standard operations. By default, the CMG is also content-enabled to provide deployment content to internet-based clients. This storage account doesn't support customizations, such as virtual network restrictions. [!NOTE] The cloud-based distribution point (CDP) is deprecated. Starting in version 2107, you can't create new CDP instances. To provide content to internet-based devices, enable the CMG to distribute content.

Azure Resource Manager

You create the CMG using an Azure Resource Manager deployment. Azure Resource Manager is a modern platform for managing all solution resources as a single entity, called a resource group. When you deploy a CMG with Azure Resource Manager, the site uses Azure Active Directory (Azure AD) to authenticate and create the necessary cloud resources.

[!IMPORTANT] Starting in version 2203, the option to deploy a CMG as a cloud service (classic) is removed. All CMG deployments should use a virtual machine scale set. For more information, see Removed and deprecated features.

Virtual machine scale sets

[!NOTE] This feature was first introduced in version 2010 as a pre-release feature. Starting in version 2107, it's no longer a pre-release feature. Configuration Manager doesn't enable this optional feature by default. You must enable this feature before using it. For more information, see Enable optional features from updates.

Starting in version 2010, customers with a Cloud Solution Provider (CSP) subscription can deploy the CMG with a virtual machine scale set in Azure. This support is only if they don't currently have a CMG deployed using classic cloud services to another subscription.

Starting in version 2107, all customers can deploy a CMG with a virtual machine scale set. If you have an existing CMG deployed with the classic cloud service, convert the CMG to use a virtual machine scale set.

With a few exceptions, the configuration, operation, and functionality of the CMG remains the same.

Other Azure resource providers in your Azure subscription.

Different deployment names, for example, GraniteFalls.EastUS.CloudApp.Azure.Com for a deployment in the East US Azure region. This name change can affect how you create and manage the CMG server authentication certificate.

The CMG connection point only communicates with the virtual machine scale set in Azure over HTTPS. It doesn't require TCP-TLS ports.

Limitations for a CMG with a virtual machine scale set

Limitations with versions 2107 and later

[!NOTE] Starting in version 2111, CMG deployments with a virtual machine scale set support Azure US Government cloud environments.

Users may experience a delay of up to three seconds for actions in Software Center.

You can't approve/deny application requests through the CMG.

Version 2107 doesn't support Azure US Government cloud environments.

Limitations with versions 2010 and 2103

If you require more than one CMG instance, they all have to use the same deployment method.

The supported number of concurrent client connections is 2,000 per VM instance. For more information, see CMG performance and scale.

It's only supported with a standalone primary site.

It doesn't support Azure US Government cloud environments.

Users may experience a delay of up to three seconds for actions in Software Center.

Configuration Manager currently creates the Azure storage container based on the name of the resource group. Azure has different naming requirements for resource groups and storage containers. Make sure the name of the resource group for this service only has lowercase letters, numbers, and hyphens. If you have an existing resource group that doesn't work, rename it in the Azure portal, or create a new resource group.

If you have more than one HTTPS management point, then you can't install the Configuration Manager client on devices over the internet. If you need to Install off-premises clients using a CMG, then you can only have one HTTPS management point. You also need to enable the CMG for content.

You can't approve/deny application requests through the CMG.

Requirements

[!TIP] To clarify some Azure terminology: The Azure AD tenant is the directory of user accounts and app registrations. One tenant can have multiple subscriptions.

An Azure subscription separates billing, resources, and services. It's associated with a single tenant. For more information, see Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings.

An Azure subscription to host the CMG. This subscription can be in one of the following environments: Global Azure cloud Azure US Government cloud Customers with a Cloud Service Provider (CSP) subscription need to use version 2010 or later with a virtual machine scale set deployment.

Integrate the site with Azure AD to deploy the service with Azure Resource Manager. For more information, see Configure Azure AD for CMG. When you onboard the site to Azure AD, you can optionally enable Azure AD user discovery . It isn't required to create the CMG, but required if you plan to use Azure AD authentication with hybrid identities. For more information, see Install clients using Azure AD and see About Azure AD user discovery.

An Azure administrator needs to participate in the initial creation of certain components. This persona can be the same as the Configuration Manager administrator, or separate. If separate, they don't require permissions in Configuration Manager. When you integrate the site with Azure AD for deploying the CMG using Azure Resource Manager, you need a Global Administrator . When you create the CMG, you need an account that is an Azure Subscription Owner and an Azure AD Global Administrator .

Your user account needs to be a Full administrator or Infrastructure administrator in Configuration Manager.

At least one on-premises Windows server to host the CMG connection point . You can colocate this role with other Configuration Manager site system roles.

The service connection point must be in online mode.

Configure the management point to allow traffic from the CMG. It also needs to require HTTPS, or configure the site for Enhanced HTTP.

A server authentication certificate for the CMG.

Other certificates may be required, depending upon your client OS version and authentication model. For more information, see Configure client authentication.

Clients must use IPv4 .

Make sure the following client settings in the Cloud services group are enabled for devices that will use the CMG: Enable clients to use a cloud management gateway Allow access to cloud distribution point [!NOTE] If you enable the client setting to Download delta content when available, the content for third-party updates won't download to clients.

Next steps

Next, determine how clients will authenticate with the CMG:

How To Convert Your Cloud Management Gateway to a Virtual Machine Scale Set

When Microsoft introduced the Cloud Management Gateway (CMG) for Microsoft Endpoint Configuration Manager (MECM), there was only one supported deployment method – to use Cloud Service (Classic) resource. Since then, Microsoft has been further deprecating the Classic Azure Service Manager resources in favor of the improved Azure Resource Manager resource model, so it was only a matter of time until CMGs based in the Classic model would need to be upgraded or replaced.

Starting in Microsoft Endpoint Configuration Manager 2107, Microsoft introduced the ability to deploy a CMG using Azure Resource Manager resources, specifically through the usage of a Virtual Machine Scale Set. No longer was there a requirement to use any Classic resources, though the legacy Classic CMGs were still supported.

Now, nearly a year later, Microsoft has announced the timeline for the end of Classic CMG support, while also providing a path for customers to migrate from Classic CMGs to Virtual Machine Scale Set-based CMGs. To assist with this transition, a new feature has been provided, known simply as Convert. The Convert wizard has very few requirements and is very adept at creating a Virtual Machine Scale Set and migrating an existing Classic CMG to a Virtual Machine Scale Set.

There are some caveats, however – if you are planning on changing the Azure AD App used to manage the CMG, or you want to move the CMG to a new Azure environment, Subscription, Region, or Resource Group, a new CMG will need to be created instead of converting the legacy CMG. Aside from those scenarios, the Convert wizard provides an easy tool to convert a Classic CMG to a Virtual Machine Scale Set CMG.

This post intends to provide further information about the timeline for migrating legacy Classic CMGs and walk through the process for using the Convert wizard to convert to a Virtual Machine Scale Set CMG.

Critical Dates for Microsoft’s CMG Transition

It is important to note that, as of Current Branch version 2203 of MECM, the option to create a CMG using Cloud Service (Classic) has been removed. The only remaining option for building a CMG is the Virtual Machine Scale Set, so if you haven’t deployed a CMG yet and are on Current Branch version 2203 or newer, then you can move forward with your CMG deployment without concern for migration from legacy Classic resources.

If you do have a Classic CMG in your environment today, you have a limited amount of time to upgrade it before it stops working – any Cloud Service (Classic) resources, including Classic CMGs, will no longer function after August 31, 2024. So, it is time to start getting those CMGs updated to the latest and greatest technology.

CMG Prerequisites for Conversion

Before you convert your existing Classic CMG, you need to make sure that you have the proper prerequisites in place.

First, the big obstacle – in order for a Classic CMG to be eligible for conversion, it needs to have been originally configured with a Service Name using a custom domain suffix (most likely your organizational domain suffix) rather than using the default suffix. Most organizations will have configured their own domain suffix in the Service Name during the initial CMG deployment and thus will be fully able to convert their Classic CMG to a new CMG. If yours was not, though, then you will be unable to convert your CMG. Hop down to the “What if the CMG can’t be Converted?” section below for more information.

Beyond that, there are four Azure Resource Providers which need to be registered within the subscription where you have your CMG running. If they are not already registered, they need to be registered before converting your Classic CMG. The resource providers are:

Microsoft.KeyVault

Microsoft.Storage

Microsoft.Network

Microsoft.Compute

To ensure these have been registered in your Azure environment, go to the Azure portal, open the Subscriptions page, and select the subscription in which your CMG is deployed. Once there, click on the Resource Providers option within the Settings menu to verify that all four of these Resource Providers are registered.

If not all of the necessary providers have been registered, follow these steps from Microsoft to configure them before proceeding.

CMG Conversion with the Easy Button

Now comes the fun part – converting the CMG. As long as your Classic CMG’s Service Name does not have a suffix and the CMG is in a Ready state, you will see the Convert option in the context menu when you right click the CMG in the MECM console. If the Convert option does not appear, verify that the Cloud management gateway with Azure VM scale set feature is enabled. You can do that from the Updates and Servicing > Features node within the MECM console.

If the feature to create a Virtual Machine Scale Set CMG is enabled, the CMG has a configuration that is not supported, or there is something wrong with the CMG that is keeping it out of the Ready state, skip down to the “What if Your CMG can’t be Converted” section of this post. Otherwise, you can keep reading!

Once you click Convert, you will be presented with the wizard which allows you to make changes to the CMG. The General page does not provide any fields that you can edit, it is informational only. The Settings page allows you to alter some of the CMG configuration details before you start the conversion.

As you can see in the following image, the Description can be changed, as well as the VM Size, number of virtual machines that will make up the CMG service, the PKI settings, and whether the CMG will also act as a distribution point for clients. Take note of the value in the Deployment name field – although you cannot edit this field, you will need to know this fully qualified name for the service so that you can edit the DNS CNAME record once the conversion is complete. Failure to do so will result in the CMG not functioning. Make sure to write it down or otherwise note it before proceeding.

One other item of note – when converting, you can change the virtual machine size for the CMG. Cloud Service (Classic)-based CMGs previously had only one virtual machine size – A2_V2. The virtual machines in the scale set can be configured as A2_V2, which is considered Standard size, or A4_V2, which is considered Large. Each of these comes with its own costs to run, so verify how much you need to spend on your CMG infrastructure before breaking the bank. There is a Lab option, which is a B2S size virtual machine, but it is only recommended to select that option if you are testing in a limited lab environment. It is not supported or recommended for production usage.

Once you complete the wizard, Configuration Manager will start deploying the new Virtual Machine Scale Set CMG and copy all of the current CMG settings over to the new service. This will take a little while to perform.

You can watch the CloudMgr.log file as the process is underway. You can also watch the Resource Group within Azure to see the new resource as they are created. Initially, the Cloud Service (Classic) and Storage Account resources were listed within the resource group. As the services are created, you will see Virtual Machine Scale Set, Key Vault, Load Balancer, Network Security Group, Public IP Address, and Virtual Network appear. Once the conversion is complete, the Cloud Service (Classic) resource will be deleted.

After You Convert, You Must Update Your DNS

After the conversion is complete, you will notice that there are some errors within the CloudMgr.log file. This is due to the CMG not being accessible from the Connection Point. Although you might think this is caused by a failure of the Connection Point configuration during the conversion, it is actually due to the existing CNAME record in DNS pointing to the old CMG Service Name, which will have changed during the conversion.

Remember earlier when we said you would need to remember the new fully qualified name of the service, as seen in the Deployment Name field? That comes in handy now. Any system that communicates with the CMG will need to know the correct information, so both internal and external DNS will need to be updated.

As seen in the following image, the CNAME record that identifies the underlying service name within Azure, the target host, needs to be updated from the previous domain to that which was found in the conversion wizard. The easy way to remember the domain suffix is by the region where your resource group is located. In the example below, this is southcentralus, followed by

You will need to either update DNS yourself if you have access, or work with whomever manages your DNS configuration to have the existing CMG records updated with the new service name.

Once the CNAME record has been updated, MECM will notice the change and successfully communicate with the CMG, which will then become available. To validate that the CMG is functioning properly, you can run the Connection Analyzer in the MECM console; you should get green check marks all the way.

What If Your CMG Can’t Be Converted?

But what do you do when you don’t have the Convert option? Typically, when you do not see the Convert menu item, it is because the Service Name’s domain suffix is The domain is used only with Cloud Service (Classic) or Cloud Service (extended support) resources. Azure Resource Manager resources, such as Virtual Machine Scale Set-based CMGs use the domain suffix instead. If your Classic CMG is using the domain suffix in its Service Name, it cannot be converted because there would be no way to redirect client communication to the new CMG.

If you look at the properties of the CMG and you see the domain suffix, your only option is to deploy a new CMG from scratch, including generating a new certificate for your new CMG’s new Service Name. Before you deploy a new Virtual Machine Scale Set-based CMG, though, your existing Classic CMG must be decommissioned – you cannot deploy a Virtual Machine Scale Set CMG if you already have a Cloud Service (Classic) CMG in your subscription.

The same prerequisites are required to create the new Virtual Machine Scale Set CMG as were needed when converting. Additionally, you will need to make sure you update your CNAME record in DNS to reflect the new Service Name to be used by the new CMG, which will ideally leverage a custom or organizational domain suffix rather than the default underlying Azure domain suffix. There are several blogs out there that detail exactly how to create a Virtual Machine Scale Set CMG if you need assistance. Perhaps that will be the subject of a future blog post.

Finally, if you have verified that the Virtual Machine Scale Set feature has been enabled and you are not using the domain suffix for your CMG service, but you are still unable to Convert your CMG, it is likely because your CMG is not in a ready state. You will need to determine why the CMG is not in a ready state before you can proceed – use the troubleshooting information on this Tech Community page and this Microsoft article to help assess the situation.

Conclusion

With the continued deprecation of legacy Azure resources and Microsoft’s announcement of Classic CMG’s end-of-life date, it is important for businesses to start making a plan for converting their Classic CMGs to the new Virtual Machine Scale Set-based CMGs. Fortunately this conversion is a simple process in most cases. In this post, we’ve walked through the process of preparing and performing the CMG conversion, as well as discussed what issues may prevent a CMG from being converted, and what needs to be done instead. Our hope is that it will be helpful for you when implementing the process in your own environment.

Thanks for reading, and follow us for more helpful posts in the future!

Further reading and resources on this subject:

MEMCM Cloud Management Gateway migration options

Now that Cloud Management Gateway (Classic Service classic) is deprecated and will be removed in the future releases of Configuration Manager after 1 March 2022 we can now longer deploy a CMG using the cloud service (classic).

This is most likely due the fact that Classic VMs is being removed in Azure as the link below shows.

Which options do we have to migrate then?

It depends on the Cloud Management Gateway is configured today if it uses a custom DNS domain name or a name. If a custom DNS name is being used the built-in wizard can be used to convert the Cloud Management Gateway to a Virtual Machine Scale set as I wrote a post on when it was in Technical Preview:

Important when migrating to a CMG Virtual Machine Scale set is that we configure the prereqs which differs from classic to virtual machine scale set.

In the Azure Subscription used we need to add the following Resource Providers that are required when using Virtual machine scale sets.

Azure Resource Groups

What if we used a DNS name then? The challenge is that the DNS name has changed for Virtual Machine Scale Sets to in my example that would be

Virtual Machine Scale Set DNS Name

When we run the migration wizard we cannot change the certificate used for the service which means that we cannot change the name, which makes perfect sense because all clients that are connected to the CMG will have no chance to get the new name of the service.

With the release of Configuration Manager 2107 we got a new option, we can now deploy a CMG cloud service (Classic) and a CMG that uses Virtual Machine Scale Set at the same time.

This was not possible before and this gives us a great migration option, simply deploy a new cloud management gateway using Virtual Machine Scale set in parallel with our classic one.

Two CMG

Remember that you need to have a second site system that we can install an additional Cloud Management Gateway Connector that you need.

Cloud management gateway connection point

If we look a client which is on the internet it picks up the new CMG as a DP really fast and after a while the new CMG as a MP as well.

Before the new CMG was installed:

Old CMG

Old CMG

The client rotates the Internet-based management point after a while or when we remove the old CMG.

New CMG

New CMG

Important: If co-management is used and we deploy the Configuration Manager client to Intune managed device the installation string needs to be updated with the correct one. The installation string sample under Cloud Attach updated itself with the new one as soon as I deployed the new CMG

Co-management settings

My sample CM Client Bootstrap LoB app in Intune which I needs to be updated manually to reflect the new CMG.

Intune CM bootstrap

I wrote above that we had two options to migrate, the other option would be to deploy a new CMG using a DNS Name and then migrate that to a Virtual Machine scale set. Which was the way we had to do it before MEMCM 2107 was released.

But now the option described above makes much more sense.