1 21/05/2026 8 min

Quando un client SCCM smette di registrarsi, non scarica le policy o resta bloccato in stato “Unknown”, il problema quasi mai è unico. Di solito si rompe uno dei passaggi della catena: comunicazione con il management point, integrità della cache, salute di WMI, servizi locali oppure stato dell’agent. La chiave è partire dal sintomo osservabile, correggere il punto più economico da ripristinare e verificare subito se il client torna a parlare con il sito.

Qui sotto trovi cinque metodi usati davvero in assistenza e in ambienti di produzione. Non sono ricette alternative buttate lì a caso: vanno letti come una sequenza di escalation. Prima si prova la correzione meno invasiva, poi si passa a quella che tocca più componenti. In ogni passaggio conviene tenere aperti i log del client, perché in SCCM la differenza tra “sembra sistemato” e “è sistemato” la fanno quasi sempre i log giusti.

1. Forzare un ciclo completo di policy e valutare il risultato nei log

Il primo metodo non ripara in senso stretto: serve a capire se il client è vivo e se il problema è solo di sincronizzazione. Se l’agente è installato ma non aggiorna policy o inventario, lanciare un recupero manuale evita di perdere tempo su ipotesi sbagliate.

Dal client apri il pannello Configuration Manager, scheda Actions, e avvia almeno queste azioni: Machine Policy Retrieval & Evaluation Cycle e Machine Policy Evaluation Cycle. Se vuoi farlo da shell, puoi usare PowerShell per richiamare l’SDK WMI locale, ma in ambienti misti il pannello riduce errori operativi.

Verifica nei log `PolicyAgent.log`, `PolicyEvaluator.log` e `ClientIDManagerStartup.log` se il client riceve una policy, se riesce a identificarsi e se il management point risponde. Un esito sano mostra richieste HTTP/HTTPS andate a buon fine, assegnazione del site code e download delle policy senza errori di autenticazione o timeout.

Comando utile per un controllo rapido della presenza del client e del site code:

wmic /namespace:\\root\ccm path SMS_Client get ClientVersion,AssignedSiteCode,CurrentManagementPoint

Se `AssignedSiteCode` è vuoto o `CurrentManagementPoint` non è valorizzato, il problema è più a monte della sola policy. In quel caso questo metodo serve solo come conferma iniziale, non come soluzione definitiva.

2. Pulire la cache CCM quando i download falliscono o restano corrotti

Se il client comunica ma non scarica contenuti, applicazioni o aggiornamenti, la cache locale è spesso il colpevole. Una cache corrotta produce errori intermittenti, retry continui e comportamenti che sembrano casuali. Non serve cancellare tutto alla cieca: basta verificare prima che il problema sia davvero lì.

Il punto da controllare è `C:\Windows\ccmcache`. Se la directory cresce in modo anomalo, contiene file incompleti o il client registra errori di download in `CAS.log`, `ContentTransferManager.log` o `DataTransferService.log`, ha senso intervenire. La correzione minima è svuotare la cache dal pannello del client oppure, se necessario, rimuovere solo i contenuti danneggiati e lasciare intatta la configurazione del client.

Da interfaccia: Configuration Manager → Cache → modifica dimensione o svuota i contenuti obsoleti se l’opzione è disponibile nella tua versione. Da shell, per un controllo diagnostico, puoi usare il tool di stato del client o leggere i log con PowerShell:

Get-Content C:\Windows\CCM\Logs\CAS.log -Tail 50
Get-Content C:\Windows\CCM\Logs\ContentTransferManager.log -Tail 50

Se dopo la pulizia i download ripartono, hai confermato un problema di integrità locale e non di sito. Se invece il client continua a fallire con errori di boundary, DP o autenticazione, il guasto è probabilmente nella catena verso il server e non nella cache.

3. Riparare WMI e il repository del client quando SCCM “vede” male il sistema

Molti client SCCM non sono davvero rotti: sono incapaci di interrogare correttamente il sistema locale. Se WMI è incoerente, l’agent legge male hardware inventory, stato compliance, servizi e identità macchina. Il risultato è un client apparentemente installato ma incapace di completare le query necessarie al sito.

Il sintomo classico è una combinazione di errori in `InventoryAgent.log`, `WMI`, `CcmExec.log` e messaggi di classe non trovata o provider non disponibile. In questi casi la riparazione va fatta con cautela: prima si verifica che il repository WMI sia effettivamente incoerente, poi si procede con un rebuild solo se la diagnosi regge.

Verifica di base:

winmgmt /verifyrepository
winmgmt /salvagerepository

Se il repository risulta inconsistente e il salvaggio non basta, il rebuild è la strada successiva. Su alcuni ambienti conviene prima esportare il contesto e controllare i log, perché un rebuild WMI può correggere il client SCCM ma lasciare intatti problemi di base del sistema operativo. Dopo l’operazione, testa il namespace SCCM:

wmic /namespace:\\root\ccm path SMS_Client get Name,ClientVersion

Se la query torna dati coerenti, il client almeno riesce a parlare con il proprio namespace locale. Se fallisce ancora, il problema è più profondo del repository e può coinvolgere componenti COM, permessi o lo stato stesso dell’agent.

4. Riavviare o riparare i servizi chiave dell’agent

Quando il servizio principale del client resta in stato anomalo, il ripristino dei servizi è spesso il metodo più rapido e meno rischioso dopo le verifiche di base. Il servizio da guardare è `CcmExec`, cioè il cuore operativo del client. Se è fermo, in avvio lento o in crash loop, il resto dell’agente non può funzionare correttamente.

Controlla lo stato con:

sc query CcmExec
Get-Service CcmExec

Se il servizio non parte, guarda `C:\Windows\CCM\Logs\CcmExec.log` e l’Event Viewer in Application e System. Un errore ricorrente sul caricamento di DLL, permessi o dipendenze indica che il servizio va riparato, non solo riavviato. In molti casi basta un restart controllato per sbloccare il client e far ripartire la registrazione.

Riavvio minimale:

Restart-Service CcmExec -Force

Se il servizio torna su ma il client continua a non registrarsi, verifica anche i servizi ausiliari legati al transfer dei contenuti e alla schedulazione delle attività. Non conviene toccarli tutti insieme senza osservare il comportamento dopo ogni singola modifica, perché altrimenti non capisci quale componente ha davvero risolto il problema.

5. Reinstallare il client SCCM in modo controllato quando il danno è strutturale

Se i metodi precedenti non cambiano il comportamento, la reinstallazione del client è spesso la soluzione più pulita. Va però trattata come un change controllato, non come un colpo di spugna. Prima di rimuovere, salva i log utili e annota site code, management point e stato del client, così puoi confrontare il prima e il dopo.

La rimozione può essere eseguita con lo script di setup del client, se disponibile nel pacchetto del sito, oppure con i meccanismi ufficiali del tuo ambiente. Il punto non è “disinstallare e sperare”, ma ricreare un’installazione pulita con parametri coerenti. In molti casi conviene usare un comando di reinstallazione che punti al management point corretto e al site code atteso.

ccmsetup.exe /mp:MP01.contoso.local SMSSITECODE=ABC

Dopo la reinstallazione, controlla `ccmsetup.log`, `ClientIDManagerStartup.log` e `LocationServices.log`. L’obiettivo non è solo vedere il processo finire senza errori, ma confermare che il client riceva un nuovo ID o rientri correttamente nel site, che trovi il management point e che completi il bootstrap senza fallback strani verso vecchi endpoint.

Se il client è gestito in massa, questo è il punto in cui il blast radius va tenuto sotto controllo: fai prima un host pilota, verifica l’impatto su policy e compliance, poi estendi il cambio. Reinstallare molti client insieme senza una verifica campione è il modo più rapido per trasformare un guasto locale in un problema operativo più ampio.

Come scegliere il metodo giusto senza perdere tempo

La sequenza pratica è questa: prima forzi le policy, poi pulisci la cache, poi controlli WMI, poi riparti dai servizi, infine reinstalli. Non è una lista teorica: segue la probabilità reale con cui i problemi SCCM si presentano in campo. Se il client comunica ma non scarica, la cache sale in cima. Se non inventaria o mostra errori di namespace, WMI diventa più plausibile. Se il servizio è down o instabile, il resto è inutile finché non si stabilizza.

Una regola che evita molta perdita di tempo è questa: ogni volta che fai una correzione, verifica subito un artefatto concreto. Può essere un log senza errori, un comando `wmic` che restituisce dati, uno stato servizio “Running” o un download che parte davvero. Se il client “sembra” a posto ma i log non lo confermano, il guasto non è chiuso.

Se invece vuoi prevenire il problema, cura tre aspetti: aggiornamento coerente del client, manutenzione della cache e salute del sottosistema WMI. In ambienti grandi, una baseline di controllo sui log più comuni (`CcmExec.log`, `LocationServices.log`, `CAS.log`, `PolicyAgent.log`) vale più di una reinstallazione fatta alla cieca. SCCM perdona poco i client lasciati marcire per mesi, ma è anche abbastanza trasparente da dirti dove si è rotto, se hai voglia di leggere i segnali giusti.