Troubleshooting: Configuration Manager Clients Failing to Connect to CMG

Table of Contents

The Cloud Management Gateway (CMG) in Configuration Manager is a powerful tool, enabling you to manage clients on the internet without additional on-premises infrastructure. It extends your Configuration Manager environment to Microsoft Azure, allowing clients to communicate with your management point (MP) and software update point (SUP) even when they are not connected to your internal network. However, setting up and maintaining a CMG can sometimes present connectivity challenges, leading to clients failing to communicate effectively.

This article provides comprehensive solutions to common issues encountered when Configuration Manager clients fail to establish communication with a Cloud Management Gateway. We will delve into specific error codes, their underlying causes, and detailed resolution steps, aiming to equip administrators with the knowledge to diagnose and fix these problems efficiently. Understanding these errors is crucial for maintaining seamless client management in a hybrid environment, ensuring that your internet-based clients receive policies, software updates, and application deployments without interruption.

Understanding Cloud Management Gateway Communication¶

Before diving into specific error codes, it’s essential to grasp the fundamental communication flow involving a CMG. When an internet-based client attempts to connect to its Configuration Manager site, it first resolves the CMG’s public FQDN (Fully Qualified Domain Name). The client then establishes an HTTPS connection to the CMG service hosted in Azure. The CMG acts as a proxy, securely forwarding the client’s requests to an on-premises CMG connection point, which then relays these requests to the internal management point. This entire process relies heavily on proper certificate authentication and secure communication channels to ensure data integrity and client identity.

Key Components in CMG Communication¶

• Configuration Manager Client: The device requiring management, often outside the corporate network.
• Cloud Management Gateway (CMG): An Azure-hosted service that acts as a proxy for internet-based clients.
• CMG Connection Point: A site system role that connects the on-premises Configuration Manager environment to the CMG service in Azure.
• Management Point (MP): The core site system role that provides policy and service location to clients.
• Certificates: Crucial for establishing trust and securing communication, including server authentication certificates for the CMG and potentially client authentication certificates for clients or enhanced HTTP certificates.

A robust understanding of how these components interact and the specific roles of various certificates is foundational to effective CMG troubleshooting. Misconfigurations in any of these areas can lead to connectivity failures, manifesting as various error codes in client and server logs.

---

Error Code 403 (CMGConnector_Clientcertificaterequired)¶

This specific 403 error code indicates a problem with server authentication, specifically related to a missing or improperly configured certificate required by the CMG connection point to communicate with the management point. When this error occurs, clients are effectively blocked from reaching the management point through the CMG. It’s a critical error that prevents any form of policy retrieval or content access for internet-based clients.

Log File Entries Indicating the Issue¶

When Configuration Manager clients encounter this error, specific entries will be recorded in various log files, providing clues to the underlying problem. These log entries are vital for diagnosing the exact nature of the communication breakdown.

LocationServices.log on the client will show entries similar to this:

[CCMHTTP] ERROR: URL=https://cmgsccm.contoso.com/CCM_PROXY_MUTUALAUTH/3456/SMS_MP/.sms_aut?SITESIGNCERT, Port=443, Options=31, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE
[CCMHTTP] ERROR INFO: StatusCode= 403 StatusText= CMGConnector_Clientcertificaterequired

This client-side log clearly indicates that the HTTP request to the CMG URL received a 403 Forbidden status, with the specific StatusText pointing to a client certificate requirement by the CMG connector. This can be misleading as the certificate is actually for server authentication on the CMG connection point.

Concurrently, the SMS_Cloud_ProxyConnector.log on the CMG connection point will log entries like:

Forwarding proxy message \<message ID> to URL: `https://InternalMP.contoso.com/SMS_MP/.sms_aut?SITESIGNCERT`
Web exception for message \<message ID>: System.Net.WebException: **The remote server returned an error: (403) Forbidden**.~~ at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)~~ at Microsoft.ConfigurationManager.CloudConnection.ProxyConnector.ConnectionBase.InternalResponseCallBack(IAsyncResult asynchronousResult)
Received response `https://InternalMP.contoso.com/SMS_MP/.sms_aut?MPLIST2&CM1` for message \<message ID>: HTTP/1.1 403 CMGConnector_Clientcertificaterequired

These server-side logs confirm that the CMG connection point attempted to forward a request to the internal management point but received a 403 Forbidden response, explicitly stating CMGConnector_Clientcertificaterequired. This error originates from the management point side, indicating that it did not receive the expected certificate from the CMG connection point.

Cause: Missing or Invalid Server Authentication Certificate¶

The core reason for this CMGConnector_Clientcertificaterequired error is that the CMG connection point lacks a valid server authentication certificate required to securely forward client requests to an HTTPS management point. While the error text mentions “Client certificate required,” in this context, it refers to the certificate the CMG connection point presents to the management point for server authentication during the secure communication channel establishment.

Specifically, when a management point is configured for HTTPS, it expects a trusted certificate from any connecting entity. The CMG connection point acts as such an entity, bridging the CMG service in Azure to the internal management point. Without a correctly configured and valid server authentication certificate, the HTTPS management point rejects the connection from the CMG connection point, leading to the 403 error. Even in scenarios where the Management Point (MP) operates in enhanced HTTP mode with token-based authentication, a server authentication certificate for the CMG connection point is still highly recommended for robust security and often implicitly expected by underlying communication mechanisms.

Resolution: Generate and Configure a Server Authentication Certificate¶

To rectify this issue, you must ensure that the CMG connection point has a valid server authentication certificate that is trusted by your management point. This certificate facilitates the secure communication channel between these two critical site roles.

Here are the detailed steps to resolve this:

1. Obtain a Server Authentication Certificate:
   • PKI Certificate: The most secure and recommended method is to obtain a server authentication certificate from your Public Key Infrastructure (PKI). This certificate must be issued to the server hosting the CMG connection point role. Ensure it has the “Server Authentication” purpose (OID 1.3.6.1.5.5.7.3.1) and a private key that is exportable if you plan to use it across multiple servers (though typically not needed for the CMG connection point itself, unless for a clustered role).
   • Self-Signed (for testing or specific scenarios): While not recommended for production, in some testing environments, a self-signed certificate with server authentication capabilities can be used. However, it must be trusted by the management point, which means manually importing the self-signed certificate into the Trusted Root Certification Authorities store on the management point server.
2. Import the Certificate:
   • If you obtained a PFX (Personal Information Exchange) file (containing both public and private keys), import it into the Personal store of the computer account on the CMG connection point server.
3. Configure the CMG Connection Point:
   • Open the Configuration Manager console.
   • Navigate to Administration > Site Configuration > Servers and Site System Roles.
   • Select the server hosting the CMG connection point role.
   • In the bottom pane, right-click on CMG connection point and select Properties.
   • On the General tab, specify the certificate. You will typically select “Use a certificate for server authentication” and then browse to select the correct server authentication certificate from the computer’s Personal certificate store. The certificate must have a friendly name that helps identify it easily.
   • Apply the changes. Configuration Manager will then attempt to bind this certificate to the CMG connection point role and use it for communication with the management point.

After configuring the certificate, monitor the SMS_Cloud_ProxyConnector.log file on the CMG connection point and LocationServices.log on a client to ensure that the 403 errors are no longer appearing.

How to Verify the CMG Has a Server Certificate¶

To confirm that a valid server authentication certificate is present and being utilized by the CMG connection point, you can enable verbose logging for the CMG connection point and review its log file.

1. Enable Verbose Logging:
   • Open the Registry Editor (regedit.exe) on the CMG connection point server.
   • Navigate to HKLM\SOFTWARE\Microsoft\SMS\Components\SMS_CLOUD_PROXY_CONNECTOR.
   • Change the value of LoggingLevel from 1 (or 0) to 2 to enable verbose logging.
   • Restart the SMS_Cloud_ProxyConnector component or the SMS_EXEC service for the change to take effect.
2. Check SMS_Cloud_ProxyConnector.log:
   • After enabling verbose logging and allowing some time for activity, open SMS_Cloud_ProxyConnector.log.
   • Look for lines related to certificate filtering and selection. You should see entries that indicate how certificates are being evaluated.
   • Specifically, pay attention to the line indicating Filtered cert count with client auth:. Although the certificate is for server authentication, the CMG connection point may filter based on its capabilities or how it presents itself to the MP. A valid count here suggests suitable certificates are found. If this count is 0, it means no suitable certificate was found by the role, indicating a problem.

Here’s an example of what you might see, where a 0 count signifies a problem:

Filtered cert count with digital signature: 7
Not allowed cert: <certificate>
Not allowed cert: <certificate>
No private key cert: <certificate>
Not allowed cert: <certificate>
Filtered cert count with allowed root CA: 3
Filtered cert count with private key: 3
Not client auth cert: <certificate>
Not client auth cert: <certificate>
Not client auth cert: <certificate>
Filtered cert count with client auth: 0
Maintaining connections...

A Filtered cert count with client auth: 0 directly after evaluation suggests that none of the available certificates met the criteria for being used by the CMG connection point to authenticate to the management point. This could be due to missing private keys, incorrect enhanced key usage, or trust issues. A positive count (e.g., 1 or more) would indicate that a suitable certificate was found and should be used.

Error Code 403 (CMGConnector_Forbidden)¶

Another variation of the 403 error, CMGConnector_Forbidden, typically points to an issue with Internet Information Services (IIS) bindings on the management point, particularly when transitioning between different HTTP communication modes. This error signifies that the management point explicitly rejected the connection from the CMG, often due to a mismatch in expected authentication mechanisms or invalid certificate configurations within IIS itself.

Log File Entries Indicating the Issue¶

When this specific 403 error occurs, client-side logs will capture the CMGConnector_Forbidden status text.

LocationServices.log on the client will log entries similar to:

[CCMHTTP] ERROR: URL=https://cmgsccm.contoso.com/CCM_PROXY_MUTUALAUTH/3456/SMS_MP/.sms_aut?SITESIGNCERT, Port=443, Options=31, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE
[CCMHTTP] ERROR INFO: StatusCode= 403 StatusText= CMGConnector_Forbidden

Similar to the previous 403 error, this indicates a failure to communicate with the CMG-proxied management point. However, the StatusText of CMGConnector_Forbidden provides a different diagnostic path, suggesting a general access restriction rather than a specific certificate requirement from the CMG connector perspective. The root cause usually lies within the management point’s IIS configuration.

Cause: IIS Bindings and MP HTTP Mode Mismatch¶

The primary cause of CMGConnector_Forbidden is a mismatch between the Internet Information Services (IIS) bindings on the management point and its configured HTTP communication mode. This issue frequently arises under the following circumstances:

• Management Point Mode Change: If a management point is switched from HTTPS mode (requiring a PKI server authentication certificate) to enhanced HTTP mode (using a Configuration Manager-issued “SMS Role SSL certificate” and token-based authentication) without properly updating or cleaning the IIS bindings, the client might struggle to configure the correct SMS Role SSL certificate for the new mode. The previous HTTPS binding might still be present or misconfigured, leading to conflicts.
• Incorrect or Expired Certificate: An invalid, expired, or revoked certificate might be incorrectly bound to port 443 in IIS on the management point. When the CMG connection point attempts to establish a secure channel, IIS presents this faulty certificate, leading to a rejection and the “Forbidden” status.
• Trust Issues: Although less common with CMGConnector_Forbidden, trust issues with the certificate presented by IIS can also contribute, similar to ERROR_WINHTTP_SECURE_FAILURE but manifested differently if the initial binding itself is problematic.

The management point, hosted within IIS, relies on these bindings to define how it handles incoming secure connections. An improper certificate or an outdated binding can cause the management point to reject connections, even from trusted sources like the CMG connection point.

Resolution: Correct IIS Site Bindings¶

To resolve the CMGConnector_Forbidden error, you must meticulously review and correct the IIS site bindings on the management point server to ensure they align with your Configuration Manager site’s communication security settings.

Follow these detailed steps to address the issue:

1. Access IIS Manager:
   • Log in to the server hosting the Configuration Manager management point role.
   • Open IIS Manager by typing inetmgr in the Run dialog or searching for “Internet Information Services (IIS) Manager” in the Start Menu.
2. Navigate to Site Bindings:
   • In the Connections pane on the left, expand the server name, then expand Sites.
   • Select Default Web Site. This is the common location for Configuration Manager web services. If your site uses a different web site, select that one.
3. Review and Edit Bindings:
   • In the Actions pane on the right, under “Edit Site,” select Bindings…. This will open the Site Bindings dialog box.
   • Locate the binding for https on port 443. If multiple HTTPS bindings exist, carefully examine each. You should typically only have one active HTTPS binding for the Configuration Manager services.
   • Select the https binding on port 443 and then click Edit….
4. Select the Correct SSL Certificate:
   • In the Edit Site Binding dialog, the “SSL certificate” dropdown menu is critical. You must select the appropriate certificate based on your management point’s communication security mode:
     • For Enhanced HTTP Mode: Select the SMS Role SSL certificate. This certificate is internally generated and managed by Configuration Manager when your site is configured for Enhanced HTTP. It allows clients to communicate with site systems using token-based authentication over HTTPS.
     • For HTTPS Mode (PKI): Select a valid public key infrastructure (PKI) server authentication certificate. This certificate must be issued by a trusted Certificate Authority (CA) in your environment, have the server authentication EKU, and be trusted by both the CMG connection point and potentially internet-based clients.
   • Remove Old/Incorrect Bindings: If you find multiple or incorrect https bindings, especially older ones from previous configurations (e.g., a PKI certificate binding still present after moving to Enhanced HTTP), it’s often best to remove the incorrect binding. Create a backup of your IIS configuration before making significant changes.
   • Click OK to save the changes in the Edit Site Binding dialog, then Close the Site Bindings dialog.
5. Verify Configuration Manager Site Settings:
   • In the Configuration Manager console, navigate to Administration > Site Configuration > Sites.
   • Right-click your primary site and select Properties.
   • Go to the Communication Security tab and verify that the “Client computer communication” setting matches your IIS configuration (either “HTTPS” or “Enhanced HTTP”). This ensures consistency.
6. Restart IIS and SMS Executive Service:
   • To ensure the changes take effect, it’s highly recommended to restart IIS (using iisreset from an elevated command prompt) and the SMS Executive service on the management point server.

After making these changes, monitor client communication and the relevant log files (e.g., LocationServices.log, SMS_Cloud_ProxyConnector.log) to confirm that the CMGConnector_Forbidden errors have ceased. Consistent and accurate IIS bindings are paramount for reliable CMG and management point communication.

---

Error Code 0x2f8f (ERROR_WINHTTP_SECURE_FAILURE)¶

The error code 0x2f8f, or ERROR_WINHTTP_SECURE_FAILURE, is a common indicator of underlying issues with the SSL/TLS negotiation between the Configuration Manager client and the Cloud Management Gateway. This error signifies that the secure connection could not be established due to various certificate-related problems, often involving trust, revocation checking, or certificate name mismatches. It’s a fundamental security failure during the initial handshake.

Log File Entries Indicating the Issue¶

When clients encounter ERROR_WINHTTP_SECURE_FAILURE, the LocationServices.log on the client will show detailed entries regarding the secure connection failure.

A typical error entry looks like this:

[CCMHTTP] ERROR: URL=https://CMG.CONTOSO.COM/CCM_Proxy_ServerAuth/72057594037928017/CCM_STS, Port=443, Options=63, Code=12175, Text=ERROR_WINHTTP_SECURE_FAILURE

Before this final error message, LocationServices.log often provides more granular details about why the secure failure occurred, typically logged during the AsyncCallback() function:

[CCMHTTP] AsyncCallback():
[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered
[CCMHTTP] : dwStatusInformationLength is 4
[CCMHTTP] : lpvStatusInformation is 0x9
[CCMHTTP] : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set
[CCMHTTP] : WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set
[CCMHTTP] : WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID is set

These preceding WINHTTP_CALLBACK_STATUS_FLAG entries are crucial for pinpointing the exact nature of the secure failure.
* WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Indicates that the client could not check the certificate’s revocation status (e.g., CRL or OCSP server unreachable).
* WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA: Means the client does not trust the Certificate Authority (CA) that issued the certificate presented by the CMG.
* WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID: Signifies a mismatch between the certificate’s Subject Name (Common Name or CN) or Subject Alternative Name (SAN) and the CMG’s FQDN that the client is trying to connect to.

Cause: Trust, Name Mismatch, or Revocation Issues¶

The ERROR_WINHTTP_SECURE_FAILURE error typically occurs if one or more of the following critical conditions related to certificate validation are true:

• Client Lacks Necessary PKI Root CA: The client does not possess the Public Key Infrastructure (PKI) Root Certificate Authority (CA) certificate in its local Trusted Root Certification Authorities store. Consequently, it cannot validate the trust chain of the server authentication certificate presented by the CMG, deeming it untrusted. This is a common issue when using a custom or enterprise PKI without proper client distribution of the root certificate.
• Incorrect Certificate Presented: The CMG presents a certificate that is incorrect or not valid for the CMG service. This could be a certificate with an incorrect FQDN, an expired certificate, a certificate issued for a different service, or one tampered with by intermediate network devices (e.g., SSL inspection proxies that modify the certificate presented to the client).
• CRL Not Accessible or Enabled: The Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) endpoint, which is used to verify that the CMG’s certificate has not been revoked, is not published on the internet or is otherwise unreachable by the client. If Configuration Manager is configured to force clients to check CRLs (which is the default and a good security practice), but the client cannot access the CRL distribution point, the secure connection will fail.

These issues directly impact the client’s ability to establish a cryptographically secure and trusted connection with the CMG, leading to the ERROR_WINHTTP_SECURE_FAILURE.

Resolution: Address Certificate Trust, Name, and Revocation¶

Resolving ERROR_WINHTTP_SECURE_FAILURE requires a methodical approach to verify and correct certificate-related configurations. If you are using a PKI server authentication certificate for your CMG, follow these steps:

1. Verify the CMG’s Presented Certificate:

   • Check CMG Name: Ensure that the certificate presented by the CMG has the expected CMG name in its Subject Name (CN) or Subject Alternative Name (SAN). The FQDN configured for your CMG in Azure and in Configuration Manager must exactly match the name(s) on the certificate.
   • Avoid External Interference: Be aware that certain non-Microsoft services or network appliances (like firewalls with SSL inspection, load balancers, or proxies that perform certificate pinning or re-encryption) might intercept and modify the certificate presented to the client. This can result in the client receiving a certificate that doesn’t match the expected CMG certificate, causing validation errors.
   • Direct Browser Check: To verify which certificate is actually presented by your CMG from an internet client’s perspective, open a web browser on an internet-connected client and navigate to the following URL:
     https://<CMGFQDN>/CCM_Proxy_MutualAuth/ServiceMetadata
     Replace <CMGFQDN> with your CMG’s public fully qualified domain name (e.g., cmgsccm.contoso.com). Examine the certificate details shown by the browser (usually by clicking the padlock icon in the address bar). Confirm the issuer, validity period, and most importantly, the Subject Alternative Names (SANs) or Subject Common Name (CN) match your CMG’s FQDN.

2. Ensure Client Trust for the Root CA:

   • Root Certificate Distribution: The client must have the entire certificate chain, particularly the Root Certificate Authority (CA) certificate that issued the CMG’s server authentication certificate, installed in its local Trusted Root Certification Authorities certificate store. If the client doesn’t trust the Root CA, it cannot validate the CMG’s certificate, regardless of the certificate’s validity or name match.
   • Modern Authentication Consideration: While Microsoft Entra ID or token-based authentication might handle client authentication to the CMG, the CMG still needs a server authentication certificate for its own identity, and the client still needs to trust this certificate’s issuer. This trust is essential for the secure transport layer (TLS) even when using modern authentication methods. When you use a non-Microsoft PKI certificate for authentication, ensure the public Root CA is discoverable and trusted by internet clients, often implying it’s a publicly trusted CA or its root has been distributed via other means.

3. Manage Certificate Revocation List (CRL) Checking:

   • CRL Accessibility: If your CRL Distribution Points (CDPs) or OCSP responders are not publicly accessible on the internet, or if your CMG certificate’s CRL is not published on the internet, clients attempting to validate the certificate’s revocation status will fail.
   • Disable CRL Checking (Use with Caution): If internet-based CRL checking is genuinely not feasible and you accept the associated security risk (clients won’t verify if a certificate has been revoked), you can disable CRL checking for clients communicating with site systems:
     1. In the Configuration Manager console, navigate to the Administration workspace.
     2. Expand Site Configuration, and then select the Sites node.
     3. Select the primary site you want to configure.
     4. In the ribbon, select Properties.
     5. On the Communication Security tab, clear the Clients check the certificate revocation list (CRL) for site systems checkbox.
   • Client Installation Parameter: When installing clients from the internet, if you have disabled CRL checking for site systems, you must also ensure that the /NoCRLCheck parameter is included in the CCMSetup command line. This tells the client installation process not to attempt CRL validation, preventing installation failures due to inaccessible CRLs. For example: ccmsetup.exe /mp:CMGFQDN /source:CMGInstallSource /NoCRLCheck

Disabling CRL checking reduces the security posture of your environment as clients can no longer verify if a certificate has been compromised. It should only be considered as a last resort if all other options for making the CRL publicly accessible are exhausted. Always prioritize a robust PKI with accessible CRLs or OCSP responders for optimal security.

---

Error Code 401 (CMGService_Invalid_Token)¶

The CMGService_Invalid_Token error, indicated by a 401 HTTP status code, specifically points to an authentication failure related to the security token used by the Configuration Manager client. This error typically occurs when the client attempts to authenticate with an expired or improperly configured token, hindering its ability to communicate with the CMG or management point. It’s a clear signal that the client’s identity could not be verified by the CMG service.

Log File Entries Indicating the Issue¶

When clients encounter CMGService_Invalid_Token, their log files will capture the 401 status code and the specific StatusText.

Ccmsetup.log (if client installation is involved) or LocationServices.log (for regular client communication attempts) will show:

[CCMHTTP] ERROR: URL=https://CMGSERVER.CLOUDAPP.NET/CCM_Proxy_ServerAuth/ServiceMetadata , Port=443, Options=224, >Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE
[CCMHTTP] ERROR INFO: StatusCode=401 StatusText=CMGService_Invalid_Token

This log entry on the client indicates that the HTTP request to the CMG received a 401 Unauthorized response, specifically tied to an invalid token.

More detailed information, confirming the token expiration, will be found in CCM_STS.log on the management point (or the CMG connection point, depending on where the token validation occurs):

Return code: 401, Description: PreAuth token validation failed, System.IdentityModel.Tokens.SecurityTokenExpiredException:
IDX10223: Lifetime validation failed. The token is expired.
ValidTo: '10/01/2020 22:03:24'
Current time: '10/28/2020 13:05:05'.
   at System.IdentityModel.Tokens.Validators.ValidateLifetime....

This server-side log is definitive, explicitly stating SecurityTokenExpiredException and showing a clear mismatch between the token’s ValidTo timestamp and the Current time. This conclusively proves that the token presented by the client had exceeded its validity period.

Cause: Expired or Invalid Token¶

This issue occurs because the security token used by the client for authentication has either expired or was not properly obtained or added during client setup. This scenario typically arises under two main conditions:

• Token Expiration: Configuration Manager clients, particularly those communicating over the internet via CMG, utilize tokens for authentication. These tokens have a limited lifespan. If a client fails to communicate with the site (either directly with an internal management point or through the CMG) for an extended period (typically more than 30 days, which is the default renewal interval for client identity tokens), its existing token can expire. Once expired, the CMG service will reject any authentication attempts with that token, leading to a 401 error.
• Improper Token Usage during CCMSetup: If the CCMSetup command is used with the /regtoken parameter for client installation, and the provided bulk registration token is already expired or malformed, the client installation process will fail with this 401 error. Bulk registration tokens also have a limited validity period (e.g., 7 days by default from issuance) to enhance security.

The underlying mechanism relies on these tokens to establish and maintain a trusted identity for the client. When this trust mechanism breaks due to expiration or invalidity, the CMG service cannot authorize the client’s requests.

Resolution: Renew Token or Reinstall Client¶

To resolve the CMGService_Invalid_Token error, you must ensure the client obtains a valid, unexpired security token. There are two primary approaches depending on the client’s current state and network connectivity:

1. Renew the Expired Token (Internal Network Access):

   • If the client is physically brought back into the internal corporate network, it can directly communicate with an on-premises management point. During this direct communication, the client will automatically renew its security token.
   • Once the token is renewed, the client should be able to communicate with the CMG again when it moves back to the internet. This is the simplest solution if direct network access is feasible.
   • Verification: After the client connects internally, check its ClientIDManagerStartup.log for successful token renewal messages. Then, move the client back to the internet and verify CMG communication via LocationServices.log.

2. Reinstall the Client with a New Bulk Registration Token (Internet Only):

   • If the client cannot access the internal network, you must reinstall the client using a new, valid Bulk registration token. Bulk registration tokens are generated from the Configuration Manager console and are specifically designed for internet-based client installations.
   • Generate a New Bulk Registration Token:
     1. In the Configuration Manager console, navigate to Administration > Overview > Cloud Services > Cloud Management Gateway.
     2. Select your CMG, then from the ribbon, select Client Certificate for Cloud Management Gateway.
     3. Click Create Token.
     4. Copy the generated token string. Note its expiry date (default is 7 days).
   • Reinstall the Client:
     1. On the internet-connected client, uninstall the existing Configuration Manager client using Ccmsetup.exe /uninstall.
     2. Reinstall the client using the CCMSetup command line with the newly generated bulk registration token:
        ccmsetup.exe /mp:https://<CMGFQDN> /ccmhostname:<CMGFQDN> /regtoken:<YOUR_NEWLY_GENERATED_TOKEN> /nocertcheck
        (Replace <CMGFQDN> with your CMG’s FQDN and <YOUR_NEWLY_GENERATED_TOKEN> with the token string.)
        The /nocertcheck parameter might be necessary if your CMG uses a public certificate that isn’t publicly trusted by default or for testing, but ideally, the CMG’s certificate should be trusted.
   • Verification: After reinstallation, monitor the Ccmsetup.log for successful installation and registration. Then, check LocationServices.log and ClientIDManagerStartup.log for successful communication with the CMG and management point.

Remember to generate a new bulk registration token each time it’s needed, as they are single-use and time-limited for security reasons. Also, ensure the client’s system time is accurate, as significant time differences can cause token validation failures even if the token itself is technically valid.

---

More Information and General Troubleshooting Best Practices¶

Beyond specific error codes, a comprehensive approach to troubleshooting Configuration Manager CMG communication issues involves several best practices and general steps. These strategies can help diagnose problems that may not fit neatly into a single error category or provide insights when initial resolutions don’t yield results.

General Troubleshooting Steps¶

