Dashboard di compatibilità Windows 11 in SCCM

Dashboard di compatibilità Windows 11 in SCCM: cosa misurare davvero

Se vuoi una dashboard utile e non un semplice conteggio di dispositivi “idonei” o “non idonei”, la prima scelta è definire quale compatibilità stai osservando. Con Windows 11 il punto non è solo sapere quanti PC possono aggiornarsi, ma capire perché alcuni restano fuori: CPU non supportata, TPM assente o disattivato, Secure Boot non attivo, RAM insufficiente, spazio disco critico, BIOS obsoleto, oppure un blocco imposto da policy o da una baseline interna.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

In SCCM la dashboard migliore nasce da una combinazione di inventario hardware, compliance settings, hardware readiness e report personalizzati. L’errore più comune è usare un solo indicatore e poi scoprire che il numero non regge quando si passa dal pilot alla produzione. Per questo conviene costruire il flusso in tre livelli: raccolta dati, normalizzazione dell’esito e visualizzazione operativa.

Classificazione del problema: design/guida, non incidente

Qui non stiamo correggendo un guasto puntuale, ma progettando un cruscotto affidabile. L’obiettivo è avere numeri verificabili, aggiornati e abbastanza granulari da supportare decisioni di rollout, esclusione o remediation.

Stato atteso vs osservato

Atteso: per ogni device gestito da SCCM hai un esito chiaro sulla compatibilità con Windows 11, con motivazioni tecniche leggibili e una percentuale aggregata per collection, sede, modello e versione BIOS.

Osservato spesso: un report generico mostra solo “compliant/non-compliant”, senza distinguere i fattori bloccanti né segnalare dati mancanti o stale inventory. Il risultato è una dashboard visivamente ordinata ma poco utile per pianificare l’upgrade.

1) Decidi il modello dati prima del report

La parte più importante non è il grafico, ma il modello. Devi stabilire quali attributi rappresentano la compatibilità e come verranno raccolti. In pratica, le dimensioni minime da considerare sono queste:

• CPU supportata: famiglia, generazione, architettura.
• TPM 2.0: presente, abilitato, versione rilevata.
• Secure Boot: attivo o meno.
• RAM: soglia minima e valore rilevato.
• Storage: spazio libero sufficiente per l’upgrade.
• Firmware/BIOS: versione e stato rispetto a una baseline interna.
• Esito finale: idoneo, non idoneo, dato mancante, non valutabile.

Il punto critico è distinguere non idoneo da non valutabile. Se un endpoint non riporta TPM o Secure Boot perché l’inventario è incompleto, non devi trattarlo come macchina incompatibile: stai solo vedendo un buco nella raccolta dati.

2) Scegli la fonte: inventario hardware, compliance o script custom

In SCCM puoi arrivare al risultato in più modi. La scelta dipende da quanto vuoi essere preciso e da quanto controllo hai sull’ambiente.

1. Hardware Inventory: è la base più naturale se vuoi consolidare dati già presenti in SCCM. Funziona bene per RAM, disco, BIOS, alcune proprietà del sistema e in parte per TPM/Secure Boot se il class reporting è stato esteso.
2. Compliance Baselines: utili se vuoi trasformare i requisiti Windows 11 in regole di conformità. Vantaggio: l’esito è già “compliant/non-compliant”. Svantaggio: per una dashboard davvero leggibile devi spesso aggiungere dettagli sulle cause.
3. Configuration Item con script PowerShell: è la strada più flessibile quando vuoi raccogliere direttamente stato TPM, Secure Boot, CPU e altri controlli specifici. È anche la via più trasparente se vuoi loggare il motivo del fallimento.

Se l’obiettivo è una dashboard operativa per il change management, la combinazione più robusta è: inventario per i dati statici, script per i controlli dinamici, report SQL per l’aggregazione.

3) Raccogli i prerequisiti Windows 11 con uno script leggibile

Quando la console non espone nativamente tutti i dettagli che ti servono, uno script PowerShell eseguito come compliance check o discovery method è spesso la soluzione più pulita. L’obiettivo non è fare un “test Windows 11” monolitico, ma produrre campi separati che poi la dashboard possa sommare e filtrare.

Un esempio concettuale di output utile è questo: dispositivo, TPM, Secure Boot, RAM, disco libero, CPU supportata, esito finale, timestamp. La dashboard deve poter leggere ogni campo separatamente.

DeviceName : PC-ACME-014
TpmPresent : True
TpmReady : True
SecureBoot : True
RamGB : 16
FreeDiskGB : 128
CpuSupported : True
Windows11Ready : True
CollectedAt : 2026-11-02 10:15:00

Se vuoi agganciare questi dati a SCCM, l’approccio pratico è salvare l’esito in una classe inventariata custom oppure usarlo in una baseline e poi esporre il risultato tramite report SQL. La scelta dipende dalla frequenza di aggiornamento che ti serve: per una dashboard di pianificazione, giornaliera o quasi giornaliera è spesso sufficiente; per un rollout aggressivo, meglio ridurre la latenza di raccolta.

4) Normalizza l’esito: idoneo, bloccato, incompleto

La dashboard deve parlare una lingua semplice anche se sotto ha logica complessa. Conviene quindi ridurre tutti i controlli a tre stati principali:

• Idoneo: tutti i prerequisiti minimi sono soddisfatti.
• Bloccato: almeno un prerequisito noto fallisce.
• Incompleto: i dati non bastano per una decisione affidabile.

Questa distinzione evita un problema classico: se il 30% del parco è “unknown”, rischi di leggere una compatibilità artificiosamente bassa o alta. In una dashboard seria il dato mancante deve emergere come categoria autonoma, non sparire dentro il non conforme.

5) Costruisci il report SQL con una logica di aggregazione semplice

Se il tuo backend è SQL Server, il report finale può essere alimentato da una vista o da una query che aggrega gli stati per collection, sede o modello. La struttura della query non deve essere elegante a tutti i costi: deve essere leggibile, manutenibile e soprattutto coerente con il dato che hai raccolto.

SELECT CollectionName, COUNT(*) AS TotalDevices, SUM(CASE WHEN Windows11Ready = 1 THEN 1 ELSE 0 END) AS ReadyDevices, SUM(CASE WHEN Windows11Ready = 0 THEN 1 ELSE 0 END) AS BlockedDevices, SUM(CASE WHEN Windows11Ready IS NULL THEN 1 ELSE 0 END) AS UnknownDevices
FROM dbo.Windows11Readiness
GROUP BY CollectionName
ORDER BY TotalDevices DESC;

Da qui puoi calcolare percentuali e semafori, ma evita di nascondere il valore assoluto. Una percentuale del 90% su una collection da 10 PC ha un peso diverso dal 90% su 3.000 endpoint. Il numero assoluto serve sempre per contestualizzare il rischio operativo.

6) Aggiungi i motivi di blocco, non solo l’esito finale

Una dashboard che dice solo “non idoneo” è troppo povera per essere utile. Devi arrivare almeno alle cause principali, in modo da capire dove investire remediation o sostituzione hardware.

• CPU non supportata.
• TPM assente o non attivo.
• Secure Boot disabilitato.
• RAM sotto soglia.
• Spazio disco insufficiente.
• BIOS/Firmware da aggiornare.

La cosa utile è anche il conteggio dei motivi multipli: un PC può fallire su più fronti contemporaneamente. Se la dashboard mostra solo il primo motivo trovato, rischi di sottostimare l’impatto di una remediation parziale.

7) Usa collection e query mirate per leggere il parco in modo utile

In SCCM il valore della dashboard aumenta quando la segmentazione rispecchia la realtà operativa. Le collection migliori non sono quelle più “pulite” dal punto di vista tecnico, ma quelle che aiutano a prendere una decisione: sede, reparto, modello, generazione hardware, tipo utente, laptop vs desktop, pilot vs broad deployment.

