Windows 11 23H2: nuove impostazioni dei Criteri di gruppo

Le novità dei Criteri di gruppo in Windows 11 23H2 contano soprattutto dove serve controllo

Con Windows 11 23H2 il punto non è tanto la presenza di “nuovi menu”, quanto il fatto che Microsoft continua a spostare la gestione del client verso un modello più coerente con ambienti ibridi, sicurezza centralizzata e policy più granulari. Per chi amministra postazioni in dominio, il vero valore sta nel capire quali impostazioni sono state aggiunte, quali hanno cambiato comportamento e quali richiedono i file ADMX aggiornati prima di essere viste correttamente nell’Editor Criteri di gruppo.

In pratica: se il parco macchine è già governato con GPO, 23H2 non va letto come un semplice feature update. Va letto come un aggiornamento che può introdurre nuove leve operative ma anche differenze tra ciò che vedi nel server di amministrazione e ciò che il client applica davvero. È qui che si fanno gli errori più comuni: si cerca la policy nel posto sbagliato, si applica su un controller non aggiornato, oppure si confonde una preferenza di Interfaccia con un criterio effettivamente enforced.

Prima verifica: i template ADMX e il punto in cui li stai leggendo

La prima cosa da controllare, prima ancora di discutere le singole impostazioni, è il repository centralizzato dei template amministrativi. Se usi il Central Store, i file devono essere coerenti con la build del sistema che stai amministrando. Altrimenti l’Editor mostra meno voci del previsto o, peggio, una struttura incompleta che fa pensare a una mancanza di funzione quando in realtà manca solo il template.

Il controllo minimo è questo:

dir \<dominio>
sysvol\<dominio>\Policies\PolicyDefinitions

Se il percorso esiste ma i file ADMX/ADML non sono allineati a 23H2, la verifica non si fa “a occhio”. Si confrontano le versioni dei file con quelli presenti su un host Windows 11 23H2 aggiornato. Se invece non usi il Central Store, l’Editor legge i template locali della macchina da cui apri la console; in quel caso il rischio è ancora più banale: stai amministrando i client con un set di policy vecchio senza accorgertene.

Un controllo rapido lato console è aprire l’Editor Criteri di gruppo e cercare la voce nel ramo corretto, poi verificare se il nodo compare anche su una macchina aggiornata. Se la policy c’è solo sul client ma non sull’RSAT o sul server di amministrazione, il problema è quasi sempre nei template, non nel sistema operativo target.

Le aree che cambiano davvero: sicurezza, esperienza utente e gestione del dispositivo

Le nuove impostazioni introdotte o rese più rilevanti in 23H2 si concentrano in tre direzioni: riduzione della superficie d’attacco, più controllo sull’esperienza utente e maggiore integrazione con scenari gestiti. Per un sysadmin, il punto non è memorizzare il nome esatto di ogni voce, ma capire a quale problema operativo risponde.

1. Sicurezza del client. Qui rientrano criteri che rafforzano protezioni già presenti, limitano comportamenti rischiosi o rendono più stringente la configurazione di componenti come Defender, SmartScreen, accesso a contenuti e hardening dell’account. In ambienti con elevata esposizione a phishing o software non autorizzato, queste policy servono a togliere ambiguità: o il comportamento è consentito, o è bloccato.

2. Controllo dell’esperienza. Alcune impostazioni hanno l’obiettivo di standardizzare l’interfaccia, ridurre distrazioni, limitare funzioni consumer o impedire che l’utente cambi parametri non coerenti con il profilo aziendale. Questo è particolarmente utile nelle postazioni condivise o nei reparti dove la postazione è uno strumento di lavoro, non un endpoint “libero”.

3. Gestione e provisioning. 23H2 continua a convivere con un mondo in cui Group Policy, MDM e Intune si sovrappongono. Le nuove o aggiornate impostazioni spesso non servono a sostituire l’MDM, ma a colmare il gap tra ambienti tradizionali e modern management. Se hai device joined in modalità mista, il vero lavoro è evitare conflitti di autorità tra criteri locali, GPO di dominio e policy cloud.

Il problema tipico: la policy esiste ma non la vedi, o la vedi ma non si applica

Questo è il caso che genera più ticket interni. La sequenza è quasi sempre la stessa: l’amministratore legge una nota di rilascio, cerca la voce nell’Editor, non la trova, aggiorna i client, poi scopre che il template era vecchio. Oppure la policy è visibile, ma il comportamento non cambia perché il filtro di sicurezza, il loopback, l’ereditarietà o il precedence order stanno intervenendo prima della GPO che pensavi fosse “decisiva”.

Le verifiche minime sono tre:

1. Controlla l’effettiva presenza della GPO applicata sul client con gpresult /h oppure rsop.msc.
2. Verifica il log Event Viewer > Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational per errori di elaborazione o filtri negati.
3. Confronta il valore atteso nei registri di policy con il comportamento osservato nel sistema, ad esempio sotto HKLM\Software\Policies o HKCU\Software\Policies quando la policy scrive lì.

Se la policy non compare in gpresult, il problema non è il client 23H2 ma la distribuzione della GPO, il filtro di sicurezza o il link alla OU. Se compare ma non ha effetto, allora devi guardare precedenza, conflitti e riapplicazione.

Nuove impostazioni e policy già esistenti: il punto è la semantica

Una trappola frequente con le versioni di Windows è pensare che una voce “nuova” significhi per forza una funzione completamente nuova. Più spesso si tratta di una policy già nota che in 23H2 viene esposta meglio, spostata di categoria o resa più utile in combinazione con altre impostazioni. Per questo conviene leggere le policy per obiettivo operativo, non per nome.

Per esempio, una policy legata alla sicurezza del browser o alla protezione dalle app potenzialmente indesiderate vale molto di più se è accompagnata da criteri coerenti su SmartScreen, reputazione dei file e restrizioni di esecuzione. Al contrario, una singola impostazione isolata crea spesso solo un falso senso di controllo.

Lo stesso vale per l’area UX. Se vuoi una postazione standardizzata, non basta nascondere un pannello o bloccare una voce del menu Start. Serve una catena coerente: limitazione delle impostazioni, configurazione del desktop, eventuale shell launcher o restrizioni per l’account, e soprattutto una strategia chiara su cosa deve poter fare l’utente quando qualcosa non funziona. Le policy efficaci sono quelle che riducono la possibilità di deviazione senza trasformare il supporto in un percorso a ostacoli.

GPO e Intune insieme: il punto di attrito da governare

Windows 11 23H2 vive in un ecosistema in cui molte aziende non sono più “solo dominio” e non sono ancora “solo cloud”. Questo crea il classico scenario ibrido: alcune impostazioni arrivano da GPO, altre da profili MDM, altre ancora da script o remediation. Il risultato, se non si governa, è una macchina che sembra configurata ma in realtà è in conflitto.

Il consiglio operativo è semplice: per ogni area funzionale, scegli una fonte di verità. Se una famiglia di impostazioni è gestita da GPO, evita che Intune la riscriva senza una ragione precisa. Se invece il device è cloud-first, limita la GPO alle eccezioni necessarie. Il criterio vero non è “quale strumento preferisco”, ma “quale strumento è autoritativo per quel parametro”.

Per capire dove nasce il conflitto, controlla il registro di policy e la presenza di impostazioni duplicate. Un modo pratico è verificare il valore effettivo nel sistema e risalire alla sorgente tramite gpresult o report MDM. Se un parametro viene scritto due volte con logiche diverse, il comportamento finale dipende dall’ordine di applicazione e non dal tuo intento progettuale.

Un metodo di lettura utile: policy per impatto, non per catalogo

Se devi valutare le novità di 23H2 in un ambiente reale, evita il catalogo sterile delle voci. Ragiona invece per impatto:

• Riduce rischio? Allora è candidata per baseline di sicurezza.
• Riduce variabilità operativa? Allora è utile nei profili standardizzati.
• Interferisce con supporto o produttività? Allora va testata su un gruppo pilota prima della diffusione.
• Ha dipendenze da versione o template? Allora serve allineamento preventivo dei file ADMX e dei client di amministrazione.

Questo approccio evita di distribuire policy “perché ci sono”. In ambienti grandi, ogni voce in più ha un costo: troubleshooting più lento, documentazione da aggiornare, rischio di conflitto con baseline esistenti. Una policy che non risponde a un requisito concreto è rumore amministrativo.

Verifica pratica in laboratorio prima del rollout

Il modo corretto per introdurre nuove impostazioni è sempre lo stesso: anello piccolo, osservazione, poi estensione. Il laboratorio non deve essere una VM generica “che tanto poi vediamo”; deve assomigliare quanto basta al target reale per riprodurre ereditarietà, OU, filtri di sicurezza e versione di build.

Sequenza minima consigliata:

1. Aggiorna i template ADMX nel Central Store o sulla console di amministrazione.
2. Crea o duplica una GPO di test con nome esplicito, ad esempio W11-23H2-Pilot.
3. Collega la GPO a una OU di prova con pochi device rappresentativi.
4. Forza l’aggiornamento con gpupdate /force e raccogli il report con gpresult /h C:\Temp\gp.html.
5. Controlla il comportamento applicativo e i log di sistema prima di allargare il link.

Se la policy tocca sicurezza o accesso a funzionalità, aggiungi un test d’uso reale: login, apertura di un’app critica, accesso a risorse di rete, navigazione, stampa, sessione remota. Molti problemi non emergono finché non si passa dal “la policy è impostata” al “l’utente riesce a lavorare”.

Come evitare di rompere il supporto quando stringi troppo

Ogni volta che si irrigidisce una configurazione, bisogna chiedersi cosa succede quando qualcosa va storto. Se blocchi un pannello, l’help desk deve avere una strada alternativa per intervenire. Se disabiliti una funzione utente, devi sapere quale log o quale chiave ti permette di capire se il comportamento è normale o se è un effetto collaterale.

Qui entrano in gioco tre regole semplici:

• Documenta il motivo della policy, non solo il suo nome.
• Associa ogni restrizione a un canale di eccezione o di supporto.
• Verifica che il rollback sia possibile senza interventi manuali su ogni singola macchina.

Se una GPO deve essere rimossa, il rollback corretto non è “speriamo di ricordarcene”. È avere un link separato, una OU di pilot, oppure almeno una copia versionata della configurazione esportata. In caso di emergenza, poter disabilitare il link o impostare la GPO su Not Configured è molto meglio che rincorrere modifiche sparse.

La lettura giusta di Windows 11 23H2 per chi amministra davvero

Il valore di 23H2, dal punto di vista dei Criteri di gruppo, sta nel rafforzare una gestione più precisa del client moderno. Per chi gestisce ambienti Windows in modo serio, l’aggiornamento non è interessante perché “ci sono più opzioni”, ma perché permette di riallineare sicurezza, controllo e standardizzazione con meno compromessi rispetto alle versioni precedenti.

La regola resta la stessa di sempre: prima osserva, poi applica. Prima verifica i template, poi la presenza della policy, poi l’effetto reale sul client. E se una nuova impostazione sembra fare al caso tuo, trattala come un cambiamento di configurazione a tutti gli effetti: test, impatto, rollback, documentazione.

In un ambiente ben gestito, una policy nuova non è una novità da esibire. È solo un altro strumento da mettere al posto giusto, con il minimo rumore possibile e con una prova chiara del fatto che stia davvero facendo quello che promette.

Assunzione operativa: il lettore sta gestendo endpoint Windows in dominio o in ambiente ibrido, con necessità di verificare visibilità, applicazione e rollback delle policy prima di un rollout esteso.