Scaricare e installare i modelli ADMX di Windows 11 23H2

Perché i modelli ADMX contano davvero in un ambiente Windows

I file ADMX non servono a “far funzionare” le policy: servono a mostrare e interpretare correttamente le impostazioni dei Criteri di gruppo nell’Editor. Se hai workstation, server o un dominio Active Directory, i modelli ADMX sono il pezzo che traduce le nuove opzioni introdotte da Microsoft in voci leggibili e modificabili dentro gpedit.msc o gpmc.msc.

Con Windows 11 23H2 il punto non è solo aggiornare qualche file. Il nodo vero è evitare due problemi tipici: vedere impostazioni mancanti perché i modelli sono vecchi, oppure creare confusione tra versioni diverse degli ADMX installate su PC amministrativi diversi. In pratica, se il parco macchine è eterogeneo, i modelli diventano una dipendenza operativa, non un dettaglio.

La scelta corretta è semplice: scaricare i modelli ADMX della versione desiderata, estrarre solo i file utili e distribuirli in modo controllato, preferibilmente in un Central Store del dominio. Se non c’è dominio, puoi usarli localmente sul PC di amministrazione, ma il rischio di disallineamento cresce subito.

Scarico corretto: dove prendere i modelli e cosa aspettarsi

Microsoft distribuisce i modelli amministrativi come pacchetto separato. Il contenuto include file .admx e cartelle lingua con file .adml. Per Windows 11 23H2 il pacchetto va cercato nella documentazione ufficiale Microsoft relativa ai Administrative Templates (.admx) for Windows 11 2023 Update / 23H2. Il punto pratico è che il download non è un installer tradizionale: normalmente ottieni un archivio compresso o un file eseguibile che estrae il materiale.

Il controllo minimo da fare subito dopo il download è questo: verificare che il pacchetto contenga i file attesi per la lingua corretta. Per un ambiente italiano, il sottoinsieme importante è la cartella it-IT o la lingua che usi davvero sul sistema di amministrazione. Se il file lingua non coincide, l’Editor criteri continuerà a funzionare, ma molte descrizioni appariranno in inglese o, peggio, con voci non localizzate.

Se sei in un ambiente multilingua, la lingua dell’ADML deve seguire la lingua dell’Editor che usi davvero. Non c’è alcun vantaggio a copiare tutte le lingue disponibili: aumenti solo la superficie di manutenzione.

Architettura consigliata: Central Store prima del copia-incolla sul singolo PC

In un dominio Active Directory il posto giusto per i modelli è il Central Store, cioè la cartella PolicyDefinitions nel percorso SYSVOL del dominio. Questo evita che ogni amministratore lavori con una sua copia locale dei template, con il classico risultato di vedere policy diverse a seconda della postazione usata.

Il vantaggio operativo è concreto: quando aggiorni gli ADMX, tutti gli strumenti di gestione dei criteri leggono la stessa versione. È una forma banale ma efficace di controllo configurazione. In più, riduci gli errori di interpretazione quando una policy nuova esiste solo in 23H2 e non in release precedenti.

Se non hai un dominio, puoi installare i modelli in locale sotto C:\\Windows\PolicyDefinitions. Funziona, ma va trattato come una soluzione di emergenza o per laboratori. In produzione, soprattutto se più persone amministrano la stessa infrastruttura, il Central Store è la scelta più pulita.

Struttura dei file: cosa va copiato e cosa no

Il pacchetto ADMX contiene due elementi distinti:

• i file .admx, che definiscono le policy;
• i file .adml, che forniscono i testi localizzati e le descrizioni.

La regola pratica è: i file .admx vanno nella radice di PolicyDefinitions, mentre i file .adml vanno nella sottocartella della lingua, per esempio it-IT o en-US. Se scambi i due livelli, l’Editor non li interpreta correttamente.

Un errore frequente è copiare l’intero contenuto dell’archivio senza filtrare. Non sempre è dannoso, ma spesso porta dentro template non necessari o duplicati di versioni precedenti. Meglio copiare solo ciò che serve e tenere traccia della versione installata. In ambienti gestiti bene, la cartella PolicyDefinitions dovrebbe avere una provenienza chiara, con una nota interna o un changelog minimo.

Procedura operativa su dominio: aggiornare il Central Store

Se hai un dominio, la sequenza corretta è questa: prepari il pacchetto, fai un backup del Central Store esistente, copi i nuovi template, poi apri l’editor per verificare che le nuove voci siano visibili. Il backup non è facoltativo: un upgrade ADMX sbagliato può rompere la visualizzazione di policy già usate.

Il percorso tipico del Central Store è simile a questo:

\<dominio>\SYSVOL\<dominio>\Policies\PolicyDefinitions

Prima di toccare nulla, controlla la presenza della cartella e la versione corrente. Se lavori su un controller di dominio, ricordati che SYSVOL replica: la modifica deve essere coerente con la replica AD, altrimenti potresti vedere comportamenti diversi tra DC.

Una sequenza prudente è:

1. copiare l’intera cartella PolicyDefinitions in un backup con data;
2. estrarre il pacchetto ADMX di Windows 11 23H2 in una directory temporanea;
3. copiare i nuovi .admx nella radice del Central Store;
4. copiare i file lingua nella cartella corretta, per esempio it-IT;
5. aprire gpmc.msc o gpedit.msc e verificare la disponibilità delle nuove policy.

Se una policy nuova non compare, il problema di solito è uno di questi: file copiati nel posto sbagliato, lingua errata, replica SYSVOL non ancora allineata, oppure editor aperto su una macchina che sta ancora leggendo una cache locale.

Procedura su singolo PC: quando il Central Store non c’è

Su una postazione amministrativa standalone, il percorso è più semplice ma meno robusto. Copi i file nella cartella locale dei modelli amministrativi e poi riapri l’Editor Criteri. Il percorso classico è C:\\Windows\PolicyDefinitions. Anche qui il principio è identico: .admx nella radice, .adml nella sottocartella della lingua.

Questa opzione ha senso per test, laboratori o situazioni temporanee. Se il PC è usato da più operatori, conviene documentare chiaramente la versione installata, perché due amministratori possono vedere set di policy diversi in base a cosa hanno copiato localmente. È una delle cause più fastidiose di troubleshooting “fantasma”: la policy esiste, ma non su quella macchina.

Per ridurre gli errori, dopo la copia chiudi e riapri l’Editor. In alcuni casi conviene fare logoff o riavvio della console amministrativa, non dell’intero sistema. Il punto è forzare il ricaricamento dei template.

Verifiche rapide dopo l’installazione

La verifica non deve essere “se apre l’editor allora è tutto a posto”. Devi controllare tre cose: presenza dei file, visibilità delle nuove policy e assenza di errori di parsing.

Una verifica pratica su filesystem è questa:

dir C:\\Windows\PolicyDefinitions
dir C:\\Windows\PolicyDefinitions\it-IT

Nel Central Store, il controllo equivalente è il listing della directory di rete. Se i file ci sono ma l’Editor non li mostra, il passo successivo è verificare la corrispondenza tra lingua e file .adml. Se l’Editor è in italiano e hai solo en-US, vedrai descrizioni non localizzate o mancanti.

Un altro controllo utile è aprire una policy nota introdotta o aggiornata in 23H2 e vedere se i dettagli sono presenti. Se hai già una baseline, il confronto è immediato: policy nuova visibile = template corretti; policy assente = problema di installazione o di versione.

Problemi tipici che non vanno ignorati

Il primo problema è il mismatch di versione. Se nel Central Store hai template di release diverse mescolati senza criterio, alcune impostazioni possono sovrascriversi o sparire. Non è sempre un crash esplicito: spesso è più subdolo, perché l’editor mostra comunque qualcosa, ma non necessariamente la versione giusta.

