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 “cloudapp.net” 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 “cloudapp.net” 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 cloudapp.net 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 cloudapp.azure.com.
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 ‘cloudapp.net’. The cloudapp.net 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 ‘region.cloudapp.azure.com’ domain suffix instead. If your Classic CMG is using the ‘cloudapp.net’ 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 cloudapp.net 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 ‘cloudapp.net’ 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:
- Microsoft article: Modify a CMG – Configuration Manager | Microsoft Docs
- Microsoft article: Deprecated features – Configuration Manager | Microsoft Docs
- Microsoft Announcement: Cloud Services (classic) deployment model is retiring on 31 August 2024 | Azure updates | Microsoft Azure
