1 01/05/2026 4 min

Quando ha senso rimuovere il Cloud Management Gateway

Rimuovere il Cloud Management Gateway da SCCM non è una pulizia cosmetica. Significa togliere un punto di ingresso cloud che alcuni client possono usare per registrarsi, scaricare policy e parlare con il management point quando non sono sulla rete interna. Prima di farlo, bisogna chiarire un punto semplice: se ci sono ancora device remoti che dipendono dal CMG, la rimozione rompe la loro capacità di gestione fino a quando non trovano un canale alternativo verso l’infrastruttura on-premises o verso un altro servizio equivalente.

La strada giusta dipende dal motivo della rimozione. Può essere un change pianificato perché si sta dismettendo il cloud path, una migrazione verso Microsoft Intune o una riorganizzazione dell’architettura. Può anche essere un troubleshooting, quando il CMG è stato creato per prova e non serve più. In ogni caso conviene lavorare in questo ordine: capire quali client lo usano, verificare se esistono servizi collegati, rimuovere la relazione dalla console SCCM, poi controllare che in Azure e nei client non restino riferimenti inutili.

Impatto operativo e blast radius

Il blast radius è limitato ai client che si affidano al CMG per comunicare con SCCM fuori rete. Non stai disinstallando SCCM né cancellando il sito, ma stai togliendo una via di comunicazione. Se il management point è raggiungibile solo via VPN o rete interna, l’effetto può essere nullo per gli utenti sempre connessi. Se invece hai laptop in mobilità, il risultato tipico è che quei device smettono di ricevere policy, application deployment e, in alcuni casi, anche l’inventory fino a quando non rientrano in una rete gestita.

Il rollback non è sempre “annulla”. Se il CMG viene rimosso e le risorse cloud vengono eliminate, ricrearlo richiede tempo: certificati, subscription, storage account, eventuale service connection point e propagazione lato client. Per questo la rimozione va trattata come change controllato: prima si misura chi lo usa, poi si disconnette, infine si elimina. Se il CMG è ancora critico, la mossa minima reversibile è disabilitarne l’uso temporaneamente solo per un sottoinsieme di client o in una finestra di manutenzione, non cancellarlo subito.

Verifiche preliminari prima di toccare la console

Prima di rimuovere il CMG, conviene raccogliere evidenza minima. Non serve fare archeologia: bastano pochi controlli per capire se ci sono dipendenze attive. Il primo punto è la console SCCM, dove si vede se il Cloud Management Gateway è configurato, quante istanze esistono e se il management point o il distribution point sono esposti tramite cloud service.

Il secondo punto è l’osservabilità lato client e lato server. Se hai log centralizzati, cerca riferimenti a CMG, cloud management, service name o endpoint Azure. Se non hai una piattaforma di log, i file classici da controllare sono quelli del client Configuration Manager e i log del ruolo sul server. Il nome esatto può variare in base alla versione, ma il pattern è sempre lo stesso: vuoi vedere se i client stanno ancora parlando con il gateway e con quale frequenza.

Terzo punto: verifica se esistono funzionalità che dipendono indirettamente dal CMG, come co-management, automatic enrollment, content access da remoto o policy pensate per device internet-only. Se non le hai mappate, la rimozione rischia di sembrare innocua fino al primo ticket aperto dagli utenti fuori sede.

Come capire se il CMG è ancora usato

Se vuoi una verifica rapida, parti dai log e dalla console. Sul client Configuration Manager il punto non è cercare “errore”, ma vedere se esiste una connessione effettiva al cloud path. In ambiente standard conviene controllare i log del client nella cartella locale dei log di SCCM e cercare stringhe legate al cloud gateway, al management point cloud e alla registrazione del dispositivo.

Un controllo pratico è questo:

findstr /i /c: