A Deep Dive look into CMG Cloud Components (Part 2)
Published Mar 10 2024 10:30 AM 3,124 Views



In continuation with Part 1 of the series, in this post, we will discuss CMG App-Registrations.


Once the Installation Wizard for the CMG is complete, the Service Connection Point creates a thread for the Cloud Manager, which is observable in the CloudMgr.log. Our server app establishes a connection to Azure and applies the ARM Template to the Resource Group based on the wizard properties provided which deploys the following Azure resources: 


  • Virtual machine scale set 
  • Key vault 
  • Load Balancer 
  • Network security Group 
  • Public IP address 
  • Virtual network 
  • Storage account 




 The virtual machines in the scale set are configured using PowerShell Desired State Configuration. This configuration is found in the Installation directory of ConfigMgr ("<ConfigMgr-Installalocation>\inboxes\cloudmgr.box\cmgdsc.zip"), is uploaded to the Storage Account and applied from there. This configuration sets up the WebServer, installs additional WebComponents, removes legacy Crypto-Provider, disables RC4, and performs cleanup tasks for Internet Information Service. 


If you look at the Azure Resource Visualizer, it shows the following configuration: 




Virtual Machine Scale Set 


The VMSS configuration includes the number of instances, their state, the operating system, and extensions like PowerShell DSC. Although VMSS supports auto scaling which includes adding or removing virtual machines based on usage, this isn’t supported by ConfigMgr. This is because configuration changes made outside of the ConfigMgr API aren't supported, as ConfigMgr isn't aware of such changes, potentially leading to issues. 


With the creation of the VMSS, an Enterprise Application Managed Identity is also created for accessing the key vault. 




Key Vault 


Inside the Key Vault for the CMG’s VMSS, there are two secrets stored 


  • The Storage Connection String (in case the CMG is configured to act as a Distribution Point)  
  • The local Administrator password for the virtual machines inside the scale set.  




Additionally, we store the certificate for the CMG. 




By default, only two applications have access to the key vault: our WebApp and the managed identity of the scale set. 




Load Balancer 


The Load Balancer distributes traffic among multiple virtual machine instances within the CMG. It’s configured with a front end IP configuration linked to the public address and three rules: 


  • One load balancer rule for the HTTPS-Traffic which is used for the backend pools and the HealthProbe 
  • Two Inbound NAT Rules for each VMSS-Instance 


Front End Port 

Back End Port 







Custom / CMG-Channel-Traffic 


The Remote Desktop Protocol is pre-created and used in combination with an Azure Bastion avoiding external port exposure. 


One of our peers in Ireland wrote one article specific to this Port 8443 – which you will also find in the Network Security Groups: Cloud Management Gateway - Inbound Rule for Port 8443 - Microsoft Community Hub. 


Network Security Groups 


Apart from Default Rules for Inbound/Outbound Security, there are two allow rules for inbound traffic: 



















The virtual subnet is solely associated with this resource group’s Network Security Group (NSG). 


Public IP Adress 


The Public IP Address serves its obvious purpose. Notably, the IP Address Assignment is static, ensuring the IP Address is retained unless this Resource is deleted. For details on Azure public IP addresses, see Create, change, or delete an Azure public IP address - Azure Virtual Network | Microsoft Learn. 


Virtual Network 


As outlined above, there is a single IP-Subnet associated with the Scale Set NSG. 


Storage Account 


Here we upload and store all ConfigMgr content distributed to the CMG’s cloud storage to Azure blob storage.  






We also create tables within Azure the Azure storage account for CMG logging, audit and configuration purposes. 






Defender for Cloud Recommendations 


Security is vital for organizations – and of course we need to address those concerns. For Instance, if you use at the Defender for Cloud recommendations you will see the following advices for a CMG: 




 As mentioned earlier, the CMG is a SaaS utilizing PaaS components, and modifications are not supported outside the Configuration Manager API. The following comments address each of the items called out in the screenshot above. 


  • A Log Analytics Agent or Azure Monitoring Agent is not necessary for this service. 
  • The entire content workflow is based on a Shared Key Access. Modifying this would break the content download. Additionally, this Secret Key is stored in the Key Vault. 
  • By default, when you create a new key vault, the Azure Key Vault firewall is disabled. All applications and Azure services can access the key vault and send requests to it. However, this configuration does not mean that any user will be able to perform operations on your key vault. The key vault still restricts access to secrets, keys, and certificates stored within it by requiring Microsoft Entra authentication and enforcing access policy permissions. In our case, only the WebApp and the Managed Identity of the VMSS have access to the Key Vault. 
  • Restrict the Storage Account access to specific virtual networks or private link connections. In this case, the service itself is designed to manage devices regardless of their location without requiring a VPN. 
  • Purge Protection helps in case of malicious deletion of a key vault, which could lead to permanent data loss. However, the risk for this scenario is low regarding data loss because, in the worst case, you would rebuild your CMG and upload your on-premises content again. 


We hope this Blogpost provides a better understanding of the CMG, assisting ConfigMgr Admins in addressing queries from their Azure & Security Teams. 


The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. 


Version history
Last update:
‎Mar 10 2024 09:41 PM
Updated by: