Sunday, 5 July 2020

CMG and multiple root certificates

I was deploying a Cloud Management Gateway on a customer site recently and encountered this problem. This was a PKI deployment so I was adding internal root and intermediate certificates in the Settings page of the CMG wizard. 

I tried to satisfy the customer requirements but I was unable to add a third root certificate and received this error:

"You can only add two trusted root CAs and four intermediate CAs". 

I found that this was a limitation with CMG in ConfigMgr version 1902. This limit has been removed from version 1906 and later. 

The solution was obvious - upgrade the site to a later version.

I hope this helps. Until next time...…... 

Sunday, 21 June 2020

Cloud Management Gateway and Azure tags

I encountered this problem recently while deploying a CMG for a customer. Perhaps there was a better way for me to solve it but I'll explain the problem and how I worked around it. 

I got this error when creating the CMG. On my first try I was creating the resource group in the wizard.

Error occurred when granting Contributor permission to the Azure AD app for resource group xxxxx. For more information, see SmsAdminUI.log".

The error wasn't clear to me. I knew that I was using a Global Administrator account, which was also an Owner of the Azure subscription.  I didn't really understand the problem until I looked at the logs.

In the Azure activity log I found this.

It told me that the resource I was creating was disallowed by an Azure policy that had been configured. The policy was called "Require a tag and it's value on resource" and meant that resources could not be created in the subscription without tags and their associated values. I found the same text in the SmsAdminUI.log file. That makes sense. It's good for housekeeping, right?

However, ConfigMgr couldn’t create the resource group as there was a policy in place enforcing Azure tags, which I couldn’t configure in the wizard. I figured that I should create the resource group manually and apply tags to it. However I got the exact same error when I re-ran the wizard.

I finally solved it and created the CMG by disabling the policy. Perhaps there was a more graceful way to solve it but it allowed me to continue.

Remember, in ConfigMgr, logs are your friend.

I hope this helps.

Until next time...........

Sunday, 17 May 2020

CMG token based authentication with ConfigMgr 2002

A few years ago we were first introduced to the Cloud Management Gateway. It was a revolutionary new feature allowing us to manage all supported ConfigMgr clients over the internet. At that time the solution required that you configure a PKI solution so that the clients could communicate with the management point over https. Microsoft recognised that this was challenging for some organizations so, from version 1806, Azure AD joined Windows 10 devices could communicate with the management point over http (as long as we enabled enhanced http).

However that still didn't suit all organizations. Some organizations weren't ready for PKI or Azure AD join implementations and still needed to manage Windows 7 devices. ConfigMgr 2002 was generally released last week and includes a real game-changer. We can now used token-based authentication for communication between internet clients and the management point over http. The amazing thing here is that we don't have to do anything additional on the management point or client. All this works out of the box when you upgrade the ConfigMgr site to version 2002. Remember you MUST actually upgrade the clients to 2002 as well.

There are two scenarios and we'll look at both.

  • clients that can register on the internal network
  • clients that are always internet-based
Internal network

This is easy. It just works out of the box. When you upgrade a client to 2002 it will immediately register with the management point.

In the ClientIDManagerStartup.log file you will see the client receiving it's self-prove token from the management point.

This is a ConfigMgr 2002 client on the intranet. You will see that it is not configured for PKI (otherwise you would see Client certificate: PKI). It uses a self-signed client certificate (and the self-prove token behind the scenes).

The client is not Azure AD joined.

Now the client roams to the internet. It pairs it's self-signed certificate with the management point-issued self-prove token to communicate with the CMG.

The client is now aware of the CMG.

In the CcmMessaging.log file we can see the client receiving a CCM token which allows the communication to continue.

In the ConfigMgr console we can now see that the client is being managed over the internet.

An important thing to note is that the client renews the token once a month and it is valid for 90 days.


What can we do with clients that are already internet-based? We won't be able to automatically upgrade the client to 2002 and the client won't be able to register with the management point immediately and get the self-prove token. In this case we can use the bulk registration token.

Navigate (as administrator) to the \bin\x64 folder of the ConfigMgr installation directory on the site server.

Run the tool by executing: 

BulkRegistrationTool.exe /new

The token is generated. Remember this token has a short-validity period so you should use it straight away.

Copy the token.

Now install the ConfigMgr client on the internet-based device using the additional /regtoken parameter. I've done it manually by copying the installation files to the device and executing this command:

ccmsetup.exe /mp: SMSSiteCode=GER SMSMP=https://MEM.hampson.local /regtoken:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1XUldSbUtVQlZjNlJDSGpCTjQyZnhvZUdEMCJ9.eyJTQ0NNVG9rZW5DYXRlZ29yeSI6IlNDQ01QcmVBdXRoVG9rZW4iLCJBdXRob3JpdHkiOiJTQ0NNIiwiTGljZW5zZSI6IlNDQ00iLCJUeXBlIjoiQnVsa1JlZ2lzdHJhdGlvbiIsIlRlbmFudElkIjoiN0IwQzM4MDYtRDI4Qy00QTQ1LUFEQjItRkI5Rjk0QTQ2MkY4IiwiVW5pcXVlSWQiOiJlYTJmYzUxMC1hM2JlLTRjZWYtOTBiMC0yYTA1MTVjNGU0MGMiLCJpc3MiOiJ1cm46c2NjbTpvYXV0aDI6N2IwYzM4MDYtZDI4Yy00YTQ1LWFkYjItZmI5Zjk0YTQ2MmY4IiwiYXVkIjoidXJuOnNjY206c2VydmljZSIsImV4cCI6MTU4OTcwMTUxOCwibmJmIjoxNTg5NDQyMzE4fQ.Y-6s6_h18cnIZP8OPqdjpxQHUhg_4srICehX5xOfym5AcyQRC3wlN89PAByFD2gfp6QvV7gXX9H7oG198UGHhUuJrthAipSo4KNCSr8t7TcZwjR9awt720tErf9aiflBKnFibAYAGU9xBS3UYTetQ6XYpdh0XsCedsbh0-6ilj6KmP1qWBFIYNkBaL3oP_HJhX02de0wqeh-fWiTtdvbKnOxDrGetoCKsEVp3sJumprzWHZ6ZpRD3powG3AUOOSbAW96c_driDvzwC6x6hoWOo4GPEs-BaoJUdRzi1htY9IJB2X_drIQqLH8X0Ps6B5H5-KGH3gB0tJA45WwERuLxA

As before you will see the client getting it's CCM token from the CMG in the ClientIDManagerStartup.log file.

The client is installed.

In the ConfigMgr console we can see that the device is managed by the CMG over the internet.

There are obviously a few challenges in this scenario:

How does the remote user get the ConfigMgr 2002 client installation files?

I plan to use this scenario in production and I intend to copy the files and installation instructions to OneDrive to make available to users.

How can the user install the client if they are not a local administrator?

This one is more challenging. The users will need some assistance with elevated rights, possibly using screen-sharing software. This also highlights a great use case for a solution like Local Administrator Password Solution (LAPS).

I think this feature will be extremely useful so I hope this walkthrough was helpful.

Until next time......

Thursday, 7 May 2020

CMG Name Resolution Failure

This was an issue I encountered recently. I had added a CMG but there were errors in the CMG Connection Analyzer.

I always advise my customers to secure the CMG using a public SSL certificate. This involves using an externally routable domain and creating a CNAME record to direct requests to the CMG ( -> for example, all the screenshots below are examples, not from the customer). 

I had already configured the CNAME record with the domain hosting company and it could resolve externally. This is what it should look like. The DNS name should resolve but it doesn't matter that there is no ping response. That is normal.

However the CMG Connection Analyzer still failed with the error:

"Failed to connect to the CMG service. Unexpected response status code is NameResolutionError. For more information, see SmsAdminUI.log".

I carried out some troubleshooting and saw that the CNAME resolution did not work from the Primary Site server. At that point I realized that the customer was using split DNS. In a split DNS infrastructure, you create two zones for the same domain, one to be used by the internal network, the other used by the external network – typically users on the Internet. Split DNS directs internal hosts to an internal domain name server for name resolution and external hosts are directed to an external domain name server for name resolution.

The solution was to also add the CNAME record to the internal DNS zone.

Right click the zone and choose New Alias (CNAME).

Enter the details for the alias.

All was good for the CMG.

Until next time....

Tuesday, 5 May 2020

CMG - the subscription is not registered to use namespace 'Microsoft.Storage'

This was a new issue for me to fix when deploying a CMG last week. 

The first attempt failed - "Failed to provision cloud service".

The CloudMgr.log file was full of information and told me what I needed to know.

"The subscription is not registered to use namespace 'Microsoft.Storage'".

I could see the same in the Azure Activity log.

This was a little unusual for me as I hadn't come across this problem before. I know that I have to register the Classic.Compute resource provider (this one has it's own issues in that it's not exposed in a CSP subscription) but I've never seen a problem with the Microsoft.Storage resource provider.

As usual I found that it was specifically called out in the official docs.

"The Microsoft.ClassicCompute & Microsoft.Storage resource providers must be registered within the Azure subscription".

I registered the Microsoft.Storage resource provider.....

....and was able to deploy the CMG.

I hope this helps you. Until next time......