Il secondo problema è la lingua. La cartella it-IT con file mancanti o presi da un pacchetto diverso produce descrizioni incoerenti. In quel caso conviene riallineare tutto, non patchare singoli file a mano.

Il terzo problema è la replica del dominio. Se aggiorni il Central Store su un solo DC e poi verifichi da una postazione che legge un altro DC, potresti interpretare come errore un semplice ritardo di replica. Prima di cambiare altro, controlla lo stato della replica e il percorso SYSVOL effettivamente usato.

Comandi e controlli utili senza fare danni

Per capire cosa hai scaricato e dove l’hai estratto, puoi usare controlli banali ma efficaci:

dir /s /b *.admx

dir /s /b *.adml

Se lavori da PowerShell, puoi fare un controllo più leggibile:

Get-ChildItem -Path C:\Temp\ADMX_23H2 -Recurse -Include *.admx,*.adml | Select-Object FullName

Per confrontare prima e dopo, conserva l’hash dei file principali o almeno una lista dei nomi. Non serve una piattaforma di change management complessa per evitare errori grossolani: basta sapere quali file sono entrati nel repository dei template.

Se vuoi essere più rigoroso, archivia il pacchetto originale in una cartella con data e mantieni la copia precedente del Central Store. In caso di regressione, il rollback è semplice: ripristini la cartella precedente e riapri la console di gestione.

Rollback: come tornare indietro senza improvvisare

Il rollback corretto non è “cancello e vedo cosa succede”. Se hai sostituito i template in produzione, il ripristino deve essere una copia della cartella precedente, non una ricostruzione manuale. Questo vale ancora di più se il dominio è usato da più team.

La sequenza prudente è:

1. chiudere le console di gestione dei criteri;
2. ripristinare la cartella PolicyDefinitions dal backup;
3. verificare che i file .admx e .adml tornino alla versione precedente;
4. riaprire gpmc.msc o gpedit.msc e controllare che le policy tornino leggibili.

Se il problema era solo locale sul PC admin, basta ripristinare i file da backup nella cartella C:\\Windows\PolicyDefinitions. Anche qui, il punto non è “far sparire l’errore”, ma riportare l’ambiente a uno stato coerente e documentabile.

Quando conviene aggiornare anche se “funziona già”

Conviene farlo quando introdurrai policy nuove, quando stai standardizzando un dominio o quando vuoi evitare che la postazione di chi amministra diventi il vero collo di bottiglia. I template non aggiornati non rompono sempre qualcosa nell’immediato, ma ti tolgono visibilità. E in amministrazione Windows la visibilità vale più della comodità.

Se stai preparando un cambio controllato, il criterio pratico è questo: aggiornare i template prima di creare o modificare GPO che dipendono da opzioni introdotte in 23H2. Così eviti di dover tornare indietro perché l’editor non mostra la voce giusta o la mostra con una descrizione incompleta.

Il vantaggio reale non è estetico. È ridurre gli errori operativi, allineare gli strumenti di amministrazione e rendere ripetibile la configurazione. Se hai un team, questo è ancora più importante: i template sono parte della baseline amministrativa, non un accessorio del desktop dell’admin di turno.

Checklist finale da usare prima di chiudere il cambio

• Il pacchetto ADMX è quello di Windows 11 23H2 e non una versione precedente.
• I file .admx sono nella radice di PolicyDefinitions.
• I file .adml sono nella cartella lingua corretta.
• Il Central Store, se presente, è stato aggiornato con backup precedente disponibile.
• Le nuove policy sono visibili nell’Editor Criteri dopo riapertura della console.

Assunzione: ambiente Windows recente con gestione locale o dominio Active Directory, lingua italiana come caso più probabile, e necessità di mantenere un rollback semplice e verificabile.

Nota operativa: se non sai da quale versione partono i template installati oggi, il primo passo non è copiare file nuovi a caso. È identificare la baseline attuale e confrontarla con il pacchetto 23H2 prima di sostituire qualcosa.