Query CMPivot per trovare la versione di Windows 10

Se devi capire quale versione di Windows 10 gira su un parco macchine gestito da Microsoft Endpoint Configuration Manager, CMPivot è la strada più corta. Non hai bisogno di aprire ogni client, né di aspettare un ciclo completo di inventory: lanci una query, leggi il risultato quasi in tempo reale e ti porti a casa il dato che serve per patching, compatibilità applicativa, supporto e compliance.

Il punto pratico è questo: in Windows 10 la parola “versione” viene usata in modo ambiguo. Spesso si intende la release del sistema, cioè 1909, 21H2, 22H2 e così via; altre volte si vuole il numero di build completo, ad esempio 19045.4046. CMPivot ti consente di estrarre entrambi i livelli, ma conviene partire dal dato che ti serve davvero. Se devi fare un report operativo, la release basta quasi sempre. Se stai inseguendo un bug o una vulnerabilità, la build completa è più utile.

La query CMPivot più utile per Windows 10

La query base parte dalla classe OS, che espone le proprietà del sistema operativo rilevate dal client. Per trovare la versione di Windows 10, la forma più semplice è questa:

OS | project Device, Caption, Version, BuildNumber, OSArchitecture

In molti ambienti il campo chiave è Version. Su Windows 10, di solito restituisce il ramo di release, ad esempio 10.0.19045. BuildNumber ti dà il numero di build, mentre Caption conferma il nome del sistema operativo. OSArchitecture è un extra comodo quando incroci il dato con software legacy o driver.

Se vuoi la vista più essenziale possibile, puoi restringere il set di colonne:

OS | project Device, Version, BuildNumber

Questo è il formato che uso più spesso quando devo esportare velocemente un elenco e confrontarlo con una matrice di compatibilità. Meno colonne significa meno rumore e meno margine di errore quando fai copia-incolla in Excel o in un ticket.

Come leggere correttamente il risultato

Un errore frequente è confondere il numero di build con la release. Per esempio:

• 19041 corrisponde alla base di Windows 10 2004.
• 19042 è 20H2.
• 19043 è 21H1.
• 19044 è 21H2.
• 19045 è 22H2.

Su molte macchine vedrai anche il numero di revisione dopo il punto, ad esempio 19045.4046. Quella parte cambia con gli aggiornamenti cumulativi. È il dato che serve se stai verificando se una correzione di sicurezza è stata applicata davvero, non solo se la macchina è “su Windows 10”.

Se il tuo obiettivo è sapere se un device è compatibile con una certa baseline, la combinazione più utile è:

OS | project Device, Caption, Version, BuildNumber, LastBootUpTime

LastBootUpTime non dice nulla sulla versione, ma aiuta a interpretare risultati strani: ad esempio un client appena aggiornato che non ha ancora completato il riavvio, o una macchina che da giorni non parla con il management point.

Query con filtro per Windows 10 soltanto

Se nel perimetro hai anche Windows 11, server o sistemi fuori standard, conviene filtrare i risultati già in CMPivot. La query seguente isola i sistemi che iniziano con Windows 10:

OS | where Caption startswith "Microsoft Windows 10" | project Device, Caption, Version, BuildNumber

In alcuni ambienti il valore di Caption può variare leggermente in base alla lingua o alla forma restituita dal client. Se il filtro non produce risultati, non dare per scontato che i device siano sbagliati: verifica prima il valore reale di Caption su un campione di endpoint.

Quando vuoi ridurre il rischio di falsi negativi, conviene usare un filtro più generico sul ramo 10.0:

OS | where Version startswith "10.0" | project Device, Caption, Version, BuildNumber

Questo approccio non distingue Windows 10 da altri sistemi basati su 10.0, ma per molti inventari rapidi è sufficiente. Se ti serve precisione assoluta, aggiungi sempre un secondo criterio sul caption o su un filtro di collection più stretto.

Versione, release e build: cosa conviene usare nei report

Nel reporting operativo, la scelta del campo cambia il valore del dato. Version è utile per raggruppare rapidamente i dispositivi per release. BuildNumber è più adatto al troubleshooting e alla sicurezza. Caption serve più come conferma visiva che come indicatore analitico.

In pratica:

1. Se devi sapere quanti PC sono su 22H2, usa Version.
2. Se devi verificare un KB o una vulnerabilità, usa BuildNumber e, se serve, la revisione completa del sistema.
3. Se devi esportare un elenco leggibile per il service desk, includi anche Device e Caption.

Un esempio pratico di query orientata al reporting è questo:

OS | summarize Count = count() by Version, BuildNumber | order by Version asc

Con questa vista vedi subito la distribuzione del parco macchine. È una query semplice ma molto efficace quando devi capire se il rollout di una nuova feature update è partito davvero o se una parte degli endpoint è rimasta indietro.

Quando il dato non torna: tre controlli rapidi

Se CMPivot restituisce risultati incompleti o incoerenti, il problema non è sempre la query. Prima di cambiare approccio, controlla tre cose.

1. Il client è online e raggiungibile. Se il device non risponde al management point, CMPivot non può interrogare il sistema in tempo reale. Qui la verifica minima è il risultato della console e lo stato del client nel device collection.
2. Il client è aggiornato e sano. Un agente vecchio o con problemi di policy può restituire dati parziali. Il controllo utile è nei log del client, tipicamente sotto C:\Windows\CCM\Logs\, con particolare attenzione a CMPivot.log e ai log di policy o connectivity correlati.
3. La proprietà interrogata esiste nel contesto giusto. Se hai adattato la query da un esempio generico, verifica il nome esatto del campo nella tua versione di MECM e nel tuo namespace CMPivot.

Quando il dubbio è sul campo, il metodo più pulito è partire da una query minimale e poi allargare. Ad esempio:

OS

Se la tabella base funziona, aggiungi una colonna alla volta. È un modo molto più veloce per capire se stai sbagliando filtro, proprietà o aspettativa sul formato del risultato.

Uso operativo: inventario, patching e compliance

La query per la versione di Windows 10 non serve solo a “sapere che sistema c’è”. In pratica ti aiuta in tre casi ricorrenti.

• Patching: individui i sistemi ancora fermi a release precedenti e li metti in coda per l’aggiornamento.
• Compatibilità applicativa: verifichi se una piattaforma supporta una specifica build minima o massima.
• Risk management: confronti la build con i bollettini di sicurezza e capisci se un endpoint è nella finestra vulnerabile.

In ambienti grandi, il valore vero non è la singola risposta, ma la possibilità di fare una fotografia immediata su una collection precisa. Se la collection è ben costruita, CMPivot diventa uno strumento di conferma rapida, non un sostituto dell’inventory storica.

Un esempio concreto: se devi controllare se una filiale è ancora ferma a Windows 10 21H2, puoi lanciare la query su una collection geografica o funzionale e ottenere in pochi secondi la distribuzione per Version. Se invece stai verificando una vulnerabilità legata a una build specifica, la colonna BuildNumber ti permette di separare i dispositivi “quasi aggiornati” da quelli effettivamente allineati.

Un piccolo trucco per evitare report ambigui

Se il risultato deve finire in un report o in un ticket, non esportare solo la versione. Aggiungi almeno un identificativo stabile del device e, se possibile, il dominio o l’ultima connessione utile. Un output più ricco evita discussioni inutili dopo tre giorni, quando qualcuno ti chiede quale macchina fosse davvero quella riga.

OS | project Device, Version, BuildNumber, OSArchitecture, LastBootUpTime

Se il tuo ambiente usa naming standard, Device può bastare. Se invece hai ambienti misti, conviene arricchire il dato con un campo di contesto della collection o esportare il risultato insieme al nome della collection stessa. CMPivot ti dà il dato tecnico; la governance del report la devi costruire sopra.

Versione Windows 10 da CMPivot: query pronte da riusare

Qui sotto ci sono tre varianti che coprono la maggior parte dei casi reali.

OS | project Device, Version, BuildNumber

Versione minimale, utile per inventario rapido.

OS | where Version startswith "10.0" | project Device, Caption, Version, BuildNumber

Versione filtrata su sistemi Windows 10 o comunque su ramo 10.0, con conferma del nome OS.

OS | summarize Count = count() by Version, BuildNumber | order by Version asc

Vista aggregata per capire la distribuzione del parco macchine. È quella che uso quando devo rispondere alla domanda più comune: “quanti siamo ancora indietro?”.

Se devi fare un controllo puntuale su una singola macchina, puoi anche usare il nome del device come filtro a monte della collection e poi leggere il dato nel pannello CMPivot. In quel caso la query resta identica: cambia solo il perimetro di esecuzione.

Conclusione operativa: il dato giusto al primo colpo

Per trovare la versione di Windows 10 con CMPivot, la query di partenza è semplice: OS | project Device, Caption, Version, BuildNumber. Da lì decidi se ti basta la release o se ti serve il build number completo. La regola pratica è non sovraccaricare il risultato: prima ottieni il dato utile, poi aggiungi contesto solo se serve davvero.

Nel lavoro quotidiano, CMPivot funziona bene quando è usato come strumento di verifica immediata: veloce, mirato, con un output leggibile. Se il risultato non torna, non forzare la query: controlla il client, i log e la reachability del device. È quasi sempre più rapido che inseguire la sintassi perfetta al buio.