Versioni SCCM, build, console e dettagli del client

Versioni SCCM, build, console e dettagli del client: come leggerli senza confonderli

Quando si parla di SCCM, oggi Configuration Manager o MECM, il punto critico non è solo sapere “che versione ho”, ma capire quale componente stai osservando. Site server, console e client non avanzano sempre allo stesso ritmo, e una mismatch banale può spiegare errori di console, policy che non arrivano o client che si registrano ma non scaricano contenuti.

Nel lavoro quotidiano conviene ragionare su tre livelli separati: versione del sito, versione della console e versione del client. A questi si aggiunge la build del database e, quando serve, il ramo di manutenzione installato. Se mescoli questi dati, finisci facilmente a inseguire un problema inesistente o a fare upgrade dove non serve.

Perché le versioni non coincidono quasi mai

In Configuration Manager il sito definisce la baseline funzionale. La console è solo il front-end amministrativo e può avere una build leggermente diversa, purché compatibile. Il client, invece, segue il suo ciclo di aggiornamento, spesso distribuito tramite client push, co-management o automatic client upgrade. Per questo è normale vedere console e client con numeri diversi dal site server.

La regola pratica è semplice: la compatibilità conta più dell’uguaglianza. Se la console è troppo vecchia rispetto al sito, alcune funzionalità spariscono o generano warning; se il client è indietro, può continuare a funzionare ma con limiti su inventario, endpoint analytics, co-management o feature recenti. Non serve inseguire il numero identico su tutto: serve sapere dove trovare il dato corretto e come interpretarlo.

Dove leggere la versione del sito SCCM

Il dato più affidabile del sito si legge dalla console, ma è utile sapere anche dove trovarlo lato server. Nella console vai su Administration → Overview → Site Configuration → Sites. Selezionando il sito, trovi la colonna Version o Build a seconda della vista. In molte installazioni compare anche l’informazione del branch, ad esempio Current Branch.

Un controllo più diretto si fa sul server del sito consultando il file di installazione o i log di setup. I percorsi più utili sono quelli sotto C:\Program Files\Microsoft Configuration Manager\Logs\ e, per l’installazione iniziale o gli aggiornamenti, i log del setup nella cartella di installazione. Se hai un dubbio sulla build effettiva, il log di setup è più affidabile di una schermata riassuntiva letta al volo.

Comando utile per verificare la presenza della console e dei log locali su una workstation amministrativa:

dir "C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole"
dir "C:\Program Files\Microsoft Configuration Manager\Logs"

Se la cartella dell’AdminConsole non esiste, la console potrebbe essere installata in un percorso diverso oppure non essere presente su quella macchina. In quel caso il problema non è il sito: stai guardando il posto sbagliato.

Versione e build della console: il punto che rompe più spesso gli accessi

La console SCCM/MECM ha una propria build e può essere aggiornata in modo indipendente, ma deve restare compatibile con il site server. Quando la console è troppo vecchia, i sintomi tipici sono: nodi che non si aprono, oggetti con proprietà incomplete, messaggi su funzionalità non supportate o assenza di alcune schede nel dettaglio di device e application.

Per leggerne la versione, in genere basta aprire la console e andare su Help → About Configuration Manager. Lì trovi la build della console. Questo numero è quello da confrontare con i requisiti di compatibilità della tua release. Se lavori in ambienti con più amministratori, controlla che tutti usino la stessa console o almeno una build compatibile: è un modo semplice per evitare comportamenti diversi a seconda del PC da cui si opera.

Se vuoi verificare senza aprire la GUI, puoi controllare il file eseguibile della console e le proprietà della versione. Un esempio su Windows:

Get-Item "C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe" |
Select-Object -ExpandProperty VersionInfo | Select-Object FileVersion, ProductVersion

Il dato utile è la ProductVersion o la FileVersion, non il nome del file. Se queste due non coincidono con il ramo atteso, hai un indizio concreto che la workstation admin non è allineata.

Dettagli del client: non limitarti al numero di versione

Il client Configuration Manager non si valuta solo con la versione del pacchetto installato. In campo servono almeno quattro dati: versione del client, stato del servizio, timestamp dell’ultimo policy retrieval e presenza di eventuali errori nei log. Un client “aggiornato” ma con ccmexec fermo o con policy vecchie è, di fatto, un client non affidabile.

Il percorso standard da controllare è C:\Windows\CCM\ e, soprattutto, C:\Windows\CCM\Logs\. I log più utili sono ClientLocation.log, CCMSetup.log, PolicyAgent.log, LocationServices.log e ClientIDManagerStartup.log. Non serve aprirli tutti: spesso bastano uno o due file per capire se il client è registrato, se parla con il management point e se riceve policy.

Per leggere la versione installata sul client puoi usare il WMI namespace di SCCM oppure controllare i file del servizio. Un approccio rapido è questo:

wmic /namespace:\\root\ccm path SMS_Client get ClientVersion /value

Se il comando restituisce una versione, hai conferma della registrazione WMI del client. Se non restituisce nulla o genera errore di namespace, il problema è più profondo: WMI danneggiato, client non installato correttamente o componente CCM non inizializzato.

In PowerShell puoi anche interrogare il servizio e il client WMI insieme:

Get-Service CcmExec
Get-CimInstance -Namespace root\ccm -ClassName SMS_Client | Select-Object ClientVersion

Se CcmExec non è in stato Running, la versione del client conta poco: prima va rimesso in piedi il servizio, poi si verifica l’aggancio al sito.

Build, hotfix e update rollup: leggere il ramo giusto

