IT Consultant Everyday Notes

Just some problems/solutions storage

Category Archives: CMG

SCCM: CMG installation failed when granting permissions to a resource group

I reinstalled a Cloud Management Gateway (CMG) in my Lab and the installation failed with: “Error occurred when granting Contributor permission to the Azure AD app for resource group RG-SCCM-CMG. For more information, see SmsAdminUI.log”

I checked the log and found a weird error containing the following (tenant are sanitized):

“InvalidAuthenticationTokenTenant: The access token is from the wrong issuer ‘’. It must match the tenant ‘′ associated with this subscription. Please use the authority (URL) ‘′ to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later”

Strange, taking in consideration the account I used to sign in has only one directory associated.

Resolution: I closed SCCM console and completely deleted cache including cookies in my Edge Browser. After that I restarted the installation from SCCM console and this time it passed smoothly.

SCCM: Secondary SUP broke the primary one.

Recently I helped my Customer with a CMG configuration. The Clients are not hybrid joined, so we needed to use PKI infrastructure. For the Pilot the Customer decided to bring a new 2016 Server and configure it for SSL-enabled MP and SUP in the current HTTP environment (SCCM is installed on Windows Server 2012 R2).

Everything looked ok until the second SUP was prepared. We used as a guide and pointed the new WSUS to the primary database. That was a mistake – the secondary WSUS was installed ok, but the primary went down and could not start anymore. I tried to run wsusutil postinstall  with specified content folder and database, but WSUS was not happy anyway. wsusutil log revealed that the new 2016 WSUS actually updated WSUS DB schema and the old 2012 R2 WSUS could not access it anymore Smile. The error message suggested to upgrade WSUS to the same version…

Hopefully we had a backup of the DB, so I deleted the new WSUS, restored the DB with the old schema and re-run wsusutil postinstall content_dir=*MYFOLDER*  SQL_Instance_Name=*MySQLNAME*. After that the primary WSUS started and with some time SUP connected to it correctly.

After that I install a new WSUS on the 2016 server again, but this time I used a local folder for content and WID for the WSUS database. Next, I moved database from WID to my SQL server with a different name (since SUSDB already existed there) and tweaked registry settings in WSUS Server configuration to point it to the new location. step-by-step is here:

registry settings for SQL name and DB name (if the name was changed):


Lesson learned: it is always better to use the same OS version for site systems in your SCCM infrastructure.

SCCM: MP is not reachable via CMG (PKI scenario)

One of my Customers asked me to help with a CMG deployment. The idea is to get Internet-based machines managed and patched.

They do not have Hybrid AAD joined environment yet, so I need to use old good PKI.

I decided to get it in my Lab first. I do have CA on my pfsense router to get it even more interesting (the certs do not CRL link).

I issued required certificates for my SCCM, CMG and Clients and flipped my Primary site to PKI. On all Certificate settings I checked “No CRL verification” box (sice I do not have one.

Internally everything worked fine, but when I flipped a Client to “Internet” subnet I found it can connect for a short period of time only. After that connection to MP via CMG is lost, client goes grey and I see:

[CCMHTTP] ERROR INFO: StatusCode=403 StatusText=CMGConnector_Clientcertificaterequired

in LocationServices.log on the Client.

It turned out to be a known issue (KB4503442) or better by design behaviour for a scenario when Azure AD tokens are not in use.

So, I added a Client cert with the name of my MP as Subject Name and in SAN. Restarted Cloud Connector on my SCCM.

Still no go.

Checked the SMS_Cloud_ProxyConnector.log  and found:

Chain build failed cert: 77…………………………………………1

Chain 0 status: RevocationStatusUnknown

ok… So it looks like even though I unchecked Revocation List check in properties of CMG the connector is still trying to check it Smile. In troubleshooting guide (  Microsoft says the best way is to publish CRL properly (sure, I know that). and do not provide information how to disable the check.

But if we take a look in the registry HKLM\SOFTWARE\Microsoft\SMS\SMS_CLOUD_PROXYCONNECTOR  we can find a key: ClientCertSelectionNoCRLCheck set to 0 by default.

I switched it to 1 and restarted the connector.

After that the Internet Client successfully connected to the MP.

Note: I completely agree with the Vendor – the proper approach is to have your PKI properly configured and CRL published with public access; but in my case it is a Lab, so the workaround is acceptable.

SCCM: CMG Provisioning Failed

Microsoft published an interesting Lab Set for Modern Desktop Management. Between projects I decided to install the kit and try Labs.

Here are some gotchas:

1. If Azure Account does not have an Azure Subscription in its own directory CMG installer cannot see the Subscription. Even if the account has rights to another subscription. I needed to create a new rial subscription linked to the same AAD to be able to proceed.

2. Even after that CMG provisioning failed. I checked the logs and found that Microsoft decided to not register Classic Compute (yes, CMG still uses Classic model). TO fix that I ran Powershell in Azure Portal and register requred provider:

register-azurermresourceprovider –providernamespace “Microsoft.ClassicCompute”

will see what additional surprises MS prepared…

SCCM: CMG Connector Analyzer fails

I installed Cloud MAnagement GAteway in my SCCM environment and ran CMG Connector Analyzer. It failed on the last test with

Failed to get ConfigMgr token with Azure AD token. Status code is ‘403’ and status description is ‘CMGConnector_Un-authorizedrequest’.
A possible reason for this failure is the CMG connection point failed to forward the message to the management point. The management point returned the following error: ‘Un-authorizedrequest’.


it turned out the account I used for the test has MFA and it looks like the Analyzer cannot handle that. So I signed in with a regular non-MFA account and this time the Connector passed successfully: