A sales rep goes fully remote for six weeks — no VPN, no office visits, home Wi-Fi and airport lounges. Compliance policy stops evaluating. Software Center stops showing new deployments. Endpoint protection definitions go stale. Back at head office, the CMG dashboard looks perfectly healthy: the service is running, the connection point shows green, traffic graphs are flowing for everyone else. But this one device — and a growing list of others — just isn't checking in. The console calls it "not connected to CMG," and that phrase tells you almost nothing about where the problem actually is.
This post explains what a Cloud Management Gateway actually does, which components have to work together for it to function, and why — in the overwhelming majority of real cases — a healthy-looking CMG deployment with a disconnected client comes down to a certificate trust problem or a CRL/OCSP reachability issue on the client's network, not a fault in the gateway itself.
The problem
Cloud Management Gateway (CMG) exists to solve one specific problem: Configuration Manager was built for devices sitting on a corporate network, and modern devices don't sit on corporate networks anymore. CMG lets ConfigMgr-managed devices check in and get policy, content, and inventory collection from the internet, without a VPN, by routing that traffic through an Azure-hosted gateway back to your on-premises site.
When it's working, an internet-based client behaves almost identically to one sitting in the office — it gets machine policy, downloads applications and updates, submits inventory, and shows up in the console as an online client. When it stops working, the symptom is rarely a crash or an error dialog. It's silence: no new policy, no new deployments, no fresh inventory, and eventually a device that looks stale or noncompliant in Intune even though nothing was changed on it.
Why it happens
To understand why this fails the way it does, you need to know what's actually sitting between the client and your on-premises site. CMG is not a single thing — it's three coordinated components, per Microsoft's own architecture documentation:
- The CMG cloud service — deployed in Azure (as a virtual machine scale set on current versions), this authenticates and forwards Configuration Manager client requests over the internet to the on-premises CMG connection point. It's a certificate-based HTTPS web service from the client's point of view.
- The CMG connection point — a site system role installed on an on-premises server. It maintains the outbound connection from your network to the CMG service in Azure, publishes connection and security settings to it, and forwards client requests to the right on-premises roles — typically the management point and software update point — according to URL mappings.
- Certificates — a server authentication certificate for the CMG cloud service itself (required in every deployment), plus, depending on your client authentication model, either PKI client authentication certificates, Configuration Manager site-issued tokens, or Microsoft Entra ID for client identity. If you use PKI client certificates, the CMG also needs the trusted root certificates for that PKI chain, and — critically — a publicly reachable certificate revocation list (CRL) if you leave the default "Verify Client Certificate Revocation" option enabled.
Every one of those pieces has to be correct at the same time for a client to connect successfully. But here's the part that catches people out: the CMG cloud service and CMG connection point are usually the most stable part of the chain. Once deployed, they don't drift. Certificates, by contrast, expire, get reissued with a different chain, or depend on infrastructure — a CRL distribution point, an OCSP responder — that has to be reachable from wherever the client currently is, which for an internet-based device could be anywhere.
This is why a device on the corporate LAN and the exact same device tethered to a phone hotspot can behave completely differently. On the LAN, CRL/OCSP endpoints are usually reachable through internal DNS and internal firewall rules. Off the LAN, those same endpoints may sit behind on-premises-only network paths that were never designed to be reachable from the open internet — so the certificate check silently times out or fails, and the client falls back to "can't connect."
How to verify
Before assuming the gateway is broken, separate "is the service healthy" from "can this specific client reach and trust it." These are different questions and need different checks.
Start server-side. In the Configuration Manager console, the Cloud Management Gateway node under Administration > Cloud Services shows the deployment status, and the built-in Connection analyzer tool lets you simulate a client connection using either a Microsoft Entra user or a client certificate — a genuinely useful first check, because it tests the service, the connection point, and the path to the management point without needing an actual remote device.
Then check the client itself. Three client-side log files are the ones that actually show what a specific device is doing when it tries to reach management points, software update points, and distribution points — including a CMG:
- LocationServices.log — records the client activity for locating management points, software update points, and distribution points. This is where you'll see the client attempting to resolve and use a CMG-published management point location.
- ClientLocation.log — records tasks related to client site assignment.
- CcmMessaging.log — records activities related to communication between the client and management points, including the actual policy request/response traffic that would go through a CMG.
%WINDIR%\CCM\Logs on the client. Open them in CMTrace (or any tail-capable viewer) rather than Notepad — CMTrace highlights errors and warnings inline, which matters when you're scanning for a single certificate failure buried in routine location-service chatter.CRL = true flag in the log line is the whole story. It confirms the client is enforcing certificate revocation checking on this connection attempt. If the revocation status can't be determined — because the CRL endpoint or OCSP responder is unreachable from the client's current network — this call fails exactly the way it would if the certificate itself were invalid, even though nothing is actually wrong with the cert.On the network side, confirm the client can actually resolve and reach the CMG's public endpoint and any CRL distribution points it depends on. A basic Test-NetConnection against the CMG's HTTPS endpoint on port 443, plus a check that the CRL distribution point URL embedded in the certificate is reachable, tells you whether this is a network path problem before you go anywhere near the ConfigMgr console.
The fix
Work through this in order — server health first, then certificate trust, then network reachability. Don't jump straight to rebuilding the CMG; in the majority of cases the gateway itself is fine.
- Go to Administration > Cloud Services > Cloud Management Gateway.
- Select the CMG instance and confirm its Status shows Ready/running, not a deployment or error state.
- Select the CMG, then choose Connection analyzer in the ribbon.
- Choose Client certificate (if you use PKI auth) or Microsoft Entra user (if you use Entra ID auth), authenticate, and select Start.
- Review each stage of the result — service reachability, connection point path, and management point response — and note exactly which stage fails, if any.
If the connection analyzer passes cleanly but real clients still can't connect, the fault is almost certainly specific to those clients' network paths or certificates rather than the CMG deployment. Move to the certificate side:
- Go to Administration > Site Configuration > Sites.
- Select the primary site your internet-based clients are assigned to, then choose Properties.
- Switch to the Communication Security tab.
- Confirm the client authentication model configured here (PKI client certificate vs. Entra ID vs. token) matches what you expect the failing devices to be using.
- If you don't have a publicly reachable CRL, and you're relying on PKI client certificates, disable Clients check the certificate revocation list (CRL) for site systems — but only after confirming with your PKI team that skipping revocation checking is an acceptable risk for your organisation.
If CRL/OCSP reachability is the actual root cause — which it is in most "healthy CMG, disconnected client" tickets — the fix is on the PKI and network side, not inside ConfigMgr:
- Identify the CRL distribution point URL(s) embedded in the client authentication certificate template.
- Confirm that URL is published somewhere reachable from the public internet — an HTTP CDP location, not just an internal CA server share.
- If you use OCSP instead of or alongside CRL, confirm the OCSP responder URL is likewise internet-reachable and not blocked by an internal-only firewall rule.
- Re-test from an actual internet-based network path (a hotspot, a home connection outside your corporate VPN) — not from inside the office, where internal DNS and firewall rules can mask the exact failure remote users see.
Proof it worked
"It's back in the console" isn't proof — the console can lag behind the client's real state. Confirm on the device itself, and confirm the mechanism (cert/CRL), not just the symptom (device shows online again).
Test-CMGClientConnectivity.ps1 is free and open source. It's a genuinely read-only script — no writes to Autopilot, Intune, or Entra ID.
A genuinely resolved device should show fresh, successful entries in LocationServices.log and CcmMessaging.log — not just an absence of new errors, but actual new successful management point lookups and policy retrieval timestamped after your fix. If the CRL/OCSP path was the root cause, you should also be able to independently confirm — via a plain network test from that same device and network — that the CRL or OCSP endpoint is now reachable, separate from anything ConfigMgr reports.