Una vista unica con tutto il parco è comoda per il numero totale, ma da sola non ti dice dove intervenire prima. Se un modello di notebook è diffuso e quasi interamente non compatibile, quella è una priorità diversa rispetto a una manciata di desktop vecchi sparsi in varie sedi.

8) Esporre la dashboard: console, report o Power BI

Hai tre strade pratiche. La console SCCM è immediata ma limitata. I report SSRS sono più coerenti per i team IT, perché restano dentro l’ecosistema Microsoft e permettono filtri e drill-down. Power BI è il passo successivo se vuoi una lettura più visuale, ma richiede disciplina sui dati a monte.

Se scegli Power BI, il punto non è solo il grafico. Devi curare refresh, permessi sul dataset e definizione delle metriche. Una dashboard con tre indicatori ben scelti vale più di una schermata piena di card decorative.

9) Controlli di qualità sui dati: il punto che molti saltano

Una dashboard affidabile deve includere anche controlli di qualità. Almeno questi:

1. Freshness: quando è stato raccolto l’ultimo dato per quel device?
2. Coverage: quanti endpoint hanno un record completo?
3. Coerenza: i valori di TPM, Secure Boot e BIOS sono plausibili tra loro?
4. Duplicati: esistono record ripetuti per lo stesso device o risorse stale?

Se non controlli la freschezza, puoi finire a pianificare upgrade su endpoint che non sono più attivi. Se non controlli la copertura, puoi prendere per affidabili percentuali costruite su dati incompleti. Sono errori banali, ma in ambienti grandi costano tempo e fiducia nel dato.

10) Esempio di percorso operativo per una rollout dashboard credibile

1. Definisci i prerequisiti minimi di Windows 11 che vuoi misurare.
2. Verifica quali campi sono già presenti nell’hardware inventory SCCM.
3. Estendi la raccolta con script o custom inventory per i campi mancanti.
4. Normalizza gli stati in idoneo, bloccato e incompleto.
5. Costruisci una vista SQL per aggregare per collection, sede e modello.
6. Esponi il report in SSRS o Power BI con filtri e drill-down.
7. Valida il risultato su un pilot di almeno una o due collection rappresentative.

Questo approccio è più lento di un report improvvisato, ma evita di rifare tutto dopo due settimane. La differenza tra un cruscotto “bello” e uno utile sta quasi sempre nella qualità del dato e nella chiarezza delle categorie.

11) Errori comuni da evitare

• Confondere inventario incompleto con incompatibilità reale.
• Mostrare solo percentuali e non i numeri assoluti.
• Ignorare il timestamp del dato raccolto.
• Usare un’unica etichetta “non compliant” per problemi diversi.
• Esporre la dashboard senza un filtro per collection o sede.
• Basarsi su un campione troppo piccolo e poi generalizzare al parco intero.

Un altro errore tipico è fermarsi al requisito hardware e non considerare il contesto operativo: un device teoricamente compatibile può essere bloccato da policy, da un firmware vecchio o da una configurazione BIOS incoerente con gli standard aziendali.

12) Cosa rende davvero utile la dashboard per Windows 11

La dashboard giusta non è quella che mostra il numero più alto o il grafico più ricco. È quella che consente di rispondere rapidamente a domande pratiche: quanti PC sono pronti oggi, quanti si possono rimettere in riga con una remediation, quanti vanno sostituiti e dove si concentra il rischio maggiore.

Se il dato è pulito, la lettura diventa immediata: il team di deployment sa dove partire, il service desk sa quali richieste aspettarsi e il management vede una fotografia realistica del parco. In un progetto Windows 11, questa differenza vale più di una dashboard “scenografica” ma opaca.

Una dashboard di compatibilità serve a decidere, non solo a mostrare. Se non distingue dati mancanti, blocchi reali e remediation possibili, sta solo decorando il problema.

Assunzione operativa: il parco è gestito in SCCM/MECM con SQL Server disponibile per reportistica e con possibilità di estendere l’inventario o usare una baseline di compliance per raccogliere gli indicatori mancanti.