Se devi capire quali patch sono state installate in un certo intervallo di giorni, CMPivot in SCCM è spesso più utile del reporting classico: interroghi i client quasi in tempo reale, incroci la cronologia locale con l’hardware inventory e ottieni risposte pratiche senza aspettare la replica dei dati.
Il punto chiave è questo: CMPivot non “magicamente” conosce la storia completa delle patch, ma legge ciò che il client può esporre subito. Per la data di installazione conviene appoggiarsi a WMI/CIM, in particolare alla classe Win32_QuickFixEngineering, e poi filtrare per intervallo temporale. In molti ambienti è la via più rapida per rispondere a domande tipo: “quali KB sono entrate ieri sera su questo gruppo di macchine?” oppure “chi ha ricevuto la cumulative update nel weekend?”.
Quando CMPivot è la scelta giusta
Usa CMPivot quando ti serve una fotografia operativa, non un report storico certificato. È adatto a:
- verificare rapidamente le patch installate su pochi o molti client;
- limitare il controllo a una collection SCCM già definita;
- incrociare installazioni recenti con un evento, un ticket o una finestra di manutenzione;
- validare se un deployment ha effettivamente raggiunto i nodi attesi.
Non è lo strumento migliore se cerchi una compliance auditabile a lungo termine o una timeline completa di installazioni e rimozioni. In quel caso serve il reporting SCCM, il log del client, o una soluzione di inventario più strutturata. CMPivot ti dà il dato operativo, non la certificazione storica.
La classe WMI da interrogare
La base più semplice è Win32_QuickFixEngineering. Su molti client restituisce gli hotfix e le KB installate, con campi utili come HotFixID e InstalledOn. Il limite è noto: il campo della data non è sempre omogeneo tra sistemi e build, e su alcune macchine può essere vuoto o formattato in modo non perfettamente coerente.
In pratica, la query va costruita sapendo che la qualità del dato dipende dal sistema operativo e da come Windows ha registrato l’aggiornamento. Se il campo InstalledOn non è affidabile, il passo successivo è incrociare anche i log del client o usare i dati di installazione di Windows Update dove disponibili.
Per una verifica veloce, la query di base è questa:
InstalledQuickFixEngineering
| project Device, HotFixID, InstalledOnLa forma esatta del comando può variare in base al contesto CMPivot, ma il principio è quello: elenchi gli hotfix e poi filtri il risultato per data.
Come filtrare le patch installate in giorni
Il problema vero non è vedere le patch, ma tradurre “negli ultimi 3 giorni” in un filtro affidabile. In CMPivot puoi lavorare con date e confronti, ma devi tenere presente che la colonna InstalledOn può arrivare in formato stringa. Quindi il filtro va testato sul tuo parco macchine, perché una sintassi che funziona in laboratorio può fallire su client con localizzazione diversa o dati incompleti.
Una strategia prudente è questa:
- prima estrai tutte le patch e osserva il formato reale di InstalledOn;
- poi definisci la finestra temporale che ti interessa;
- infine filtra i record in base alla data rilevata, validando un campione di client.
Se il formato data è coerente, il filtro diventa leggibile e veloce. Se non lo è, conviene normalizzare il dato lato output o spostare il controllo su un’altra sorgente, ad esempio i log del client o i report di compliance.
Query pratiche da usare in CMPivot
Qui sotto trovi i casi più utili in produzione. Non sono “ricette universali”, perché dipendono da versione OS, lingua del sistema e qualità del dato esposto dal client, ma sono un buon punto di partenza.
1. Elenco completo delle patch
InstalledQuickFixEngineering
| project Device, HotFixID, InstalledOn
| sort by InstalledOn descServe per capire subito cosa è stato installato e in che ordine apparente. Il controllo da fare è semplice: se la colonna data è vuota o incoerente, il dataset non è sufficiente per un filtro affidabile.
2. Solo le patch più recenti
InstalledQuickFixEngineering
| where InstalledOn > ago(3d)
| project Device, HotFixID, InstalledOnÈ la forma più comoda se il campo data è già utilizzabile. L’atteso è un elenco ridotto ai client che hanno installato hotfix negli ultimi tre giorni. Se non ottieni risultati ma sai che il deployment è andato a buon fine, il problema è spesso nel formato del campo o nella latenza di raccolta.
3. Finestra temporale precisa
InstalledQuickFixEngineering
| where InstalledOn between (datetime(2024-11-01) .. datetime(2024-11-03))
| project Device, HotFixID, InstalledOnQuesta forma è utile quando devi verificare una manutenzione pianificata. Il punto critico è la conversione della data: se il dato arriva come stringa non normalizzata, il filtro può restituire zero risultati anche con patch realmente presenti.
Come validare che il dato sia davvero attendibile
Prima di fidarti del risultato, fai una validazione minima su un paio di client rappresentativi. Su un nodo campione controlla il dato in locale e confrontalo con ciò che CMPivot restituisce. Se trovi differenze sistematiche, non forzare il filtro: il problema non è la query, è la sorgente del dato.
Un controllo utile è leggere la stessa informazione direttamente dal sistema operativo, ad esempio con PowerShell, per vedere se il formato della data è compatibile con ciò che vuoi filtrare. Un esempio di verifica locale è questo:
Get-HotFix | Select-Object HotFixID, InstalledOnSe qui il campo InstalledOn è valorizzato ma CMPivot lo mostra in modo diverso, hai un indizio chiaro: il client espone il dato, ma la forma con cui lo stai leggendo o filtrando va adattata. Se invece anche localmente il dato è scarso, il limite è a monte e non nel tool SCCM.
Scenari reali in cui CMPivot fa risparmiare tempo
Il primo scenario tipico è il post-deploy. Hai distribuito una cumulative update a una collection e vuoi sapere chi l’ha installata nelle ultime ore, senza attendere l’inventario hardware. CMPivot ti dà una risposta subito, utile per decidere se aprire una remediation o aspettare il prossimo ciclo di verifica.
Il secondo scenario è la gestione di un incidente. Se compare un bug noto dopo una patch, puoi interrogare rapidamente i client coinvolti e isolare i nodi che hanno ricevuto quella KB in una certa finestra temporale. Questo ti aiuta a capire se il problema è legato alla patch, alla sequenza di installazione, o a un’altra modifica coincidente.
Il terzo scenario è la verifica di compliance operativa. Non sostituisce un report formale, ma ti permette di rispondere a una domanda semplice e urgente: “quanti endpoint del gruppo X hanno installato gli aggiornamenti negli ultimi 2 giorni?”. In molti casi è sufficiente per decidere il passo successivo senza aspettare il batch notturno del reporting.
Limiti da conoscere prima di usarlo in produzione
Il limite più comune è la variabilità del dato. Non tutti i client espongono la stessa qualità di informazione, e non tutte le build di Windows trattano la data nello stesso modo. Se il tuo parco è misto, considera CMPivot come strumento di triage, non come unica fonte di verità.
Il secondo limite è la latenza di risposta. Anche se il motore è rapido, il risultato dipende dalla raggiungibilità del client, dal carico del sistema e dalla salute generale di SCCM. Se un endpoint è offline o molto degradato, la query non ti darà una fotografia utile in tempo reale.
Il terzo limite è la semantica della data. “Installato il giorno X” può significare cose diverse: avvio del processo, completamento effettivo, o data registrata dal sistema. Per questo, quando la precisione è importante, conviene accompagnare CMPivot con un controllo sui log del client.
Metodo operativo consigliato
Se vuoi usare CMPivot in modo affidabile per trovare le patch installate in giorni, il flusso pratico è questo:
- parti da una collection ristretta e rappresentativa;
- interroga Win32_QuickFixEngineering e osserva il formato reale di InstalledOn;
- prova prima un elenco completo, poi un filtro temporale semplice;
- confronta il risultato con un check locale su uno o due client;
- se il dato è incoerente, passa ai log o al reporting SCCM invece di forzare la query.
Questo approccio evita il classico errore: costruire una query elegante su un campo che nel mondo reale è sporco, vuoto o incoerente. In ambienti Microsoft la differenza tra “funziona in console” e “funziona sul campo” è spesso tutta lì.
Verifica finale e lettura del risultato
Il risultato corretto non è solo una lista di KB, ma una lista che risponde alla domanda iniziale. Se la richiesta è “quali patch sono state installate in giorni”, devi arrivare a un output che includa almeno device, KB e data di installazione. Senza la data, hai solo un inventario; senza il device, non puoi attribuire il cambiamento; senza la KB, non puoi correlare l’evento a un fix specifico.
Se vuoi fare un uso davvero pratico di CMPivot, pensa in termini di decisione operativa: devo sapere chi è stato toccato, quando e da quale patch. Tutto il resto è contorno. E quando il dato temporale non regge, il modo corretto di chiudere il gap non è inventare un filtro più aggressivo, ma cambiare sorgente o validare il formato prima di filtrare.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.