1 12/10/2026 9 min

Quando CMG fallisce sul nome remoto non risolto

In ConfigMgr, l’errore di nome remoto non risolto sul Cloud Management Gateway quasi mai è un problema “di CMG” in senso stretto. Di solito il punto debole sta prima: risoluzione DNS, certificato sbagliato, proxy che riscrive la destinazione, oppure un endpoint Azure raggiungibile solo a metà. La lettura corretta è questa: il client prova a contattare un nome FQDN, non ottiene una risposta valida, e interrompe la catena prima ancora di stabilire una sessione utile.

Il dettaglio importante è non confondere un errore di risoluzione con un errore di autenticazione o con un timeout applicativo. Se il nome non si risolve, il problema è quasi sempre nel layer DNS o nella configurazione del nome esposto dal CMG. Se invece il nome si risolve ma la connessione fallisce, allora il blocco si sposta su certificati, firewall, proxy o TLS.

Prima distinzione utile: dove si rompe il flusso

Per non perdere tempo, separa subito i casi in tre gruppi.

  • DNS: il client non risolve il FQDN del CMG o risolve un indirizzo inatteso.
  • Rete/TLS: il nome si risolve, ma la connessione HTTPS non si completa.
  • Configurazione CMG: il nome pubblicato nel servizio non coincide con quello usato dai client o con il certificato presentato.

Se hai un ambiente con proxy esplicito, split DNS o DNS filtrato, il problema può essere locale a una sede o a un sottoinsieme di client. Questo è il primo indizio da cercare, perché evita di trattare come incidente globale un guasto che in realtà è circoscritto a una subnet o a un resolver specifico.

Verifica il nome esatto pubblicato dal CMG

Il primo controllo non è sul client, ma sulla console ConfigMgr. Devi verificare il FQDN effettivo del Cloud Management Gateway e confrontarlo con quello che il client sta tentando di raggiungere. Se il nome è stato cambiato, se è stato rigenerato il servizio, o se è stato inserito un suffisso errato, il client continuerà a cercare un nome che non esiste più o che non corrisponde al certificato.

Controlla anche il certificato associato al CMG: il subject o, meglio, il SAN deve coprire il nome usato dal servizio. Un certificato valido ma emesso per un nome diverso può generare sintomi che sembrano DNS, ma in realtà nascono da un mismatch di identità TLS.

Artefatti da verificare

  • Console Administration > Cloud Services > Cloud Management Gateway: FQDN configurato.
  • Certificato usato dal CMG: campo Subject Alternative Name con il nome corretto.
  • Eventuali note operative o change recenti: rinomina del servizio, rinnovo certificato, modifica del DNS.

Test minimo dal client: risoluzione e connessione

Dal client interessato, fai due test separati. Il primo serve a capire se il nome si risolve. Il secondo serve a capire se la porta HTTPS risponde davvero.

nslookup nome-cmg.contoso.com

Atteso: il comando restituisce un record A o CNAME coerente con il servizio. Se il resolver risponde con Non-existent domain, o con un IP interno che non dovrebbe comparire, la pista DNS è la più probabile.

curl -vkI https://nome-cmg.contoso.com/

Atteso: handshake TLS completato e risposta HTTP, anche se magari non è una pagina utile per l’utente finale. Se il nome si risolve ma la connessione si interrompe durante il TLS, il problema è più in basso del DNS.

Se il client è Windows e vuoi un’indicazione più diretta sul resolver locale, puoi usare anche:

Resolve-DnsName nome-cmg.contoso.com

Se il nome risolve solo su un client e non su un altro nella stessa rete, il problema è nel resolver configurato, nella cache DNS locale, oppure in una policy di rete che altera la consultazione verso i DNS pubblici o interni.

Cause più probabili, in ordine pratico

Nel campo, le cause ricorrenti sono abbastanza stabili. Le prime tre che controllerei sono queste.

  1. FQDN CMG non allineato al DNS pubblico: il record non esiste, è stato rimosso, o punta a un valore errato.
  2. Certificato non coerente con il nome: il client vede un endpoint che non corrisponde al subject/SAN e la negoziazione fallisce prima di arrivare ai servizi ConfigMgr.
  3. Proxy o ispezione TLS: il traffico verso Azure viene intercettato, riscritto o bloccato, con effetti che il client interpreta come impossibilità di raggiungere il nome remoto.

In ambienti ibridi, aggiungo un quarto controllo: il DNS interno può risolvere il FQDN del CMG verso un indirizzo diverso rispetto a quello pubblico, per effetto di split-brain DNS o di zone locali create per errore. È una configurazione che in laboratorio sembra innocua, ma in produzione crea sintomi intermittenti e difficili da leggere.

Come falsificare ogni ipotesi in pochi minuti

Qui conviene essere brutali: un test breve, un esito chiaro, niente interpretazioni creative.

  • DNS errato: confronta l’output di nslookup su un client interno con quello di un resolver esterno affidabile. Se i risultati divergono sullo stesso FQDN, il problema è nel naming.
  • Certificato incoerente: apri il certificato del CMG e verifica che il nome usato dal client compaia nel SAN. Se manca, il fix non è sul client ma sul certificato o sul nome pubblicato.
  • Proxy/TLS: prova la stessa URL da una macchina che bypassa il proxy o da una rete di test. Se il problema sparisce, il colpevole è nel percorso di uscita, non nel CMG.

