• Guide, Sistemi Operativi
• 17 Febbraio 2026

Nel mondo UEFI Secure Boot, i certificati non sono un dettaglio, ma la radice di trust che permette al firmware di considerare legittimi i componenti di avvio come boot loader e boot manager, e quindi di bloccare manomissioni molto prima che il sistema operativo possa difendersi. A gennaio 2026 su ICT Power abbiamo pubblicato l’articolo Aggiornamento dei certificati Secure Boot: cosa cambia nel 2026 e come gestirlo in azienda per descrivere la transizione alla nuova chain 2023, necessaria perché i certificati Microsoft storici (chain 2011) presenti da anni su moltissimi dispositivi inizieranno a scadere nel 2026. In quella guida il focus era sull’approccio cloud con Microsoft Intune tramite Settings catalog per avviare e monitorare l’aggiornamento.

In questo articolo, invece, ci concentreremo sugli ambienti on-prem, dove i dispositivi sono domain-joined e gli aggiornamenti sono gestiti dall’IT. Vedremo come governare il rollout tramite Group Policy e come misurare e orchestrare la compliance con Microsoft Configuration Manager (SCCM). Questo approccio è in linea con le indicazioni ufficiali Microsoft dedicate agli scenari con IT-managed updates, che prevedono strumenti e controlli specifici per un’adozione graduale e verificabile. L’obiettivo è quello abilitare in modo controllato il deployment dei nuovi certificati tramite GPO, poi usare SCCM per costruire una baseline di compliance e creare collection dinamiche (compliant, non-compliant, error, unknown) utili per fare un pilota, monitoraggio e remediation, fino alla chiusura operativa del rollout.

In questa guida vedremo nel dettaglio:

• Prerequisiti, ADMX e configurazione delle GPO
  
• Come usare le GPO per avviare l’aggiornamento dei certificati Secure Boot
  
• Creare una Baseline di compliance in SCCM
  
• Checklist operativa
  
• Conclusioni
  

Prerequisiti e ADMX per la configurazione delle GPO

Partiamo dalle fondamenta, perché in questo scenario ci sono due piani distinti che devono essere entrambi a posto. Da un lato serve che Windows abbia la funzionalità necessaria per gestire l’aggiornamento dei certificati Secure Boot (cioè i registry keys e i task che eseguono il lavoro), dall’altro serve che l’infrastruttura di dominio abbia i template amministrativi (ADMX e ADML) aggiornati per poter configurare le impostazioni via Group Policy in modo pulito e supportato.

Sul piano Windows, Microsoft ha introdotto i registry keys (tra cui AvailableUpdates, UEFICA2023Status, UEFICA2023Error e le chiavi legate agli “assist” di rollout tramite Windows Update o Controlled Feature Rollout) all’interno di aggiornamenti rilasciati a partire dal 14 ottobre 2025 per le versioni supportate (Windows 10 22H2 e successive, Windows 11 supportate, Windows Server 2022 e successive), con ulteriori estensioni dall’11 novembre 2025 per versioni ancora in supporto. Questo è il prerequisito tecnico che rende realmente eseguibile il rollout, indipendentemente dal fatto che tu lo attivi via GPO o con altri strumenti.

Sul piano Group Policy, Microsoft ha pubblicato le impostazioni dedicate sotto il percorso Computer Configuration > Administrative Templates > Windows Components > Secure Boot

Figura 1: Secure Boot path in Group Policy Management

Per visualizzarle correttamente nella Group Policy Management Console, è necessario utilizzare Administrative Templates pubblicati nella guida ufficiale Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates. Trovate i pacchetti MSI degli ADMX per client e server (ad esempio gli Administrative Templates per Windows 11 2025 Update (25H2) e per Windows Server 2025) nella sezione Resources della guida sopraccitata.

Un ultimo prerequisito, spesso sottovalutato, è che l’aggiornamento dei certificati Secure Boot non è solo Windows ma dipende anche dal firmware, e vi raccomando dunque un rollout prudente. Alcuni dispositivi potrebbero anche aver bisogno di un aggiornamento del firmware prima di poter riuscire ad aggiornare i certificati Secure Boot.

Importante: se in azienda avete hardware recente, non date per scontato che l’attività non vi riguardi. Anche in presenza di modelli nuovi, è essenziale verificare lo stato reale della chain di trust e la corretta applicazione degli aggiornamenti, soprattutto in ambienti misti e con più generazioni di dispositivi.

Installazione ADMX

Come detto, uno dei prerequisiti è l’installazione degli ADMX. Se dovete gestire solo Windows 10 e Windows 11, scaricate e importate nel Central Store il pacchetto Client (Administrative Templates per Windows 11 2025 Update / 25H2 – V2.0). Se invece dovete gestire anche Windows Server (es. 2016/2019/2022/2025), scaricate e importate anche il pacchetto Server (Administrative Templates per Windows Server 2025). Vi lascio i link di seguito:

Tabella 1: Riferimenti e download ADMX per Windows Client e Windows Server

Importante: Nella sezione Resources, Microsoft pubblica due pacchetti distinti proprio perché le impostazioni Secure Boot sono pensate per essere applicate sia a Windows client sia a Windows Server. L’articolo infatti parla esplicitamente di domain-joined Windows clients and servers.

In questa demo vedremo come scaricare e installare gli Administrative Templates (ADMX/ADML) per la piattaforma Windows Client; la procedura è sostanzialmente identica anche per Windows Server, utilizzando il pacchetto dedicato indicato nella sezione Resources della guida Microsoft. Come prima cosa, apriamo la pagina Download Administrative Templates (.admx) for Windows 11 2025 Update (25H2) – V2.0 e avviamo il download del pacchetto MSI tramite il pulsante Download

Figura 2: Download ADMX per Windows Client – Parte 1

Una volta completato il download, eseguiamo il file MSI direttamente dal pannello dei download del browser oppure dalla cartella in cui è stato salvato

Figura 3: Download ADMX per Windows Client – Parte 2

All’avvio del wizard di installazione, selezioniamo Next per proseguire

Figura 4: Installazione ADMX per Windows Client – Parte 1

Nella schermata relativa alla licenza (EULA), selezioniamo la casella “I accept the terms in the License Agreement“ e proseguiamo con Next

Figura 5: Installazione ADMX per Windows Client – Parte 2

Nella schermata di setup, prendiamo nota del percorso in cui verranno estratti i file ADMX/ADML (oppure modifichiamolo tramite Browse, se necessario). Quindi selezioniamo nuovamente Next

Figura 6: Installazione ADMX per Windows Client – Parte 3

Avviamo l’installazione selezionando Install

Figura 7: Installazione ADMX per Windows Client – Parte 4

L’estrazione dei file richiede in genere pochi secondi. Attendiamo il completamento della procedura

Figura 8: Installazione ADMX per Windows Client – Parte 5

Al termine, selezioniamo Finish per chiudere la finestra.

Figura 9: Installazione ADMX per Windows Client – Parte 6

Copia dei file ADMX e ADML nel Central Store

Nel prossimo step copieremo i file nel Central Store (SYSVOL) per renderli disponibili nella Group Policy Management Console. In un dominio Active Directory, quando esiste un Central Store, gli strumenti di Group Policy lo verificano automaticamente e utilizzano i file ADMX/ADML presenti lì (invece dei template locali), garantendo linearità tra tutte le postazioni amministrative e tra i Domain Controller.

Dopo aver installato il pacchetto MSI degli Administrative Templates, i file vengono estratti in una cartella PolicyDefinitions sul computer (tipicamente sotto C:\Program Files (x86)\Microsoft Group Policy\<versione>\PolicyDefinitions come visto in Figura 6). A questo punto l’operazione corretta è copiare i contenuti nel Central Store del dominio, che dovreste avere in \\vostro-dominio.com\SYSVOL\ vostro-dominio.com\policies\PolicyDefinitions. I file presenti nel Central Store vengono poi replicati su tutti i Domain Controller tramite SYSVOL.

Figura 10: Cartella PolicyDefinitions in SYSVOL

Operativamente, per evitare sorprese in produzione, conviene seguire una logica conservativa:

• Prima di tutto fate un backup della cartella PolicyDefinitions già presente nel Central Store (se esiste), così avete una strada di rollback immediata in caso di conflitti tra template o regressioni. Non è ossessione, è best practice mantenere un repository ordinato dei template ADMX/ADML che utilizziamo, proprio per gestire questi aggiornamenti in modo controllato
• Se il Central Store non esiste, createlo creando la cartella PolicyDefinitions sotto SYSVOL nel percorso indicato. Se invece esiste già e volete gestire l’aggiornamento in modo ancora più safe, potete anche optare per l’utilizzo di una cartella versionata (ad esempio PolicyDefinitions-25H2) come approccio organizzativo
• Infine, copiate nel Central Store tutti i file .admx dalla cartella di origine del pacchetto MSI e, soprattutto, copiate anche i file .adml nelle sottocartelle lingua corrispondenti (ad esempio it-it e/o en-us). La parte ADML è quella che spesso viene dimenticata, ma senza i file lingua corretti, alcune impostazioni possono apparire in modo incompleto o non leggibile nell’editor delle GPO

Importante: se il vostro obiettivo fosse importare solo lo stretto necessario per le impostazioni Secure Boot, i file di riferimento sarebbero SecureBoot.admx e il relativo file lingua SecureBoot.adml. In teoria potreste quindi copiare esclusivamente questi due file nel Central Store. Operativamente, però, il consiglio è di evitare aggiornamenti parziali degli Administrative Templates. Aggiornare solo alcuni ADMX/ADML aumenta il rischio di incoerenze tra template (dipendenze tra policy, versioni disallineate, descrizioni mancanti o impostazioni che non compaiono correttamente in GPMC), e rende più complessa la gestione nel tempo perché dopo qualche mese diventa difficile ricostruire quali file sono stati aggiornati e perché. È molto più sano adottare un approccio consistente; quando si aggiorna il set di Administrative Templates per una piattaforma, si aggiorna l’intero pacchetto nel Central Store, mantenendo allineati ADMX e ADML e documentando la versione/data del pacchetto utilizzato. In questo modo riducete i problemi di compatibilità, semplificate troubleshooting e rendete l’operazione ripetibile anche per chi metterà mano al dominio in futuro.

Figura 11: Copia dei file .admx e .adml in SYSVOL/dominio/Policies/PolicyDefinitions

A copia completata, aprendo la Group Policy Management Console dovreste vedere le impostazioni sotto Computer Configuration > Administrative Templates > Windows Components > Secure Boot e poterle configurare

Figura 12: Group Policy Management – Secure Boot

Come usare le GPO per avviare e governare l’aggiornamento dei certificati Secure Boot

In questo capitolo passiamo dalla teoria alla governance operativa. Creeremo una GPO dedicata, abiliteremo il deployment delle impostazioni e decideremo consapevolmente se lasciare in gioco gli “assist” di distribuzione automatica oppure mantenere un controllo più granulare. Prima di procedere, due note operative importanti che Microsoft mette nero su bianco e che abbiamo già riportato nel precedente articolo
Aggiornamento dei certificati Secure Boot: cosa cambia nel 2026 e come gestirlo in azienda – ICT Power: l’aggiornamento dipende dal firmware e può avere problemi di compatibilità, quindi va validato su almeno un dispositivo rappresentativo per ogni tipologia; inoltre, una volta applicati al firmware, i nuovi certificati non sono rimovibili da Windows ed eventuali rimozioni richiedono intervento da interfaccia firmware.

Ciò detto, passiamo alla pratica! Apriamo la Group Policy Management Console avviando gpmc.msc dalla barra di ricerca di Windows oppure tramite Esegui (Win+R).

Figura 13: Creazione GPO per Secure Boot settings – Parte 1

Una volta aperta la console, espandiamo il dominio e selezioniamo Group Policy Objects. Nel riquadro centrale, facciamo clic con il tasto destro e scegliamo New per creare una nuova GPO.

Figura 14: Creazione GPO per Secure Boot settings – Parte 2

Assegniamo un nome descrittivo alla GPO (ad esempio “SecureBoot_Settings“) e confermiamo con OK.

Figura 15: Creazione GPO per Secure Boot settings – Parte 3

La nuova GPO comparirà nell’elenco sotto Group Policy Objects. A questo punto, facciamo clic con il tasto destro sulla GPO appena creata e selezioniamo Edit per aprire l’editor e configurare le impostazioni.

Figura 16: Creazione GPO per Secure Boot settings – Parte 4

Impostazioni GPO Secure Boot

Navighiamo in Computer Configuration > Administrative Templates > Windows Components > Secure Boot: qui Microsoft espone tre impostazioni che servono a governare il rollout dei certificati Secure Boot in scenari “IT-managed updates“. È importante leggerle come tre leve distinte: una innesca il processo, le altre due definiscono quanto automatico vuoi che sia il rollout.

• Enable Secure Boot Certificate Deployment
  
• Automatic Certificate Deployment via Updates
  
• Certificate Deployment via Controlled Feature Rollout
  

Figura 17: Creazione GPO per Secure Boot settings – Parte 5

Enable Secure Boot Certificate Deployment

Questa è l’impostazione chiave, è quella che avvia realmente il processo sul client. Se questa policy non è abilitata, potete anche ottimizzare le altre due, ma il rollout non parte.

• Quando la impostate su Enabled, Windows abilita il deployment dei certificati Secure Boot e porta avanti il workflow quando gira l’attività pianificata dedicata (l’elaborazione avviene a cadenza periodica, tipicamente ogni 12 ore)
• Il processo può richiedere uno o più riavvii per completare in modo sicuro alcuni passaggi (non è un reboot forzato). Nella pratica, il completamento si appoggia ai riavvii normali del dispositivo (patching, manutenzione, reboot utente)
• Questa policy corrisponde a una logica di configurazione lato registro (in particolare il valore AvailableUpdates): è utile saperlo perché, nel capitolo su SCCM, potremo misurare stato ed errori leggendo gli indicatori ufficiali di avanzamento

Figura 18: Setting Enable Secure Boot Certificate Deployment

Automatic Certificate Deployment via Updates

Questa impostazione stabilisce se i dispositivi che Microsoft ha già convalidato come compatibili possono ricevere l’aggiornamento in modo più automatico tramite i normali aggiornamenti mensili di Windows.

Qui la cosa più importante è interpretare correttamente
Enabled e Disabled, perché non è subito intuitivo:

• Enabled: di fatto blocca la distribuzione automatica per i dispositivi “convalidati” (state dicendo: “non farlo automaticamente, lo governo io“)
• Disabled: abilita l’aggiornamento automatico per i dispositivi con esito convalidato (state dicendo: “ok, se Microsoft lo considera safe, vai pure“)
• Not Configured: mantiene il comportamento predefinito

Quando usarla:

• Se volete un controllo più granulare (pilota rigido, deploy a waves, remediation prima di proseguire), spesso conviene abilitare questa policy (cioè bloccare l’automatico) e gestire tutto con scoping GPO + monitoraggio in SCCM.
• Se invece volete usare l’aggiornamento automatico come acceleratore sui device safe, potete lasciarla Not Configured oppure impostarla Disabled (in base alla strategia di governance che volete adottare).

Figura 19: Setting Automatic Certificate Deployment via Updates

Certificate Deployment via Controlled Feature Rollout (CFR) (opt-in al rollout controllato Microsoft)

Questa terza impostazione consente di partecipare al Controlled Feature Rollout gestito da Microsoft.

• Serve quando volete che la propagazione segua un rollout controllato da Microsoft con logiche di gradualità e selezione.
• Richiede che i dispositivi possano inviare a Microsoft i dati di diagnostica obbligatori necessari per questo tipo di meccanismo (vedi pagina Microsoft sulla Telemetria)
• Anche questa policy ha un mapping a chiave di registro utile per verifiche e compliance, ma dal punto di vista pratico la domanda che dovreste porvi è “intendo aderire a questo modello di rollout, lato policy e lato privacy e compliance?“

Figura 20: Setting Certificate Deployment via Controlled Feature Rollout

Suggerimenti per la configurazione

In ambienti enterprise, la scelta più solida e più governabile è gestire il rollout in modo granulare, evitando sia l’opt-in al Controlled Feature Rollout (CFR) gestito da Microsoft, sia la distribuzione assistita tramite il normale ciclo di patching. Qui non stiamo parlando di una normale impostazione di Windows, ma di un aggiornamento che coinvolge anche il firmware UEFI, può esporre casi di compatibilità per specifiche piattaforme e, una volta applicati i certificati al firmware, non è reversibile da Windows. In più, Microsoft raccomanda esplicitamente una validazione per tipologia di device e un rollout controllato per bucket.

Con un approccio più granulare ed un deploy per waves riuscirete a garantire change management, finestre di riavvio in linea con le vostre esigenze e processi interni, e remediation mirate per i modelli di pc più problematici. Con gli assist automatici rischiate invece di avere progressi non uniformi, meno prevedibilità operativa e più complessità quando dovrete monitorare chi ha ricevuto cosa e quando.

Per questo, in questo articolo adotteremo la strada della gestione granulare con Group Policy + monitoraggio e orchestrazione tramite SCCM. Le impostazioni che dunque vi suggerisco di adottare, per avere il rollout completamente sotto il vostro controllo, sono:

• Enable Secure Boot Certificate Deployment = Enabled
• Automatic Certificate Deployment via Updates = Disabled (update automatico bloccato)
• Certificate Deployment via Controlled Feature Rollout = Disabled (o Not Configured)

Figura 21: Creazione GPO per Secure Boot settings – Parte 6

Distribuire la GPO Secure Boot

Una volta completata la configurazione della GPO, è il momento di distribuirla ai client. Il suggerimento, in linea con l’approccio prudente adottato in questa guida da Microsoft, è di partire con un pilota ristretto, applicando la policy a una OU di test che includa pochi dispositivi, preferibilmente di modelli differenti. In questo modo potete validare fin da subito la compatibilità con l’hardware del tuo vostro macchine, riducendo il rischio di incontrare problematiche a sorpresa quando estenderete il rollout in produzione.

Nel nostro esempio abbiamo già una OU denominata Workstations. Per semplicità linkeremo lì la GPO (in un contesto reale, l’ideale è una OU dedicata al pilot come indicato sopra). Per procedere, facciamo clic con il tasto destro sulla OU scelta e selezioniamo “Link an Existing GPO…” dal menu contestuale.

Figura 22: Link GPO in Organization Unit – Parte 1

Nella finestra che si apre, selezioniamo la GPO appena creata (nel mio caso “SecureBoot_Settings“) e confermiamo con OK.

Figura 23: Link GPO in Organization Unit – Parte 2

Da questo momento la GPO risulta collegata alla OU selezionata. Alla successiva applicazione delle Group Policy sui client (secondo il normale ciclo di refresh), i dispositivi inizieranno a ricevere le impostazioni e ad avviare il processo di aggiornamento, che potrà completarsi nell’arco delle successive esecuzioni dell’attività pianificata (e, dove necessario, dopo i riavvii previsti dal normale ciclo operativo).

Figura 24: Link GPO in Organization Unit – Parte 3

Per verificare cosa succede lato client (Registro di Sistema, PowerShell ed Event Viewer) ho già riportato una serie di controlli pratici e a prova di produzione nel capitolo Troubleshooting dell’articolo Aggiornamento dei certificati Secure Boot: cosa cambia nel 2026 e come gestirlo in azienda – ICT Power. Per evitare duplicazioni e mantenere questa guida focalizzata su Group Policy e SCCM, vi consiglio di consultare direttamente quella sezione, dove trovate anche gli indicatori ufficiali di stato (chiavi di registro e codici errore) e gli eventi principali da correlare in caso di blocchi o comportamenti anomali.

Differenze GPO vs Microsoft Intune

Aggiungo questo paragrafo per evidenziare una differenza che può emergere tra la configurazione via GPO vista in questo articolo e la configurazione distribuita via Microsoft Intune descritta nella guida precedente.

Lato client, i valori di riferimento del Registro di sistema si trovano in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot. Sia la policy Intune “Enable Secureboot Certificate Updates” sia la GPO “Enable Secure Boot Certificate Deployment” corrispondono ufficialmente al valore AvailableUpdates, cioè il bitmask che funge da trigger per avviare le azioni di aggiornamento.

Nella pratica, però, può capitare che con la distribuzione via GPO vediate anche un secondo valore chiamato AvailableUpdatesPolicy, oltre ad AvailableUpdates. Microsoft non lo elenca nella tabella ufficiale delle registry keys (quindi non va considerato un prerequisito documentato), ma dai test che ho effettuato sembrerebbe che AvailableUpdatesPolicy sia stato inserito come valore aggiuntivo quando si abilita la GPO.

Il modo più corretto e prudente per interpretare la differenza ritengo sia questo:

• AvailableUpdates è il valore operativo usato dal processo di aggiornamento
• AvailableUpdatesPolicy, quando presente, va visto come un possibile valore di policy per la presenza o persistenza lato GPO (un dettaglio implementativo direi), utile a non confondere il valore desiderato impostato dalla configurazione con il valore runtime che può variare mentre Windows completa i passaggi. Questa lettura è in linea con ciò che si osserva in ambienti GPO, ma non è descritta come meccanismo ufficiale in un KB.

Per evitare falsi positivi o falsi negativi, soprattutto quando poi costruiremo la baseline in SCCM, la regola più efficace sarà che per misurare davvero l’avanzamento non bisognerà guardare AvailableUpdates o AvailableUpdatesPolicy, ma usa gli indicatori ufficiali di stato sotto …\SecureBoot\Servicing (in particolare UEFICA2023Status e UEFICA2023Error) e, se serve, correla con gli eventi in Event Viewer. Trovate i riferimenti di queste chiavi di registro alla paragrafo Registro di sistema della guida precedente.

Figura 25: AvailableUpdates vs AvailableUpdatesPolicy

Creare una Baseline di compliance in SCCM

È ora di passare oltre. In questo capitolo entreremo subito nel pratico lato SCCM e vedremo come trasformare questi segnali in un modello di misurazione ripetibile, costruendo una baseline di compliance (Configuration Item + Configuration Baseline) e generando collection dinamiche per stato (Compliant, Non-Compliant, Error, Unknown). L’obiettivo è avere un rollout realmente governabile in modo da sapere sempre quali dispositivi hanno completato l’aggiornamento, quali sono fermi in una fase intermedia, e quali richiedono interventi mirati di remediation prima di estendere la distribuzione alla wave successiva.

Per questo esempio abbiamo creato una device collection denominata “Secure Boot (Check compliance)“, voi chiamatela come preferite e posizionatela dove volete, infine Inserite dentro i dispositivi pilota.

Figura 26: Creazione device collection pilota in SCCM

Creazione Configuration Item

Dal menu Assets and Compliance, navighiamo in Compliance Settings > Configuration Items. Qui potete scegliere una cartella già esistente (ad esempio una folder dedicata alle baseline di sicurezza), crearne una nuova per tenere ordinati gli oggetti di progetto, oppure lavorare direttamente nella root: la scelta non impatta il funzionamento, ma una folder dedicata rende molto più semplice manutenzione e troubleshooting nel tempo. Una volta posizionati in Configuration Items, facciamo clic con il tasto destro e selezioniamo Create Configuration Item.

Figura 27: Creazione Configuration Item in SCCM – Parte 1

Appena si apre il wizard, nella scheda General inseriamo il nome del nostro Configuration Item (nel nostro esempio “Secure Boot Compliance“). La descrizione è facoltativa, ma in un ambiente con molte baseline può essere utile per contestualizzare lo scopo. Nella sezione Settings for devices managed with the Configuration Manager client selezioniamo Windows Desktops and Servers (custom). Questa opzione ci permette di definire un controllo personalizzato tramite script, basato sugli indicatori ufficiali lato client. Infine, facciamo click su Next.

Figura 28: Creazione Configuration Item in SCCM – Parte 2

Nella scheda Supported Platforms possiamo restringere l’applicabilità del CI alle versioni di Windows effettivamente in scope (ad esempio solo Windows 11 x64). È un passaggio opzionale, ma consigliato per evitare esecuzioni su piattaforme non pertinenti o non supportate. Concludiamo con Next.

Figura 29: Creazione Configuration Item in SCCM – Parte 3

Nella scheda Settings facciamo click su “New…“. Si apre il wizard Create Setting. Compiliamo i campi principali:

• Name: ad esempio CheckCA2023
• Setting type: selezioniamo Script
• Data type: selezioniamo String

Figura 30: Creazione Configuration Item in SCCM – Parte 4

Nella sezione Discovery script facciamo click su “Add Script…“. Si aprirà la finestra Edit Discovery Script. Verifichiamo che Script language sia impostato su Windows PowerShell, quindi incolliamo lo script seguente:

Per lo scopo di questa guida, lo script è volutamente semplice ma rigoroso. Ci restituirà Compliant solo quando UEFICA2023Status è Updated e UEFICA2023Error è 0. In scenari reali potreste essere tentati di aggiungere logiche alternative (ad esempio se il DB contiene Windows UEFI CA 2023 ma lo status non è valorizzato). Il mio suggerimento, però, è mantenere una regola rigorosa. Finché entrambi gli indicatori non risultano in linea, la compliance deve restare Non-Compliant, così la reportistica e le collection SCCM rimangono pulite e non producono falsi positivi.

Quando abbiamo terminato, facciamo click su OK per salvare il discovery script e poi su OK per chiudere il setting.

Figura 31: Creazione Configuration Item in SCCM – Parte 5

A questo punto spostiamoci nella scheda Compliance Rules per definire la regola associata al setting appena creato.

    Figura 32: Creazione Configuration Item in SCCM – Parte 6

Facciamo click su New… per creare una rule: si aprirà il wizard Create Rule. Compiliamo così:

• Name: ad esempio CA2023Compliant
• Rule type: Value
• Operator: Equals
• Value: Compliant (la stringa restituita dallo script quando il dispositivo è conforme)
• Noncompliance severity: consigliato Information (o, se volete essere più stringenti in fase di rollout, potete usare Warning; dipende tutto dalla vostra governance)

Concludiamo con OK.

Nota: se volete che il dispositivo risulti Non-Compliant anche nel caso in cui lo script non trovi l’istanza del setting (ad esempio chiavi mancanti), potete selezionare l’opzione “Report noncompliance if setting instance is not found”. In questa specifica verifica è una scelta sensata, perché l’assenza delle chiavi può indicare prerequisiti non presenti o device fuori scope.

Figura 33: Creazione Configuration Item in SCCM – Parte 7

A questo punto applichiamo e chiudiamo con Apply e poi Ok.

Figura 34: Creazione Configuration Item in SCCM – Parte 8

Tornati al wizard principale, facciamo click su Next.

Figura 35: Creazione Configuration Item in SCCM – Parte 9

Nella schermata successiva (dove vengono riepilogate le compliance rules) possiamo proseguire ancora con Next, perché abbiamo già completato la parte di definizione regole.

Figura 36: Creazione Configuration Item in SCCM – Parte 10

Nella scheda Summary verifichiamo che le informazioni siano corrette (nome CI, piattaforme, setting, regola) e avviamo la creazione facendo click su Next.

Figura 37: Creazione Configuration Item in SCCM – Parte 11

La creazione può impiegare qualche secondo. Al termine, nella schermata conclusiva selezioniamo Close.

Figura 38: Creazione Configuration Item in SCCM – Parte 12

Figura 39: Creazione Configuration Item in SCCM – Parte 13

Il nostro Configuration Item è ora pronto. Nel prossimo capitolo creeremo la Configuration Baseline che includerà questo CI e la distribuiremo alla collection pilota per misurare la compliance e costruire collection dinamiche utili per monitoraggio e remediation.

Figura 40: Creazione Configuration Item in SCCM – Parte 14

Creazione Configuration Baseline

Spostiamoci ora nella sezione Compliance Settings > Configuration Baselines. Qui facciamo clic con il tasto destro e selezioniamo Create Configuration Baseline.

Figura 41: Creazione Configuration Baseline in SCCM – Parte 1

Nel wizard che si apre, assegniamo un nome alla baseline (ad esempio “Secure Boot Compliance Baseline“) e, se lo ritenete utile, aggiungiamo una descrizione per contestualizzare l’obiettivo. Proseguiamo quindi con Add > Configuration Items per includere nella baseline il Configuration Item creato nel capitolo precedente

Figura 42: Creazione Configuration Baseline in SCCM – Parte 2

Nel wizard Add Configuration Items che si apre, utilizziamo la barra di ricerca per individuare il Configuration Item creato in precedenza (nel nostro esempio “Secure Boot Compliance CI“). Selezioniamolo dall’elenco e facciamo click su Add.

Figura 43: Creazione Configuration Baseline in SCCM – Parte 3

Una volta aggiunto il Configuration Item alla lista, confermiamo con OK.

Figura 44: Creazione Configuration Baseline in SCCM – Parte 4

Tornati nella finestra principale di creazione della baseline, possiamo verificare che il Configuration Item compaia correttamente tra gli elementi inclusi. A questo punto concludiamo il processo facendo click su OK.
Nota: se i dispositivi sono gestiti in co-management, abilitate anche l’opzione “Always apply this baseline even for co-managed clients”. In questo modo la baseline verrà valutata anche sui client co-managed, evitando che la configurazione venga esclusa in base alle impostazioni di workload e alle logiche di gestione condivisa.

Figura 45: Creazione Configuration Baseline in SCCM – Parte 5

Deploy Configuration Baseline

A questo punto possiamo distribuire la Configuration Baseline alla collection pilota. Posizioniamoci sulla baseline appena creata, facciamo clic con il tasto destro e selezioniamo Deploy.

Figura 46: Deploy Configuration Baseline in SCCM – Parte 1

Nel wizard che si apre, la baseline sarà già presente nella sezione Selected configuration baselines. Ora dobbiamo indicare la collection di destinazione: facciamo clic su “Browse…” Nella finestra di selezione, dal menu a tendina scegliamo Device Collections, poi navighiamo nella folder in cui abbiamo salvato la collection pilota, selezioniamola e confermiamo con OK.

Figura 47: Deploy Configuration Baseline in SCCM – Parte 2

A questo punto configuriamo la Schedule di valutazione. Questa pianificazione stabilisce ogni quanto spesso il client SCCM riesegue il discovery script del Configuration Item e aggiorna lo stato di compliance della Baseline. In un’attività critica come questa per l’aggiornamento dei certificati Secure Boot con possibili step intermedi e reboot necessari, è consigliabile una valutazione almeno giornaliera, così da avere un monitoraggio regolare senza introdurre carico inutile sui client. Selezioniamo quindi Simple schedule con frequenza Every 1 days oppure, se preferite un controllo più ravvicinato durante il pilot, potete impostare una schedule personalizzata (ad esempio ogni 12 ore) e poi ridurla quando il rollout entra in fase stabile. Completata la configurazione, facciamo clic su OK per avviare il deploy.

Da questo momento i dispositivi della collection pilota riceveranno la Baseline e inizieranno a valutarla secondo la schedulazione impostata.

Figura 48: Deploy Configuration Baseline in SCCM – Parte 3

Creazione device collection di monitoraggio

Ora che la Configuration Baseline è stata distribuita, possiamo creare delle Device Collection dinamiche basate sullo stato di compliance della baseline. È un passaggio molto utile perché trasforma il monitoraggio in qualcosa di operativo: invece di guardare un report, ti ritrovi quattro gruppi di dispositivi sempre aggiornati, pronti per analisi e remediation. Per iniziare, selezioniamo la nostra Baseline in Compliance Settings > Configuration Baselines. Nella parte bassa della console spostiamoci nella tab Deployments, individuiamo il deployment appena creato; quindi, facciamo clic con il tasto destro e selezioniamo Create New Collection.

A questo punto SCCM ci propone di creare una collection basata su uno dei quattro stati disponibili:

• Compliant
• Non-compliant
• Error
• Unknown

Per un monitoraggio davvero efficace, il suggerimento è creare tutte e quattro le collection, perché ognuna racconta una storia diversa:

• Compliant: dispositivi che hanno completato correttamente il requisito che abbiamo definito (nel nostro caso, UEFICA2023Status = Updated e UEFICA2023Error = 0)
• Non-compliant: dispositivi che non hanno ancora completato l’aggiornamento oppure che presentano condizioni non conformi (ad esempio status non
  Updated).
• Error: dispositivi che non riescono a eseguire la valutazione (tipicamente problemi di execution dello script, permessi, WMI/local policy, o anomalie lato client SCCM)
• Unknown: dispositivi che non hanno ancora riportato uno stato (client offline, baseline non ancora valutata, o policy non ancora ricevute)

Vediamo come creare la prima insieme. Procediamo a fare click su Compliant

Figura 49: Creazione device collection per monitoring compliance in SCCM – Parte 1

Nel wizard che si apre troverete un nome preimpostato. Sostituiamolo con un naming in linea con l’obiettivo, ad esempio “Secure Boot Compliance Baseline (Compliant devices)“. Come potete notare, la collection che stiamo creando eredita già come ambito di riferimento la device collection pilota utilizzata per il deploy della baseline. In questo modo il monitoraggio resta allineato alla wave selezionata. Proseguiamo con Next.

Figura 50: Creazione device collection per monitoring compliance in SCCM – Parte 2

Nella schermata successiva, anche la Membership rule è già precompilata. SCCM genera automaticamente una query che popola la collection in base allo stato di compliance della baseline (in questo caso Compliant) e rispetto alla collection di partenza. Non è necessario modificarla, è proprio ciò che vogliamo ottenere per costruire collection dinamiche affidabili. Qui vi suggerisco di abilitare Use incremental updates for this collection. Il motivo è che durante un rollout, lo stato dei dispositivi cambia progressivamente (da Unknown a Non-Compliant, fino a Compliant). L’incremental update permette alla collection di aggiornarsi più rapidamente tra un ciclo e l’altro, evitando di dover attendere il full evaluation e rendendo il monitoraggio molto più reattivo, soprattutto nella fase di pilot e nelle prime wave. Proseguiamo con Next.

Figura 51: Creazione device collection per monitoring compliance in SCCM – Parte 3

Nella tab Summary verifichiamo che i parametri siano corretti e continuiamo con Next.

Figura 52: Creazione device collection per monitoring compliance in SCCM – Parte 4

Al termine della procedura, facciamo click su Close.

Figura 53: Creazione device collection per monitoring compliance in SCCM – Parte 5

A questo punto ripetiamo gli stessi passaggi per creare le collection relative agli altri stati, ovvero Non-Compliant, Error e Unknown (ripetendo i passaggi da Figura 49 a Figura 53, variando solo lo stato selezionato e il naming della collection). Una volta completato, il risultato sarà un set di quattro collection di monitoraggio, sempre aggiornate e pronte per guidare le azioni operative durante il rollout.

Figura 54: Verifica device collection per monitoring compliance in SCCM

Verifiche finali

Chiudiamo il cerchio con due verifiche rapide, una lato client e una lato console SCCM, così da confermare che la Baseline è stata ricevuta, valutata e che lo stato di compliance sta alimentando correttamente le collection dinamiche. Sul client pilota, apriamo il pannello Configuration Manager (potete richiamarlo eseguendo smscfgrc.cpl oppure da Pannello di controllo > Sistema e sicurezza > Configuration Manager). Andiamo nella scheda Configurazioni, sezione relativa alle configuration baselines. Come mostrato nell’immagine seguente, il dispositivo ha già ricevuto la Configuration Baseline e risulta Compliant.

Figura 55: Valutazione compliance su dispositivo pilota

A questo punto spostiamoci sulla console di SCCM. Nella device collection di monitoraggio creata in precedenza “Secure Boot Compliance Baseline (Compliant devices)“, possiamo verificare che la collection si sia popolata correttamente. In particolare, la colonna Member Count riporta 1 dispositivo: è il nostro pc pilota, che risulta quindi incluso tra i membri. Questo conferma che lo stato di compliance restituito dal Configuration Item sta alimentando correttamente la membership della collection in modo dinamico, come previsto.

Figura 56: Incremento membri collection Compliant devices

Queste due verifiche sono importanti perché validano l’intera catena costruita fino a questo punto:

• creazione e deploy della GPO
• creazione e deploy del Configuration Item e della Configuration Baseline
• esecuzione del discovery script sul client
• valutazione della compliance e aggiornamento dinamico delle Device Collection di monitoraggio

Da qui in avanti il rollout diventa scalabile. È sufficiente estendere gradualmente la GPO e la baseline alle wave successive, continuando a utilizzare le collection per governare l’avanzamento, intercettare eventuali blocchi e pianificare le remediation prima di procedere con la wave successiva.

Checklist operativa

Prima di chiudere, facciamo di nuovo ordine con una checklist pratica al fine di ridurre i rischi e aumentare la percentuale di successo durante tutta l’attività. L’obiettivo è scegliere un metodo, validarlo su un pilota rappresentativo e poi scalare mantenendo il pieno controllo.

• Selezionate un pool di 5–10 dispositivi pilota su cui testare la soluzione scelta. Se avete più modelli hardware, diversificate. Il pilota deve essere la rappresentazione del vostro parco macchine e non composto da un solo modello
• Predisponete la soluzione (Group Policy + SCCM) e distribuitela esclusivamente al gruppo pilota, evitando fin da subito l’estensione all’intero parco macchine
• Se emergono anomalie, fermate l’estensione e risolvete prima i blocchi sul pilota. In questa fase è normale dover introdurre eccezioni temporanee, fare remediation mirate o aggiornare firmware su una parte dei modelli
• Se il pilota è stabile ma volete aumentare confidenza, estendetelo a un secondo gruppo di 5–10 dispositivi, mantenendo la stessa logica di diversificazione hardware e lo stesso modello di monitoraggio
• Quando i risultati sono ok, potete scalare alle wave successive fino a coprire tutti i dispositivi in produzione, continuando a monitorare con SCCM e intervenendo in modo mirato dove necessario

Ma soprattutto, analizzate i risultati e, come visto nella sezione Troubleshooting dell’articolo precedente, ponetevi le domande giuste: il Secure Boot è effettivamente attivo su tutti i device? Su alcuni modelli è necessario aggiornare il firmware prima di proseguire? Ci sono errori persistenti o variabili UEFI (KEK/DB/DBX) non aggiornabili che richiedono coinvolgimento dell’OEM? Il processo segue il flusso atteso dall’inizio alla fine, inclusi eventuali riavvii necessari? Con questi step evitate l’errore classico di trasformare un’attività delicata in una distribuzione massiva senza telemetria e senza margine di controllo.

Conclusioni

In questa guida abbiamo visto come utilizzare le GPO per avviare e controllare il rollout e come affiancare SCCM per trasformare lo stato dei client in compliance misurabile, collection dinamiche e azioni operative. Il valore non è solo far partire l’update, ma sapere in ogni momento quali dispositivi hanno completato il passaggio alla chain 2023, quali sono fermi e quali richiedono remediation prima di estendere la wave successiva. La chiave, alla fine, è sempre la stessa. Scegliere un metodo, validarlo con un pilot rappresentativo e poi scalare senza perdere controllo. Perché quando parliamo di Secure Boot, non stiamo aggiornando un componente, stiamo aggiornando le fondamenta.