Correggere gli errori dei contatori prestazioni in SCCM Console

Correggere i contatori prestazioni in SCCM Console senza tirare a indovinare

Quando i contatori prestazioni in SCCM Console mostrano valori vuoti, incoerenti o errori di caricamento, il problema raramente sta nella console in sé. Di solito il guasto è in uno di questi punti: connettività verso il server, repository WMI, stato del provider SMS, permessi dell’account, oppure corruzione locale del profilo console. La chiave è capire quale layer ha smesso di rispondere prima di toccare configurazioni o reinstallare componenti a caso.

Il sintomo tipico è semplice: apri una vista o un nodo che dipende dai contatori, la Console resta lenta, restituisce errori generici o mostra dati manifestamente sbagliati. L’atteso è che la console interroghi il sito e riceva metriche aggiornate; l’osservato è un risultato parziale, nullo o bloccato. In pratica, stai guardando un problema di telemetria e accesso ai dati, non per forza un problema di raccolta dati nel client.

Layer da verificare prima di cambiare qualcosa

La diagnosi utile parte dal percorso: Console → rete → provider SMS/WMI → sito SCCM → SQL o dati di stato. Se salti un livello, rischi di correggere il sintomo e non la causa. In particolare, i contatori prestazioni possono rompersi per motivi diversi ma con lo stesso effetto visivo: un provider non raggiungibile, un repository WMI corrotto, un servizio fermo o un certificato/permesso che blocca la query.

Un errore molto comune è confondere un problema locale della macchina amministrativa con un problema del sito. Se la console è installata su un endpoint con profilo utente corrotto o con cache danneggiata, i contatori possono fallire solo lì. Se invece il difetto è lato server, di solito lo vedono tutte le console che interrogano lo stesso sito.

Diagnosi rapida: capire se è locale o lato server

Prima di intervenire, fai tre verifiche minime. Sono reversibili e ti dicono subito dove scavare dopo.

1. Apri la console da un secondo account amministrativo o da una seconda postazione. Se i contatori funzionano lì, il problema è locale alla workstation o al profilo.
2. Verifica la raggiungibilità del server del sito e del provider SMS con un test di base. Se la rete non risponde, la console non può completare le query.
3. Controlla i log della console e del provider per errori WMI, RPC o accesso negato. Se compaiono eccezioni ripetute, hai già il punto d’ingresso del guasto.

Un controllo rapido da shell sulla macchina amministrativa è questo:

ping -n 4 nome-sito-o-ip-del-provider
Test-NetConnection nome-sito-o-ip-del-provider -Port 135
Test-NetConnection nome-sito-o-ip-del-provider -Port 443

Il primo test ti dice se c’è almeno connettività di base. Il secondo serve a intercettare problemi RPC/WMI. Il terzo è utile se il tuo ambiente usa interfacce HTTPS o componenti esposti su 443. Se uno di questi fallisce, non ha senso partire dalla console: devi sistemare il trasporto prima della UI.

Controllo WMI e repository locale della console

Se i problemi si presentano solo sulla macchina con la SCCM Console, il colpevole più probabile è il layer locale. La console usa componenti WMI, librerie .NET e cache applicative. Un repository WMI degradato può produrre errori intermittenti, viste vuote o contatori che si fermano senza un messaggio chiaro.

Per verificare WMI sul client amministrativo, esegui una query semplice. Non serve niente di sofisticato: devi solo vedere se il motore risponde.

wmic /namespace:\root
sop path __namespace get name
Get-CimInstance -Namespace root\cimv2 -ClassName Win32_OperatingSystem | Select-Object Caption, Version

Se queste query falliscono, il problema non è SCCM ma la piattaforma WMI della macchina. In quel caso, prima di pensare a reinstallare la console, conviene verificare lo stato del servizio WMI e la salute del repository.

sc query winmgmt
winmgmt /verifyrepository

Se il repository risulta incoerente, la correzione va fatta con cautela perché impatta anche altri strumenti di amministrazione. Il rischio è medio: toccando WMI puoi rompere temporaneamente più console di gestione. Prima di qualsiasi riparazione, fai un backup dello stato macchina o un checkpoint se sei su virtual machine. Il rollback, in un caso simile, è il ripristino del disco o della snapshot, non un “undo” magico dentro SCCM.

Provider SMS e permessi: quando la console vede il sito ma non i dati

Se la connettività è ok e la console funziona su altre postazioni, il passo successivo è il provider SMS. È il punto in cui la console traduce le richieste in operazioni lato sito. Un provider fermo, saturato o con permessi errati può far sparire i contatori prestazioni senza compromettere tutto il resto della console.

Verifica innanzitutto che il servizio e il nodo provider siano in salute. Sul server del sito, controlla i servizi SCCM correlati e cerca errori nel log del provider. I percorsi possono variare con la versione, ma i log utili sono in genere sotto `C:\Program Files\Microsoft Configuration Manager\Logs\`.

Get-Service *SMS* | Sort-Object Status, Name
Get-Service Winmgmt
Get-ChildItem 'C:\Program Files\Microsoft Configuration Manager\Logs\' | Select-Object Name, LastWriteTime

Nel log del provider cerca segnali come access denied, query WMI fallite, timeout o impossibilità di aprire oggetti del sito. Se la console usa un account che non ha i diritti corretti sul sito o sul provider, può vedere solo parte dei dati e fallire proprio quando prova a leggere i contatori.

Un controllo ragionevole è la membership nei ruoli amministrativi di Configuration Manager e le autorizzazioni DCOM/WMI sul server provider. Non allargare i privilegi “per prova” più del necessario: se il problema sparisce con un account più potente, hai già isolato il gap di permessi. A quel punto correggi il ruolo, non lasciarti il workaround in produzione.

Corruzione della cache locale della console

Quando i contatori falliscono solo su una macchina e i test di rete e WMI sono sani, la cache locale è il sospetto più forte. La console memorizza dati temporanei, layout e riferimenti che possono degradarsi dopo update, crash o chiusure anomale. In questi casi la soluzione più pulita è rimuovere solo la cache utente o ricreare il profilo applicativo, non reinstallare tutto il management stack.

Prima di cancellare nulla, chiudi la console e salva eventuali personalizzazioni importanti. Il blast radius è basso, ma il rollback non è nullo: perdi file temporanei e cache, e in alcuni casi anche preferenze locali della UI.

1. Chiudi la SCCM Console.
2. Rinomina la directory cache dell’utente, invece di eliminarla subito. In questo modo hai un rollback immediato.
3. Riapri la console e verifica se i contatori tornano visibili.

Le cartelle esatte possono cambiare per versione e installazione, ma spesso il punto da controllare è sotto il profilo utente, nell’area Application Data. Se non sai dove sia la cache, prima individua il percorso reale con una ricerca sul profilo dell’utente amministrativo.

dir %LOCALAPPDATA%\Microsoft /s /b | findstr /i "Configuration Manager Console"
dir %APPDATA%\Microsoft /s /b | findstr /i "Configuration Manager"

Se dopo la ricreazione della cache i contatori tornano, hai chiuso il problema con un intervento locale e reversibile. Se non cambia nulla, il guasto è quasi certamente lato sito o provider.

Riparare il caso lato server senza fare danni collaterali

Quando il problema è lato server, l’obiettivo non è “riavviare tutto” ma isolare il punto esatto. Il rischio operativo aumenta perché tocchi servizi condivisi. Prima di ogni modifica, fotografa lo stato dei servizi e dei log, così puoi tornare indietro se la mitigazione peggiora la situazione.

Una sequenza prudente è questa:

1. Controlla se il servizio del provider SMS è in esecuzione.
2. Verifica che WMI sul server risponda a query semplici.
3. Controlla i log recenti del sito per errori di accesso al provider o al database.
4. Solo se i servizi sono in stato anomalo, esegui un riavvio mirato del servizio coinvolto, non dell’intero server.

Per esempio, prima di riavviare un servizio, annota lo stato attuale:

Get-Service *SMS* | Format-Table Name, Status, StartType
Get-EventLog -LogName Application -Newest 50 | Select-Object TimeGenerated, EntryType, Source, Message

Se il servizio provider resta in errore, valuta la riparazione della registrazione WMI o la reinstallazione del componente, ma solo dopo aver confermato che il problema non è una banale saturazione del server o un blocco di rete. Una reinstallazione cieca in SCCM è costosa e spesso inutile.

Controlli finali: come sapere che il fix è vero

La verifica finale non è “la console si apre”, ma “i contatori prestazioni tornano coerenti e aggiornati”. Devi vedere tre segnali: dati presenti, tempi di risposta accettabili e assenza di nuovi errori nei log.

1. Riapri la SCCM Console da un account amministrativo con i permessi corretti.
2. Raggiungi lo stesso nodo o la stessa vista che prima falliva.
3. Controlla che i contatori si popolino e che l’aggiornamento non produca errori nel log locale della console o nel log del provider.
4. Se hai modificato cache o profilo, verifica anche da una seconda sessione per escludere un fix casuale legato allo stato dell’utente.

Se hai toccato servizi o configurazioni, osserva per almeno un ciclo operativo: un recupero apparente seguito da nuovo errore indica che hai sistemato solo la superficie. Il rollback deve essere chiaro: ripristino della cache rinominata, riavvio del servizio riportato allo stato precedente, o restore della snapshot se hai toccato WMI o componenti più delicati.

Assunzione operativa: il guasto è trattato come incidente di produzione finché non dimostri il contrario; per questo la prima correzione deve essere minima, reversibile e validata con evidenza tecnica, non con impressioni visive.

Pattern pratico che evita falsi positivi

Il modo più efficiente per non perdere tempo è questo: prima conferma che il problema non sia locale, poi conferma che il provider risponda, poi guarda i permessi. Solo alla fine considera corruzione profonda del sito o del database. Nella pratica, i contatori prestazioni “rotti” in SCCM Console sono spesso una combinazione di cache, WMI e diritti di accesso, cioè problemi fastidiosi ma molto più banali di quanto sembrino all’inizio.

Se vuoi ridurre il rumore in futuro, tieni una checklist operativa con quattro campi: macchina amministrativa, account usato, stato provider, esito query WMI. Con quei quattro dati, il 90% delle diagnosi si chiude senza aprire ticket inutili o reinstallazioni complete.