Se hai accesso ai log del client, cerca le occorrenze del nome del CMG e le eccezioni correlate alla risoluzione. I log utili dipendono dalla versione e dal flusso coinvolto, ma in generale i file di log del client ConfigMgr e il log di gestione del servizio mostrano abbastanza per capire se il blocco è precedente o successivo alla risoluzione del nome.

Correzione minima reversibile prima di toccare altro

La regola è semplice: prima correggi il nome o il DNS, poi verifichi, solo dopo tocchi il resto. Evita di cambiare insieme FQDN, certificato, proxy e regole firewall: se risolvi il problema non saprai mai quale modifica lo abbia causato.

  1. Se il DNS è sbagliato, correggi il record del nome del CMG nel namespace corretto e attendi la propagazione. Se usi un record CNAME, verifica che punti al nome cloud effettivo e non a un alias vecchio.
  2. Se il certificato non copre il nome, prepara un nuovo certificato con SAN coerente, installalo sul CMG secondo la procedura ufficiale e mantieni il vecchio disponibile fino alla validazione del nuovo.
  3. Se il proxy altera il traffico, crea una eccezione mirata per il FQDN del CMG e per gli endpoint Azure richiesti dal tuo scenario, senza aprire bypass indiscriminati verso l’intero cloud.

Ogni modifica deve avere un rollback chiaro. Per il DNS, il rollback è il ripristino del record precedente. Per il certificato, è la possibilità di tornare al certificato precedente se non è stato revocato o scaduto. Per il proxy, è la rimozione selettiva dell’eccezione appena creata.

Se il problema è nel DNS: cosa controllare davvero

Il DNS non va controllato solo con un lookup “sì/no”. Devi verificare tre cose: il resolver interrogato, il record restituito e la coerenza con il percorso di rete.

  • Il client usa il DNS previsto o un resolver imposto da VPN, DHCP o policy?
  • Il record restituito è un A, un CNAME o un valore vecchio in cache?
  • Il nome punta a un endpoint pubblico coerente con il modello CMG o a un indirizzo interno che non dovrebbe essere usato?

Se hai recentemente migrato il CMG o cambiato il prefisso cloud, considera il tempo di propagazione e la cache locale. Su Windows una cache DNS sbagliata può tenere in vita un risultato vecchio più a lungo del previsto. In questi casi un flush è un test utile, ma non è la soluzione strutturale: serve solo a capire se la cache sta mascherando il problema.

ipconfig /flushdns

Se dopo il flush il nome torna a risolversi, il problema era probabilmente una combinazione di cache e record aggiornato di recente. Se invece il nome continua a fallire, la causa è a monte.

Se il problema è il certificato: non fermarti al “è valido”

Un certificato può essere formalmente valido e comunque sbagliato per il tuo CMG. Il punto è il nome. Il client non ragiona sul fatto che la CA sia attendibile; ragiona sul fatto che l’identità presentata corrisponda al nome atteso. Se manca il SAN corretto, o se il certificato è stato emesso per un FQDN diverso, il risultato pratico è un endpoint non affidabile.

Controlla anche la catena completa. In alcuni ambienti la root è presente, ma manca l’intermedia sul client o sul server di pubblicazione. Il sintomo può sembrare “nome non risolto”, ma in realtà la connessione TLS si interrompe al momento della validazione della catena.

Se il problema è il proxy o la sicurezza perimetrale

Il proxy è un sospetto serio quando il problema colpisce solo i client remoti o solo quelli fuori sede. Alcuni proxy ispezionano HTTPS, altri bloccano in base a categorie, altri ancora riscrivono i certificati in modo trasparente. Per un servizio come CMG, questo può essere sufficiente a rompere la fiducia del client.

La correzione corretta non è “aprire tutto”. È creare una regola mirata per il traffico necessario al CMG, documentare il motivo e verificare che il comportamento torni stabile. Se l’eccezione è troppo ampia, introduci un rischio inutile e perdi la possibilità di audit.

Validazione finale dopo la correzione

Dopo la modifica, non limitarti a un test singolo. Verifica almeno questi tre punti: il nome si risolve, la connessione HTTPS si completa, il client ConfigMgr torna a comunicare con il CMG senza errori di nome remoto.

  • DNS: nslookup nome-cmg.contoso.com restituisce il record atteso.
  • TLS: curl -vkI https://nome-cmg.contoso.com/ arriva a handshake e risposta.
  • ConfigMgr: i log del client non riportano più l’errore di nome remoto non risolto e la connessione al CMG riparte.

Se l’ambiente è grande, controlla almeno un client per ciascuna rete o sede interessata. Un fix che funziona solo da una subnet non è un fix: è un indizio che il problema è ancora presente altrove.

Come evitare che il problema torni

La prevenzione vera sta nella disciplina del naming. Quando il CMG viene creato o modificato, il nome pubblico, il certificato, il DNS e la documentazione operativa devono essere aggiornati insieme. Se uno di questi elementi resta indietro, il guasto si ripresenta al primo rinnovo o al primo cambio di infrastruttura.

Conviene anche tenere una check-list di change minima: FQDN esatto, record DNS, SAN del certificato, proxy exemption, e un test di validazione da un client esterno. È una pagina di lavoro semplice, ma abbatte i casi in cui si fa troubleshooting “a memoria” su un servizio che dipende da più layer.

In sintesi, il messaggio operativo è questo: l’errore di nome remoto non risolto sul CMG non si risolve a intuito. Si isola il layer, si verifica il nome effettivo, si confronta il certificato, si controlla il percorso di rete, e solo dopo si corregge. È il modo più rapido per uscire dal falso problema e arrivare alla causa reale senza introdurre effetti collaterali.