Verificare i tempi di avvio dei dispositivi con CMPivot in SCCM

Se vuoi capire quanto tempo impiegano davvero i dispositivi ad arrivare al desktop, CMPivot in SCCM è uno strumento più utile di quanto sembri. Non sostituisce un sistema di telemetry completo, ma per una verifica operativa su una collection ti dà una fotografia immediata: quali client sono online, quali rispondono, quali hanno orari incoerenti e, soprattutto, quali indizi puoi raccogliere per stimare i tempi di avvio dopo un reboot o una riaccensione forzata.

Il punto non è “avviare un cronometro” in modo assoluto. Il punto è definire una metrica osservabile e ripetibile: tempo tra boot del sistema, disponibilità del client SCCM, comparsa di eventi di logon, stato del servizio SMS Agent Host, oppure differenza tra ultimo avvio registrato e ora attuale. In ambienti Microsoft, questa distinzione conta più della precisione al secondo, perché ti evita di costruire report belli ma inutili.

Che cosa puoi misurare davvero con CMPivot

CMPivot lavora interrogando in tempo quasi reale i client della collection selezionata. Questo significa che puoi ricavare dati come LastBootUpTime, processi, servizi, eventi recenti, uptime e informazioni di sistema. Per i tempi di avvio, la domanda corretta è: qual è il momento del boot che mi interessa?

Ci sono almeno tre letture utili:

Se stai facendo troubleshooting, la seconda è spesso la più pratica. Se stai valutando performance percepita, ti serve combinare più indizi. CMPivot da solo non ti dice “l’utente ha visto la schermata login dopo 42 secondi”, ma può aiutarti a capire se il problema è nel boot, nel logon o in un componente che si aggancia dopo l’avvio.

Il limite principale: CMPivot non è un cronometro storico nativo

Qui conviene essere netti: CMPivot non nasce come strumento di benchmarking storico. È eccellente per interrogazioni rapide e ad hoc, meno per serie temporali lunghe e confronti statistici raffinati. Se vuoi misurare i tempi di avvio con una certa disciplina, devi salvare l’output, ripetere la query, e definire un criterio stabile.

Questo è il primo errore che vedo spesso: si lancia una query, si guarda il numero, e si conclude che “l’avvio è lento”. Senza contesto non sai se quel valore dipende da un device appena patchato, da un disco degradato, da un profilo utente enorme o da una finestra di manutenzione che ha alterato il comportamento del client.

La lettura corretta è: desktop management + osservabilità. CMPivot ti dà il dato. Sta a te incrociarlo con eventi, log di sistema e, quando serve, con una baseline precedente.

Query CMPivot utili per stimare il boot

Per partire senza complicarti la vita, la query più immediata è quella che recupera l’ultimo avvio del sistema. In CMPivot puoi usare un’interrogazione sulla classe di sistema o sugli eventi disponibili, a seconda del livello di dettaglio che ti serve.

Un approccio semplice è questo:

OperatingSystem | where Caption != '' | project Device, LastBootUpTime

Il risultato ti dà un riferimento temporale utile per calcolare l’uptime. Da lì puoi derivare una stima del boot “effettivo” confrontando l’orario corrente con LastBootUpTime. Non è ancora il tempo di avvio completo, ma è il punto di partenza corretto.

Se vuoi capire se il client SCCM è tornato operativo dopo il boot, aggiungi il controllo sul servizio principale:

Services | where Name == 'CcmExec' | project Device, Name, State, StartMode

Il servizio CcmExec in stato Running indica che il client è attivo e può rispondere alle query. Se il servizio è fermo, non stai misurando un boot “lento”: stai misurando un client non pronto o malfunzionante.

Per una vista più orientata alla fase di logon, puoi guardare eventi recenti nel registro di sistema o nel registro operativo di Windows, ad esempio eventi di avvio, di logon o del servizio shell. La precisione dipende dalla tua baseline e da quali provider hai deciso di osservare.

Metodo pratico: misurare boot e readiness con una baseline semplice

Se il tuo obiettivo è produrre un dato difendibile in una riunione tecnica, non serve una costruzione complessa. Serve una procedura ripetibile:

1. Definisci la collection di test: pochi dispositivi omogenei, non l’intero parco.
2. Decidi il punto di partenza: ultimo reboot, disponibilità del servizio client, oppure evento di logon.
3. Esegui la query CMPivot e salva l’output.
4. Ripeti dopo reboot controllati o dopo una finestra di manutenzione.
5. Confronta i valori con la stessa metrica, non con metriche diverse.

Un esempio sensato è misurare tempo tra riavvio e risposta del client. Se il PC si riavvia alle 10:00 e CMPivot mostra CcmExec in Running alle 10:03, hai un indicatore pratico: il device è tornato interrogabile in circa tre minuti. Non è il boot totale, ma è un dato operativo che puoi usare per verificare regressioni.

Se invece vuoi confrontare il tempo di avvio percepito dagli utenti, affianca CMPivot a log eventi o script di startup che scrivano timestamp in un file locale o in un event log dedicato. CMPivot allora diventa il punto di raccolta, non il generatore del dato.

