1 24/05/2026 10 min

Quando SCCM non riesce ad accedere ad Azure tramite Cloud Management Gateway, il problema quasi mai è “Azure generico”. Di solito si rompe uno dei punti di contatto tra ConfigMgr, il tenant Entra ID, il certificato del servizio cloud, il servizio del Management Point o il livello di autenticazione usato dal client. Il modo corretto di trattarlo è separare subito il layer: tenant e subscription, registrazione del CMG, endpoint pubblico, token Azure AD, poi log lato site server e client.

Se il sintomo è un errore di accesso ad Azure in SCCM CMG, il caso tipico è questo: il CMG risulta creato, ma la console mostra stato degradato, il provisioning fallisce, i client non si autenticano oppure il servizio cloud non riesce a parlare con i componenti Azure. L’errore può apparire come access denied, unauthorized, invalid tenant, certificate chain problem, oppure come un fallimento più vago nel provisioning del role o nel refresh del token. La chiave è non saltare subito alla reinstallazione del CMG: prima si verifica dove si interrompe la catena.

Layer da isolare prima di cambiare qualcosa

Il percorso logico è questo: DNS e reachability verso gli endpoint Azure, autenticazione del tenant, validità del certificato usato dal CMG, configurazione del servizio cloud in ConfigMgr, quindi autorizzazione del client e dei ruoli di site. Se il problema è in produzione, considera l’impatto utenti fino a prova contraria: un cambio sul CMG può interrompere l’accesso remoto di client fuori rete o di dispositivi internet-only.

Stato atteso: il CMG deve risultare online, il provisioning deve essere completato, il Management Point cloud deve registrarsi correttamente e i client devono ottenere policy e content over internet. Stato osservato: uno o più di questi passaggi fallisce con errori di autorizzazione, time-out o certificato. L’obiettivo non è “far ripartire tutto” alla cieca, ma trovare il punto esatto in cui Azure rifiuta la richiesta o ConfigMgr non riesce a completare la handshake.

Controlli rapidi su Azure e su ConfigMgr

Parti dal dato verificabile più semplice: la console di Configuration Manager e i log del site server. I file più utili, a seconda del punto di guasto, sono CloudMgr.log, CMGService.log, SMS_Cloud_ProxyConnector.log, SMS_CLOUD_PROXYCONNECTOR.log e, lato client, CcmMessaging.log e LocationServices.log. Se il problema è nel provisioning o nel rinnovo del servizio cloud, CloudMgr.log di solito parla chiaro.

Da site server, verifica prima che il servizio e la connettività base siano sani. Un errore di autenticazione Azure spesso si accompagna a messaggi che citano tenant, app registration, subscription, certificate thumbprint o invalid response from Azure. La presenza di un errore “unauthorized” non significa automaticamente che il problema sia il client: può essere il site server che non ha più credenziali valide per parlare con il tenant.

Comandi utili per un primo giro

Esegui controlli non distruttivi sul server del site o su una macchina con accesso amministrativo alla console:

Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, CcmExec | Select-Object Name, Status
Test-NetConnection login.microsoftonline.com -Port 443
Test-NetConnection management.azure.com -Port 443
Test-NetConnection <nome-cmg>.cloudapp.net -Port 443

Il risultato atteso è connettività TCP 443 stabile verso gli endpoint Azure e verso il nome pubblico del CMG. Se uno di questi test fallisce, il problema può essere più basso del layer applicativo: proxy, firewall, DNS o ispezione TLS. Se invece la connettività c’è, si torna su autenticazione e configurazione del tenant.

Controlla anche la configurazione del CMG in console: subscription, region, nome del servizio, certificato associato, e il tipo di autenticazione configurato per i client. Un dettaglio banale ma frequente è il mismatch tra tenant previsto e tenant realmente usato nella subscription o nell’app registration. Altro errore classico: certificato ancora presente in console ma non più valido, non più associato alla chiave privata o con catena incompleta sul server.

Diagnosi probabile

Le tre cause più probabili, in ordine pratico, sono queste:

  1. Credenziali Azure/Entra non più valide o non più autorizzate: app registration, secret, certificato client o permessi della subscription/tenant non corrispondono più alla configurazione CMG.

  2. Certificato del CMG o della catena non corretto: certificato scaduto, thumbprint sbagliato, chiave privata mancante, catena non trusted sul server del site o sul componente che effettua la richiesta.

  3. Blocco di connettività o endpoint sbagliato: proxy, firewall, DNS, inspection TLS o endpoint Azure non raggiungibili; in questo caso l’errore sembra di accesso, ma è un fallimento di trasporto.

Come falsificarle in pochi minuti: se il ping applicativo su 443 verso gli endpoint Azure fallisce, la terza ipotesi sale in cima. Se la rete è ok ma CloudMgr.log riporta unauthorized, invalid tenant, certificate error o token failure, la prima e la seconda sono quelle da inseguire. Se il CMG è stato modificato di recente, il cambio più recente è quasi sempre il colpevole: nuovo certificato, rotazione del secret, cambio di subscription, modifica RBAC o spostamento di tenant.

Verifiche immediate su log e stato del servizio

Apri i log del site server con CMTrace e cerca parole chiave precise: unauthorized, forbidden, certificate, thumbprint, subscription, tenant, proxy, timeout. Non basta vedere un errore generico: serve il codice o la riga che identifica il layer. In molti casi il log mostra chiaramente se il problema è l’autenticazione verso Azure o la registrazione del servizio cloud.

Se hai accesso alla console, verifica lo stato del CMG e del Cloud Management Gateway Connection Point. Se uno dei due è in errore, il problema si localizza quasi sempre tra site server e Azure, non sul client. Se invece il CMG è online ma i client non si connettono, allora l’attenzione va su certificati client, Boundary Groups, internet-based client management e policy di fallback.

Un controllo utile è la presenza di eventi o messaggi relativi al provider WMI e al component manager. Se il site server ha avuto riavvii, patch recenti o rotazioni di certificati, può esserci una discrepanza tra ciò che la console mostra e ciò che il componente cloud sta realmente usando. In questi casi il log è più affidabile della UI, ma la UI serve per confermare il dato amministrativo: tenant, subscription, nome servizio e stato del provisioning.

Soluzione consigliata passo-passo

Procedi in modo reversibile, senza toccare subito il CMG in produzione. Ogni passo sotto ha un punto di verifica dopo l’esecuzione.

  1. Conferma la reachability verso Azure. Da site server esegui i test TCP 443 verso gli endpoint usati dal servizio cloud. Se falliscono, correggi prima proxy, firewall o DNS. Verifica attesa: connessione TCP stabilita e nessun timeout nei log di sistema o nel proxy.

  2. Controlla la validità del certificato del CMG. Verifica data di scadenza, thumbprint e presenza della chiave privata. Se il certificato è scaduto o non corrisponde a quello configurato in console, prepara un rinnovo. Verifica attesa: certificato presente, non scaduto, catena completa, chiave privata accessibile dal server che gestisce il ruolo.

  3. Verifica app registration e permessi. Controlla che l’app usata da ConfigMgr abbia i permessi richiesti nella subscription o nel tenant e che il secret o il certificato associato non sia scaduto. Se c’è stato un cambio di credenziali, aggiorna solo il dato minimo necessario. Verifica attesa: la chiamata di autenticazione non restituisce più unauthorized o invalid client.

  4. Riesegui la sincronizzazione o il refresh del componente cloud. Dopo aver corretto il dato errato, forza il refresh del componente dal lato ConfigMgr secondo la procedura prevista dalla tua versione. Verifica attesa: CloudMgr.log e i log del connector mostrano provisioning completato o stato online.

  5. Se il CMG è in errore ma la configurazione è corretta, valuta un riavvio controllato del servizio coinvolto. Non è un fix strutturale, ma può sbloccare un token cache o una sessione corrotta. Blast radius: il ruolo cloud può interrompersi temporaneamente, quindi eseguilo in finestra e con rollback pronto. Verifica attesa: il ruolo torna online senza cambiare altri parametri.

  6. Solo se il problema persiste, ricrea il componente cloud con dati già validati. È l’ultima opzione, non la prima. Prima esporta o annota la configurazione, certificato, subscription, tenant, nome del servizio e parametri client. Verifica attesa: nuovo provisioning completato e client in grado di registrarsi.

Se il tuo scenario usa un proxy in uscita, non sottovalutarlo. Un proxy che richiede autenticazione o che ispeziona TLS può rompere la comunicazione con Azure senza generare un errore immediatamente leggibile nella console. In quel caso, prova a escludere temporaneamente gli endpoint Microsoft richiesti dal CMG dal filtraggio o dall’ispezione, sempre con change controllato e rollback documentato. Il test deve essere mirato: non aprire Internet, apri solo le destinazioni necessarie.

Se il problema è lato client, il modo corretto di verificare è un client internet-based che non si appoggia alla rete interna. Guarda LocationServices.log per capire se il client riceve la location del CMG e CcmMessaging.log per vedere il tentativo di handshake. Se il client non riceve il CMG, il guasto può essere in boundary, assignment, policy o certificatistica client. Se riceve il CMG ma non si autentica, la parte da controllare è il certificato client e il mapping con il metodo di autenticazione configurato.

Snippets utili per isolare il problema

Su un client o sul site server puoi usare questi controlli di base senza fare modifiche:

Get-Date
Resolve-DnsName <nome-cmg>.cloudapp.net
curl -I https://<nome-cmg>.cloudapp.net

Il primo comando non dice nulla sul problema, ma aiuta a correlare i timestamp dei log. Il secondo verifica che il nome pubblico del CMG si risolva nel modo atteso. Il terzo mostra se il servizio risponde con un codice HTTP sensato o se si ferma su handshake, timeout o errore TLS. Se curl -I non arriva a una risposta HTTP, il problema è prima dell’applicazione: rete, TLS o endpoint.

Se hai bisogno di verificare il certificato presentato dal servizio, puoi usare uno strumento esterno o il browser, ma la verifica amministrativa più utile resta la corrispondenza tra certificato configurato in console, thumbprint reale e stato del servizio cloud. Un mismatch di thumbprint è più comune di quanto si pensi dopo un rinnovo manuale o dopo la migrazione del servizio a un nuovo certificato.

Controlli finali e rollback

Quando il problema sembra risolto, non fermarti al solo “stato online” nella console. Devi vedere tre segnali: il CMG torna healthy, i log non mostrano più errori di accesso ad Azure e un client esterno riesce a ricevere policy o content attraverso il gateway. Se uno di questi tre manca, la correzione è incompleta.

Controlli finali consigliati:

  1. Verifica in console lo stato del CMG e del Cloud Management Gateway Connection Point.

  2. Controlla CloudMgr.log e CMGService.log per assenza di nuovi errori di autenticazione o provisioning.

  3. Da un client esterno, verifica che la location del CMG venga risolta e che la comunicazione HTTP/HTTPS non si fermi su timeout.

  4. Se hai fatto un change su certificato, app registration o proxy, conserva il diff della modifica e annota data e motivo nel ticket.

Rollback minimo: ripristina il certificato precedente o la configurazione precedente dell’app registration solo se hai conferma che era ancora valida e sicura. Se hai modificato proxy o firewall, reintroduci l’eccezione precedente o annulla la regola appena aggiunta. Se hai avviato un riavvio del servizio cloud e non ha risolto, non insistere con restart ripetuti: torna alla diagnosi del layer precedente, perché stai solo mascherando il sintomo.

Assunzione operativa: il CMG è in produzione e ogni cambio su tenant, certificato, proxy o subscription può avere impatto su client remoti; per questo ogni modifica va fatta con backup della configurazione, controllo dei log e un rollback pronto prima di applicarla.