Molti ambienti non sono “puliti” come nei diagrammi. Trovi site server aggiornato, console quasi allineata, client misti e magari un hotfix applicato solo in parte. In queste condizioni la sola parola “versione” non basta. Devi distinguere tra baseline del branch e cumulative update o hotfix applicato sopra.

Il modo corretto è controllare la console nella sezione degli aggiornamenti: Administration → Updates and Servicing. Qui vedi quali update sono installati, quali sono in corso e quali sono falliti. Se l’update è stato importato ma non completato, la build visibile può essere fuorviante. Il log utile in questi casi è spesso CMUpdate.log sul site server.

Se stai facendo troubleshooting di un comportamento anomalo dopo un update, confronta sempre tre elementi: build del sito, build della console e versione del client interessato. È frequente che il problema stia nella combinazione, non in un singolo componente. Per esempio: una console aggiornata su un site non ancora allineato può mostrare proprietà o task non coerenti con il backend, mentre un client vecchio può ignorare policy nuove pur essendo “online”.

Un metodo pratico per fare inventario delle versioni

Se devi fare un check rapido su più macchine, conviene creare una raccolta minima e ripetibile. L’obiettivo non è costruire un report perfetto, ma avere in pochi minuti un quadro su sito, console e client. Un esempio di checklist operativa è questo:

1. leggi la build del sito dalla console in Administration → Sites;
2. leggi la build della console da Help → About Configuration Manager;
3. leggi la versione del client con wmic o PowerShell sul device;
4. controlla i log del client in C:\Windows\CCM\Logs\ se c’è una discrepanza;
5. verifica CMUpdate.log se il sito è in fase di aggiornamento.

Se vuoi automatizzare il controllo lato client, una query PowerShell minimale può bastare per un primo censimento:

$client = Get-CimInstance -Namespace root\ccm -ClassName SMS_Client -ErrorAction SilentlyContinue
[pscustomobject]@{
    ComputerName = $env:COMPUTERNAME
    ClientVersion = $client.ClientVersion
    CcmExecState = (Get-Service CcmExec -ErrorAction SilentlyContinue).Status
}

Questo non sostituisce i log, ma ti dice subito se il client è in uno stato ragionevole. Se ClientVersion è vuoto o il servizio non esiste, hai già un indicatore di anomalia da approfondire.

Quando la console funziona ma il client no

È uno dei casi più comuni: la console si apre, le query girano, ma alcuni client non ricevono policy o restano bloccati su vecchie informazioni. Qui la tentazione è guardare la console e fermarsi. Sbagliato. La console è solo il punto di controllo; l’evidenza vera sta sul device e nei log del client.

In pratica, se il client non si aggiorna, controlla in quest’ordine: servizio CcmExec, WMI root\ccm, connettività verso management point, DNS, e infine eventuali problemi di certificato o boundary group. Il dato di versione serve a capire se il client è vecchio, ma non spiega da solo perché è fermo. Per quello servono i log e lo stato del servizio.

Un dettaglio spesso trascurato: se il client è stato reinstallato o riparato, il numero di versione può sembrare corretto ma il record in console può restare sporco per un po’. In questi casi la conferma va fatta sul device e, se necessario, con una pulizia del record obsoleto in console dopo aver verificato che il nuovo client si sia registrato correttamente.

Quando la console è vecchia e il sito è più nuovo

Qui il sintomo classico non è il crash, ma la perdita di funzionalità. Alcuni menu spariscono, alcune schede non si popolano, certe azioni non sono disponibili o la console mostra messaggi generici. È il caso tipico di una workstation admin che non ha ricevuto l’aggiornamento della console dopo un upgrade del site.

La correzione è quasi sempre semplice: reinstallare o aggiornare la console dal punto di distribuzione corretto o dal site server, seguendo la procedura prevista dalla tua versione. Prima di farlo, salva eventuali preferenze locali e verifica che l’utente abbia i permessi necessari. L’operazione non è distruttiva, ma va trattata come change controllato perché impatta la capacità di amministrazione.

Se vuoi una verifica rapida post-aggiornamento, riapri Help → About Configuration Manager e confronta la build con quella del site. Se la differenza è ancora evidente, non insistere sulla GUI: c’è quasi sempre un problema di installazione locale o di binari non sostituiti correttamente.

Checklist minima da tenere in tasca

Se devi rispondere in fretta a un ticket o fare triage su un ambiente SCCM, questa è la sequenza che evita errori grossolani:

1. identifica il componente: site server, console o client;
2. leggi la build nel posto giusto, non da un dato indiretto;
3. se il client è il problema, guarda prima il servizio e i log, poi la versione;
4. se la console è il problema, confronta la build con il site;
5. se il sito è in aggiornamento, controlla CMUpdate.log e lo stato degli update.

Questa disciplina sembra banale, ma taglia via molta confusione. In SCCM i numeri contano, però contano di più il contesto e la relazione tra i componenti. Un client vecchio può essere accettabile se il sito lo supporta; una console vecchia può essere tollerata fino al primo task moderno; un update del sito incompleto può falsare tutto il resto.

Conclusione operativa: leggere le versioni come un sistema, non come un’etichetta

La lettura corretta di versioni e build in SCCM/MECM non serve a fare inventario fine a sé stesso. Serve a capire se il sistema è coerente. Quando i numeri sono allineati, i log smettono di raccontare storie ambigue; quando non lo sono, il primo lavoro serio è stabilire quale componente è fuori fase e con quale evidenza.

Se vuoi ridurre il tempo perso nei troubleshooting, tieni sempre separati i tre piani: site, console, client. È il modo più rapido per arrivare da “non va” a una diagnosi utile, senza confondere una build della GUI con una versione del server o con lo stato reale di un endpoint.