1. Review CMG Health and Status:
   • In the Configuration Manager console, navigate to Administration > Cloud Services > Cloud Management Gateway.
   • Check the “Connection point status” and “Service status.” Look for green checkmarks. Any warnings or errors here often point to Azure service issues or misconfigurations within the CMG itself.
   • Review the CMG connection point status on the “Monitoring” workspace > “Component Status” and “Site System Status” nodes.
2. Check Azure Resource Health:
   • Log in to the Azure portal and navigate to your CMG’s resource group.
   • Check the health and status of the CMG service (Cloud service), storage account, and other related resources. Ensure they are running and healthy.
3. Validate Network Connectivity:
   • From the CMG connection point server, ensure it can communicate outbound to Azure endpoints on required ports (typically 443).
   • From a client on the internet, verify it can resolve the CMG’s FQDN and reach it on port 443. Tools like ping (though not over HTTPS), telnet, or Test-NetConnection (PowerShell) can be helpful.
4. Certificate Chain Validation:
   • Verify the entire certificate chain on both the CMG connection point (for its server authentication certificate) and the CMG service in Azure (for its server authentication certificate). Ensure all intermediate CAs and the Root CA are trusted by all relevant parties (CMG connection point, management point, and clients).
   • Use certutil -verify -urlfetch <certificate_file> to validate certificate chains and CRLs if possible.
5. Time Synchronization:
   • Ensure that the system clocks on the client, CMG connection point, and management point servers are synchronized. Significant time differences can invalidate certificates and security tokens.
6. Firewall and Proxy Configurations:
   • Verify that no firewalls (Windows Firewall on servers, network firewalls, Azure Network Security Groups) or proxy servers are blocking necessary ports or URLs. The CMG connection point needs outbound access to Azure, and clients need outbound access to the CMG’s public endpoint.
7. Enable Verbose Logging:
   • As demonstrated in previous sections, increasing the logging level for relevant components (e.g., SMS_CLOUD_PROXY_CONNECTOR, CCMHTTP components on the client) can provide much more detailed information in the logs, which is invaluable for diagnosis. Remember to revert logging levels after troubleshooting to avoid excessive log file growth.
8. Management Point Health:
   • Ensure the management point itself is healthy and functioning correctly. Check its log files (e.g., MP_GetAuth.log, MP_Location.log, MP_Policy.log) for any errors that might be preventing it from processing requests forwarded by the CMG.

Common CMG Architecture (Diagram)¶

Understanding the flow of communication visually can significantly aid in troubleshooting.

```mermaid
graph TD
subgraph Internet
Client[ConfigMgr Client]
end

subgraph Azure
    CMG(Cloud Management Gateway)
end

subgraph On-Premises
    CMGCP(CMG Connection Point)
    MP[Management Point]
    DB[(Site Database)]
end

Client -- HTTPS (443) --> CMG
CMG -- HTTPS (443) --> CMGCP
CMGCP -- HTTPS (443) --> MP
MP -- SQL --> DB

style Client fill:#f9f,stroke:#333,stroke-width:2px
style CMG fill:#bbf,stroke:#333,stroke-width:2px
style CMGCP fill:#bfb,stroke:#333,stroke-width:2px
style MP fill:#ffb,stroke:#333,stroke-width:2px
style DB fill:#fdd,stroke:#333,stroke-width:2px

```
This diagram illustrates the logical path a Configuration Manager client on the internet takes to communicate with its management point via the Cloud Management Gateway. Each arrow represents a point where secure communication and certificate validation are critical, and where failures can manifest as the errors discussed.

By systematically working through these troubleshooting steps and understanding the specific implications of each error code, Configuration Manager administrators can effectively diagnose and resolve connectivity issues with their Cloud Management Gateway, ensuring robust management of internet-based clients.

---

We hope this detailed guide has been helpful in resolving your Configuration Manager CMG communication challenges. If you have encountered similar issues and found alternative solutions, or if you have further questions or insights, please feel free to share them below. Your contributions help the entire community improve their Configuration Manager deployments.