Errore SCCM UpdateTrustedSites: come risolvere il client

Quando UpdateTrustedSites fallisce, il problema non è quasi mai il “sito fidato” in sé

In SCCM/ConfigMgr l’errore UpdateTrustedSites sul client compare spesso quando la macchina non riesce ad aggiornare la lista dei siti attendibili prevista dalla policy del management point. Il sintomo può essere silenzioso oppure accompagnato da log ripetitivi, e di solito si manifesta insieme ad altri segnali: policy che non arrivano, componenti client che restano in stato “non valutato”, oppure browser e componenti WinINet che continuano a usare una trust zone incoerente con ciò che il sito si aspetta.

La cosa utile da chiarire subito è questa: UpdateTrustedSites è un effetto, non la causa. La causa vera sta quasi sempre in uno di questi tre punti: policy client non applicata, conflitto con GPO di dominio o stato locale del client corrotto/incompleto. Se parti dal messaggio e non dal layer che lo produce, rischi di cambiare impostazioni a caso senza risolvere nulla.

Quello che devi osservare prima di toccare la macchina

Prima di fare modifiche, verifica se il client sta davvero ricevendo policy dal sito e se il problema riguarda solo la trust zone o l’intera comunicazione con ConfigMgr. In pratica: stato atteso = il client scarica policy, aggiorna le impostazioni di sicurezza e registra l’operazione nei log; stato osservato = UpdateTrustedSites fallisce, oppure il client continua a mostrare vecchie policy e nei log trovi retry, access denied, o errori WMI/registry.

Il layer da controllare è quasi sempre questo: policy > WMI/CCM > registry/Internet Options > eventuale GPO. Se uno di questi strati è incoerente, il client può essere sano per il resto e fallire solo sull’aggiornamento dei siti attendibili.

Diagnosi probabile

Le ipotesi più probabili, in ordine, sono queste.

1. GPO o policy di dominio in conflitto: SCCM prova a scrivere la lista Trusted Sites, ma un criterio di gruppo la sovrascrive subito dopo o impedisce la modifica. La falsifichi in pochi minuti controllando il Resultant Set of Policy o i valori di registro che vengono ripristinati dopo un refresh.
2. Client ConfigMgr parzialmente rotto: WMI, ccmexec o i componenti di policy non sono allineati. Lo falsifichi verificando i log client e lo stato del servizio, poi confrontando con un client funzionante.
3. Problema di comunicazione con il management point o policy non aggiornata: il client non riceve il contenuto corretto e l’azione UpdateTrustedSites lavora su dati vecchi o incompleti. Lo falsifichi forzando un policy retrieval e controllando se il problema resta identico.

Se il client è in produzione, considera il blast radius come medio: toccare trust zone, Internet Options o GPO può impattare browser, download di contenuti e applicazioni che usano zone di sicurezza. Il rollback deve essere sempre un ritorno al backup del registro o alla GPO precedente, non un “proviamo a vedere”.

Verifiche immediate

Lavora dai log, poi dal registro, poi dalla policy. Su client Windows con ConfigMgr i file più utili sono in C:\Windows\CCM\Logs\, in particolare PolicyAgent.log, PolicyEvaluator.log, ClientLocation.log, CCMExec.log e, se presente, il log specifico del componente che richiama UpdateTrustedSites.

1. Controlla se il servizio client è vivo e se il motore policy risponde:

   sc query ccmexec
   

   Atteso: stato RUNNING. KO: servizio fermo, restart loop o errori di avvio.
2. Apri i log recenti e cerca la stringa associata all’errore:

   findstr /i "UpdateTrustedSites TrustedSites policy error" C:\Windows\CCM\Logs\*.log
   

   Atteso: trovi la sequenza che mostra quale componente fallisce. Se non trovi nulla, il problema potrebbe essere altrove o il client non sta nemmeno eseguendo la policy.
3. Verifica se le zone di sicurezza sono già state alterate da GPO locali o di dominio. Il punto classico è il registro sotto HKCU o HKLM, a seconda della configurazione usata dal sito. Cerca valori relativi a siti e zone in Internet Settings e confronta con la baseline attesa.
4. Forza un aggiornamento policy dal client e osserva se cambia il comportamento:

   "C:\Windows\CCM\ccmexec.exe" /triggeraction
   

   Se il tuo ambiente usa trigger specifici, usa l’azione prevista dalla tua versione di ConfigMgr; l’obiettivo è verificare se il problema è di ricezione policy o di applicazione locale.
5. Se sospetti GPO, esegui un controllo rapido del risultato effettivo:

   gpresult /h C:\Temp\gp.html
   

   Poi apri il report e verifica se esiste una policy che gestisce Internet Explorer/Trusted Sites/zone di sicurezza. Se sì, SCCM potrebbe essere in conflitto strutturale con il dominio.

Se trovi messaggi tipo access denied, impossibilità di scrivere il registro o errore di parsing della policy, non cambiare subito parametri di SCCM: prima devi capire se il client è bloccato da una policy esterna o da un suo stato interno incoerente.

Soluzione consigliata passo-passo

La sequenza sotto è pensata per ridurre il rischio: prima osservazione, poi correzione minima reversibile, poi escalation solo se il problema resta.

1. Metti in sicurezza lo stato locale. Prima di toccare il registro esporta la chiave interessata, così hai un rollback immediato.

   reg export "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap" C:\Temp\zonemap-backup.reg /y
   

   Se il sito usa HKLM invece di HKCU, esporta anche quella chiave. Blast radius: limitato alla sessione utente o alla macchina, ma può cambiare il comportamento del browser e di applicazioni WinINet. Rollback: re-import del file .reg esportato.
2. Verifica e rimuovi il conflitto GPO. Se gpresult mostra una policy che gestisce Trusted Sites, quella è la priorità. Non forzare SCCM a combattere il dominio. Correggi la GPO oppure escludi l’OU/il gruppo correttamente.

   gpupdate /force
   

   Poi controlla se la chiave di registro ritorna al valore atteso o se viene sovrascritta. Se viene sovrascritta, hai trovato la causa.
3. Ripulisci il client solo se i log indicano corruzione locale. Se CCMExec.log o PolicyAgent.log mostrano componenti incoerenti, riavvia prima il servizio:

   net stop ccmexec
   net start ccmexec
   

   Se non basta, valuta la correzione del client ConfigMgr con reinstallazione o repair secondo la procedura standard del tuo ambiente. Non partire da un repair se hai già evidenza di GPO in conflitto: sarebbe rumore operativo.
4. Forza il refresh della policy. Dopo aver corretto il conflitto o ripristinato il client, fai un nuovo ciclo di policy e controlla i log. L’obiettivo è vedere la riga che indica l’applicazione corretta dell’azione e l’assenza di retry sull’update dei siti fidati.
5. Se il problema è limitato a un gruppo di client, confronta un endpoint sano e uno guasto. Le differenze utili sono tre: membership di OU, GPO applicate, e versione del client ConfigMgr. Questo ti dice subito se stai inseguendo un problema individuale o una regressione di configurazione.

Se devi intervenire su molte macchine, evita la modifica manuale una per una. Meglio correggere la policy a monte o distribuire un fix controllato con test su un gruppo pilota. In questo scenario il rollback è semplice: rimuovi la GPO o ripristina il backup del set di criteri, poi verifica che il client torni al comportamento precedente.

Come leggere i log senza perdere tempo

Nei log ConfigMgr non cercare solo la parola “error”. Molto spesso il punto utile è prima: un warning che mostra il fallimento della lettura della policy, oppure una sequenza di retry che indica il vero oggetto fallito. Se hai accesso a CMTrace, apri i file in C:\Windows\CCM\Logs\ e cerca il timestamp dell’ultima esecuzione dell’azione.

Segnali da considerare significativi:

• errori di scrittura su registry o access denied;
• policy scaricata ma non applicata;
• client che riceve la policy giusta ma la sovrascrittura GPO avviene dopo pochi secondi;
• componenti WMI o CCM che non rispondono come previsto.

Se il log è vuoto o non cambia dopo il trigger, il problema è più a monte: servizio fermo, client danneggiato o canale di policy interrotto. In quel caso non perdere tempo a ritoccare le zone fidate.

Un caso tipico: SCCM scrive, la GPO cancella

È uno dei casi più frequenti. Il client aggiorna correttamente la trust zone, tu vedi la modifica nel registro, ma al successivo refresh di gruppo la macchina torna al valore precedente. Da fuori sembra che SCCM “non funzioni”; in realtà funziona, ma un criterio di dominio ha priorità o temporizzazione diversa.

La verifica pratica è semplice: esegui gpupdate /force, poi leggi di nuovo la chiave interessata. Se il valore cambia subito dopo, non è un bug del client ConfigMgr. La soluzione strutturale è allineare ownership della impostazione: o la gestisce SCCM, o la gestisce la GPO, ma non entrambe.

Quando conviene riparare il client invece di inseguire il singolo errore

Se il problema compare su una sola macchina e i log mostrano anche altri sintomi anomali — policy assenti, inventario bloccato, componenti non registrati — il repair del client è spesso più efficiente della caccia al dettaglio. Ma va fatto solo dopo aver escluso il conflitto di policy esterno. Altrimenti ripari un client che verrà subito riportato nello stesso stato dalla GPO.

Su ambienti grandi, un approccio sensato è: primo test su endpoint campione, verifica dei log, poi correzione della configurazione centrale. Non fare cambi diffusi senza un gruppo pilota e senza un punto di rollback chiaro.

Controlli finali / rollback

1. Riapri i log e verifica che l’azione UpdateTrustedSites non generi più retry o errori. Atteso: una sola esecuzione corretta, senza ripetizioni anomale.
2. Controlla la chiave di registro dopo il refresh policy e dopo un refresh GPO. Atteso: il valore resta coerente con la configurazione desiderata.
3. Verifica che il servizio ccmexec sia stabile e che il client continui a ricevere policy successive. Atteso: nessun crash, nessun reset della configurazione.
4. Se hai esportato il registro, conserva il file di backup finché il comportamento non è stabile per almeno un ciclo completo di policy. Rollback: reg import C:\Temp\zonemap-backup.reg solo se la correzione introduce regressioni.
5. Se hai modificato una GPO, documenta la revisione e il punto esatto in cui il dominio deve essere l’unica fonte di verità per Trusted Sites.

Assunzione operativa: il client Windows è gestito da ConfigMgr in ambiente di dominio, e il problema riguarda la funzione di aggiornamento delle siti attendibili, non un guasto generale del sistema o del management point.