Come leggere i risultati senza farsi ingannare

Il problema più comune è confondere uptime con tempo di avvio. Un device acceso da 12 giorni non ti dice nulla sulla qualità del boot di oggi. Ti dice solo che non è stato riavviato di recente.

Altra trappola: considerare uguali tutti i dispositivi della collection. In realtà il boot cambia molto in base a:

• tipo di storage, soprattutto se hai HDD, SSD SATA o NVMe;
• GPO e script di startup;
• antivirus e agent di sicurezza;
• profilo utente e carico di login;
• stato delle patch e dei driver;
• presenza di VPN o software che apre tunnel all’avvio.

Se una macchina parte in 40 secondi e un’altra in 4 minuti, non stai automaticamente vedendo un problema SCCM. Potresti avere un driver che blocca il kernel, un servizio terzo in timeout, o un disco con latenze anomale. CMPivot ti aiuta a individuare il sintomo, ma la diagnosi vera richiede l’incrocio con altri dati.

Correlare CMPivot con eventi e log di Windows

Per dare sostanza alla misura, il passo successivo è incrociare CMPivot con i log locali. Se hai un sospetto su avvio lento o client che torna online tardi, i canali classici sono il System e il Application, oltre ai log del client Configuration Manager quando disponibili.

Un controllo utile è verificare se il servizio del client è partito senza errori e se ci sono eventi di ritardo o crash. In parallelo, puoi confrontare l’ora del boot con la comparsa del primo evento utile al logon o con il momento in cui il device inizia a rispondere a CMPivot. Se il gap è costante, hai un pattern. Se il gap è variabile, hai probabilmente una causa intermittente o legata al carico.

Quando il dato non torna, non forzare conclusioni: prima verifica il timestamp della macchina, poi la sincronizzazione oraria, poi la raggiungibilità del client. Una macchina con orologio sballato può falsare completamente la lettura di LastBootUpTime o dei log eventi.

Esempio operativo: distinguere boot lento da client non disponibile

Scenario tipico: il team helpdesk segnala che “i PC ci mettono troppo ad accendersi”. Apri CMPivot sulla collection interessata e fai due interrogazioni distinte. La prima recupera l’ultimo boot, la seconda lo stato del servizio client. Se i client hanno boot recente ma CcmExec non è ancora running, il problema è nella fase post-boot, non nel kernel.

Query orientativa:

OperatingSystem | project Device, LastBootUpTime

Services | where Name == 'CcmExec' | project Device, State, StartMode

Se vuoi un confronto immediato, guarda i device con boot recente ma client non pronto. Questo ti segnala una coda di avvio, un servizio bloccato o un conflitto con altri agent. Se invece il boot stesso è vecchio ma l’utente lamenta lentezza al login, il problema è altrove: profilo, login script, policy o applicazioni in startup.

Quando conviene passare da CMPivot a un metodo più robusto

CMPivot è perfetto per il primo taglio diagnostico, ma ci sono casi in cui non basta. Se devi produrre un report periodico, confrontare settimane diverse o costruire un KPI di avvio, conviene affiancare una soluzione più strutturata: task pianificati, log centralizzati, Event Forwarding, Microsoft Defender for Endpoint, oppure una piattaforma di monitoring con agent.

La regola pratica è semplice: se l’informazione ti serve una volta, CMPivot va bene; se ti serve sempre, automatizza. CMPivot rimane comunque utile come strumento di validazione rapida: quando il dato storico dice che un gruppo di device è peggiorato, puoi entrare nella collection e verificare subito se il servizio client, il boot o il logon mostrano anomalie ricorrenti.

Buone pratiche per evitare numeri inutili

Per non trasformare la misura in un esercizio accademico, tieni queste regole operative:

• usa una collection omogenea, per modello o ruolo macchina;
• stabilisci una metrica unica per run;
• salva sempre timestamp, query e campione;
• non mescolare boot, logon e disponibilità del client nello stesso grafico senza etichette chiare;
• verifica l’ora di sistema prima di fidarti del risultato;
• se il client non risponde, trattalo come un dato mancante, non come un boot lento.

Queste regole sembrano basilari, ma fanno la differenza tra un dato difendibile e una stima approssimativa. In ambienti SCCM grandi, la qualità della misura dipende più dalla disciplina della raccolta che dalla query in sé.

Conclusione operativa: il valore di CMPivot sta nella velocità, non nella magia

Verificare i tempi di avvio dei dispositivi con CMPivot in SCCM funziona bene quando hai chiaro cosa stai misurando. Se vuoi sapere quando il sistema è tornato vivo, controlli boot e servizio client. Se vuoi capire dove si perde tempo, aggiungi eventi e logon. Se vuoi un KPI stabile nel tempo, CMPivot è il punto di partenza, non l’unica risposta.

In pratica, il metodo migliore è questo: definisci la metrica, interroga una collection mirata, confronta sempre gli stessi campi e usa CMPivot per validare rapidamente ciò che i log e le metriche ti stanno già suggerendo. È uno strumento da operatori, non da osservatori passivi. Ed è proprio qui che rende di più.