1 17/10/2026 9 min

CMG di ConfigMgr bloccato in avvio: dove guardare per primo

Quando il Cloud Management Gateway di Configuration Manager resta fermo in avvio, il punto non è “riavviarlo e sperare”. Il problema va letto per layer: Azure, certificati, storage, SQL, service connection point, poi il ruolo CMG vero e proprio. Se salti questo ordine, rischi di cambiare tre cose insieme e non capire quale abbia rotto cosa.

Il comportamento tipico è semplice da riconoscere: in console il CMG rimane in stato Provisioning, Starting o Stopped, i client non lo usano come previsto, e nei log compaiono errori ripetuti sulla validazione del certificato, sulla creazione dell’istanza cloud o sulla comunicazione con Azure. In pratica l’architettura è viva solo a metà.

Qui l’obiettivo non è fare teoria su ConfigMgr, ma arrivare in fretta a capire se il blocco nasce da un problema di identità, di connettività o di dipendenza interna. La sequenza corretta evita falsi positivi e ti dà un rollback chiaro se devi toccare la configurazione.

Classificazione operativa e stato atteso vs osservato

Classifica: troubleshooting con possibile impatto produzione. Se il CMG serve client remoti o distribuzione di policy/app, considera l’effetto come incidente di servizio fino a prova contraria.

Stato atteso: il CMG entra in servizio, la console mostra uno stato coerente con il provisioning completato e i log confermano handshake, validazione certificati e raggiungibilità dell’endpoint Azure. Stato osservato: il ruolo non completa l’avvio, resta in transizione o fallisce in modo ricorrente, spesso con messaggi che puntano a certificati, storage account, subscription o servizi locali della console.

Ipotesi ordinate per probabilità

Le tre ipotesi che vedo più spesso, in ordine pratico, sono queste.

  1. Certificato o binding non valido. Il CMG non riesce a usare il certificato corretto per l’autenticazione o la catena non è più coerente. Falsificazione in meno di 5 minuti: verifica la scadenza, il subject, l’uso della chiave privata e la presenza della catena completa nel certificato assegnato al CMG.
  2. Problema lato Azure o identità dell’istanza. La risorsa cloud esiste ma non risponde come atteso, oppure le credenziali/permessi dell’app registrata non consentono l’operazione richiesta. Falsificazione rapida: controlla lo stato della risorsa nel portale Azure e incrocia l’errore con i log di ConfigMgr per vedere se il fallimento avviene prima o dopo la chiamata al cloud.
  3. Dipendenza locale rotta. Il servizio ConfigMgr o il componente che orchestra il CMG non riesce a completare l’avvio per blocco di SQL, storage o coda interna. Falsificazione rapida: controlla eventi del server, spazio disco, stato dei servizi ConfigMgr e latenza SQL; se uno di questi è degradato, il CMG spesso è solo il sintomo.

Se hai solo pochi minuti, la regola è questa: prima prova a dimostrare che il problema è nel CMG, poi che è fuori dal CMG. Non fare il contrario.

Verifiche immediate che danno evidenza vera

Prima di cambiare configurazioni, raccogli evidenza minima. Questi controlli non sono invasivi e ti dicono subito dove si rompe la catena.

  1. Controlla lo stato in console. In Administration > Cloud Services > Cloud Management Gateway, verifica se il ruolo è in Starting, Provisioning, Failed o Stopped. Se la console mostra un errore testuale, copialo pari pari: spesso è la traccia più utile.
  2. Leggi i log giusti. Su site server e componenti correlati, cerca in particolare `CloudMgr.log`, `CMGateway.log`, `SMS_CLOUD_PROXYCONNECTOR.log` e i log del servizio SMS Executive. Se l’errore è di certificato o provisioning, di solito emerge lì prima che in console.
  3. Verifica il certificato assegnato al CMG. Deve essere valido, con chiave privata presente e con nome coerente rispetto al servizio. Se il certificato è scaduto o sostituito senza aggiornare il riferimento nel CMG, l’avvio fallisce o resta sospeso.
  4. Controlla la risorsa Azure. Nel portale verifica che la VM/istanza, il servizio associato, lo storage e l’eventuale load balancer o public IP siano in stato sano. Se la risorsa è stata spostata, rinominata o ricreata fuori dal flusso previsto, ConfigMgr può continuare a puntare a un riferimento vecchio.
  5. Conferma la connettività verso Azure. Dal site server, un test di raggiungibilità verso gli endpoint richiesti da ConfigMgr deve passare senza proxy o filtri anomali. Se c’è un firewall in mezzo, il CMG può sembrare “bloccato” quando in realtà non riesce solo a completare i handshake.
  6. Controlla spazio disco e stato dei servizi. Se il volume che ospita log e working directory è quasi pieno, o se il servizio SMS Executive è degradato, il CMG può non completare l’avvio anche senza errori espliciti in console.

Se hai bisogno di una verifica rapida da shell sul server del site, usa almeno i servizi e lo spazio disco come primo filtro.

Get-Service SMS_EXECUTIVE, CcmExec | Select-Object Name, Status, StartType
Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, Free

Atteso: i servizi critici risultano in esecuzione e il volume di sistema o quello dei log non è vicino alla saturazione. Se uno dei due punti fallisce, il problema non è “solo” il CMG.

Soluzione consigliata passo-passo

Qui conviene procedere con azioni minime e reversibili. Ogni passaggio sotto ha un obiettivo preciso e una verifica immediata.

  1. Metti in sicurezza lo stato attuale. Prima di toccare il CMG, esporta la configurazione rilevante o annota i parametri correnti: nome della risorsa, subscription, region, certificato assegnato, storage account, eventuale numero di istanze. Questo è il tuo rollback minimo se devi ripristinare il profilo precedente.
  2. Correggi prima i certificati. Se il certificato è scaduto, non ha la chiave privata o non corrisponde al nome usato dal CMG, sostituiscilo con uno valido prima di fare altro. Dopo l’aggiornamento, verifica che il nuovo certificato sia selezionabile e correttamente associato al ruolo. Se il problema era qui, il CMG spesso riparte senza ulteriori interventi.
  3. Verifica e, se necessario, riallinea l’identità Azure. Se il log mostra errori di autorizzazione o di accesso alla subscription, controlla l’app registrata, i permessi e la scadenza del segreto o del certificato di autenticazione. Non cambiare più variabili insieme: correggi una sola credenziale e poi rilancia il controllo dello stato.
  4. Controlla la risorsa cloud dal portale. Se la risorsa è corrotta o in uno stato incoerente, spesso conviene fermare l’operazione dal lato ConfigMgr, verificare la risorsa in Azure e poi rieseguire il provisioning. Se la VM o il servizio cloud è presente ma non risponde, non forzare un riavvio cieco: prima identifica se il problema è di networking, di storage o di provisioning bloccato.
  5. Pulisci solo il necessario. Se i log indicano residui di un provisioning fallito, elimina solo gli artefatti temporanei chiaramente legati alla build fallita, non l’intera configurazione. Questo riduce il blast radius. Se non hai certezza di quale artefatto sia orfano, fermati e documenta prima la situazione.
  6. Riavvia il flusso di avvio del CMG. Dopo la correzione singola, riavvia il processo o il servizio interessato e attendi la nuova telemetria nei log. Non fare restart multipli in sequenza: un riavvio alla volta ti fa capire se l’azione ha avuto effetto.
  7. Rivedi SQL e dipendenze locali se il blocco persiste. Se i log non mostrano errori di certificato o Azure ma il ruolo continua a non partire, passa a SQL, code interne e servizi del site. Un rallentamento del database o un problema di permessi sul site server può impedire al CMG di completare la registrazione anche se la parte cloud è corretta.

Un esempio pratico: se `CloudMgr.log` mostra un errore di validazione del certificato e in console il CMG resta su Starting, la prima correzione da fare è il certificato, non la subscription. Se invece il certificato è sano ma il log segnala autorizzazione negata verso Azure, il focus si sposta sull’app registrata o sui permessi della subscription.

Altro caso frequente: il CMG sembra bloccato, ma il vero guasto è un disco quasi pieno sul site server. In quel caso il ruolo resta fermo perché non riesce a scrivere log o file temporanei. Liberare spazio su disco è un fix reversibile e spesso immediato, molto più sicuro di un reset del provisioning.

Controlli finali e rollback

Dopo la correzione, la verifica non si limita a vedere il verde in console. Devi confermare che il CMG stia davvero servendo traffico e che i log abbiano smesso di ripetere lo stesso errore.

  1. Controlla lo stato in console dopo il refresh. Atteso: il CMG passa a uno stato operativo coerente con il provisioning completato e non torna indietro dopo pochi minuti.
  2. Leggi di nuovo i log. Atteso: non compaiono più errori ripetuti relativi a certificato, autorizzazione o creazione della risorsa cloud. Se l’errore si ripresenta identico, la correzione non ha colpito la causa.
  3. Verifica il comportamento dei client. Atteso: i client remoti riescono a raggiungere il CMG e non mostrano timeout o fallback anomali verso altri punti di gestione.
  4. Conferma lo stato della risorsa Azure. Atteso: la risorsa è stabile, senza ri-creazioni continue, errori di provisioning o costi anomali dovuti a retry infiniti.
  5. Rollback se la modifica peggiora la situazione. Se dopo il cambio certificato o la correzione dell’identità il CMG peggiora, ripristina il certificato precedente se ancora valido, oppure riporta la configurazione al backup annotato prima della modifica. Se hai pulito artefatti cloud, evita ulteriori cancellazioni finché non hai un nuovo snapshot della situazione.

Assunzione: hai accesso al site server, alla console ConfigMgr e al portale Azure con privilegi sufficienti per leggere stato, log e configurazione del CMG senza dover fare rotazioni di segreti in emergenza.

Quando il problema non è il CMG ma il contesto

Ci sono due trappole classiche. La prima è confondere un errore di rete o DNS con un guasto del CMG: se il client non risolve correttamente l’endpoint, il CMG risulta “rotto” anche quando è sano. La seconda è ignorare il layer di sicurezza: un certificato valido ma non più attendibile dalla catena di trust del client produce sintomi simili a un provisioning bloccato.

Per questo, quando fai troubleshooting serio, tieni sempre separati tre livelli: configurazione ConfigMgr, stato Azure e raggiungibilità dal client. Se uno dei tre non torna, il CMG può essere solo il punto in cui il fallimento diventa visibile.

La regola pratica è semplice: prima osserva, poi correggi, infine conferma. Nel CMG bloccato in avvio, la tentazione di “rifare tutto” è forte, ma quasi sempre inutile. Un fix mirato, una sola variabile alla volta e un rollback pronto valgono più di un reset aggressivo fatto alla cieca.