CMG - HTTP1.1 500 CMGConnector_InternalServerError, check SPN


Picking up from my last post that covered the issue involving CMG Azure cloud resources and Tags, my battle was half won in the implementation project of CMG that I was carrying out for one of my customers.


After the cloud service was created and the service reported the status as ‘Connected’, the next logical step was to test and verify the connection. This is where things started to go south. On running the ‘CMG Connection Analyzer’ against the Client Authentication Certificate, I received the following error.




SMS Cloud Proxy Connector log indicated the same.



In my experience, that looked like a communication issue between the connection point and the HTTPS server configured to accept CMG requests.


The ConfigMgr environment has a Standalone Primary (Co-located SQL) configured to cater to HTTP requests. Cloud management gateway connection point was also configured on the same server.

Another server was stood up to cater to HTTPS requests. This server would also manage CMG traffic.


I started checking the health of the server in question (the one setup to respond to HTTPS request). The MP component was reporting all kind of HTTP errors indicating a possible issue with IIS. While I checked the IIS, I couldn’t find a reason for it to be not operational.


Next thing I did was to check the MPcontrol.log and this is where things started to make a little sense. There were entries pointing to SPN not being reachable.



I checked the SPN entries and Voila, they were clearly missing. As a matter of fact, the SPNs were created on the wrong Domain Service Account. If you are running the SQL Service (MSSQLSvc) with local computer system account, the SPNs are registered automatically and you should not see these types of errors. But, if you are running the SQL Service (MSSQLSvc) account with a domain account, then you
must manually register the SPN to ensure SQL clients and other site system can perform Kerberos authentication. Without Kerberos authentication, communication to the database might fail.


In order to fix, the following commands were executed. (Please note that you will need Domain Administrator rights to register the SPN manually)


To delete existing SPNs from wrong service account:

  • setspn -D MSSQLSvc/{SQL Server FQDN}:1433 {Domain\Account}
  • setspn -D MSSQLSvc/{SQL Server FQDN} {Domain\Account}

 To add new SPNs to the correct service account:

  • setspn -A MSSQLSvc/{SQL Server FQDN}:1433 {Local Computer Account}
  • setspn -A MSSQLSvc/{SQL Server FQDN} {Local Computer Account}

Allowed an hour for the replication to go through across all other Domain Controllers in the environment and then restarted the SMS Executive on server in question (Catering to HTTPS) and the errors cleared up in MPcontrol.log.



Also, the Connection Analyzer went through all the way this time.





Hope this helps. Until next time..

Reference - https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections?view=sql-server-ver15


Comments

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

Intune: Configure Printers for Non-Administrative Users

Intune: UAC Elevation Prompt Behavior for Standard Users