1 09/05/2026 9 min

Installare i modelli amministrativi di Microsoft Office senza sporcare il dominio

Se devi governare policy di Office in un ambiente Windows con Active Directory, la strada giusta non è copiare file a caso su una macchina d’amministrazione e sperare che la console li veda. La gestione corretta passa dai modelli amministrativi ADMX e ADML, idealmente pubblicati nel Central Store del dominio. Così eviti versioni incoerenti tra postazioni, riduci gli errori di lingua e rendi le Group Policy leggibili da tutto il team.

Il punto pratico è semplice: i template di Office servono a esporre nelle GPO tutte le impostazioni amministrative di Word, Excel, Outlook, PowerPoint e degli altri componenti supportati. Senza questi file la console mostra solo un sottoinsieme di policy generiche; con i template corretti puoi gestire aggiornamenti, privacy, macro, componenti cloud, salvataggio, OneDrive, roaming, add-in e un lungo elenco di comportamenti che in produzione fanno la differenza.

Che cosa stai installando davvero

Microsoft distribuisce i modelli amministrativi di Office come pacchetto separato rispetto all’installazione del client. Dentro trovi file .admx e cartelle lingua .adml. Gli ADMX contengono la definizione delle policy, gli ADML le stringhe localizzate che la console usa per mostrare nomi e descrizioni nella lingua corretta.

Il rischio classico è mescolare versioni diverse: ad esempio template di Office 2016 con client Microsoft 365 Apps, oppure ADMX aggiornati ma ADML mancanti o della lingua sbagliata. Il risultato non è sempre un errore evidente; spesso la console apre la GPO ma alcune voci spariscono, compaiono messaggi di “resource not found” o il nodo Office resta parzialmente vuoto.

Dove vanno messi: locale o Central Store

Su una singola workstation di amministrazione puoi anche usare il percorso locale del profilo amministrativo, ma in un dominio serio conviene quasi sempre il Central Store. Il vantaggio è banale ma decisivo: ogni amministratore vede le stesse policy, senza dipendere dalla versione di Windows o dalla cartella locale del proprio PC.

Il Central Store vive in \<dominio>\SYSVOL\<dominio>\Policies\PolicyDefinitions. Dentro ci metti i file .admx e la sottocartella della lingua, per esempio it-IT o en-US, con i corrispondenti .adml. Se il dominio ha operatori in più lingue, la pratica più robusta è mantenere almeno la lingua principale e quella standard di fallback, di solito inglese.

Prerequisiti che evitano il 90% dei problemi

Prima di toccare la GPO, verifica questi punti. Non sono formalità: sono i guasti più frequenti quando l’installazione “sembra fatta” ma poi la console non mostra i template di Office.

  1. Hai privilegi di scrittura sul Central Store o sul percorso locale scelto.
  2. Stai usando il pacchetto ADMX della stessa famiglia di Office che vuoi governare.
  3. Hai la lingua corretta per gli ADML, almeno per il nodo che userai nella console.
  4. La replica SYSVOL è sana, se lavori direttamente nel dominio.
  5. La console GPMC è chiusa e riaperta dopo il cambio dei template.

Se anche uno solo di questi elementi manca, la fase di verifica diventa ambigua. In particolare la replica SYSVOL merita attenzione: copiare i file nel Central Store su un DC non basta se gli altri controller non hanno ancora ricevuto la sincronizzazione.

Procedura consigliata: Central Store sul dominio

Questa è la strada da usare quasi sempre in ambienti con più amministratori. Il principio è: backup del materiale esistente, copia dei template, verifica della lingua, riapertura della console e test su una GPO di laboratorio o su una policy di scope limitato.

  1. Scarica il pacchetto ufficiale dei modelli amministrativi di Microsoft Office corrispondente alla tua versione.
  2. Estrai l’archivio in una cartella temporanea su una macchina amministrativa.
  3. Individua i file .admx e la cartella lingua, per esempio it-IT o en-US.
  4. Se il Central Store non esiste, crealo nel percorso \<dominio>\SYSVOL\<dominio>\Policies\PolicyDefinitions.
  5. Copia i file .admx nella radice di PolicyDefinitions.
  6. Copia la cartella della lingua dentro PolicyDefinitions, mantenendo il nome identico alla lingua contenuta nel pacchetto.
  7. Chiudi e riapri Group Policy Management Editor per forzare il ricaricamento dei template.

Un esempio operativo da shell, utile quando prepari il materiale prima della copia nel dominio, è questo:

mkdir C:\Temp\OfficeADMX
Expand-Archive -Path C:\Temp\OfficePolicies.zip -DestinationPath C:\Temp\OfficeADMX

Se lavori da PowerShell e vuoi fare una copia controllata verso un percorso locale di staging, tieni separati i file principali dalla lingua. Non mischiare tutto nella stessa cartella, perché poi la console non riesce a risolvere le risorse localizzate.

Struttura corretta del Central Store

La struttura attesa è lineare. Nella radice del Central Store ci sono gli ADMX; nelle sottocartelle lingua gli ADML. Un errore comune è creare una cartella in più o rinominare la lingua in modo creativo: la console non apprezza l’inventiva.

\domain.local\SYSVOL\domain.local\Policies\PolicyDefinitions\
  ├── office16.admx
  ├── excel16.admx
  ├── outlook16.admx
  ├── ...
  └── it-IT\
      ├── office16.adml
      ├── excel16.adml
      ├── outlook16.adml
      └── ...

Se la tua console è in inglese ma il dominio ha template in italiano, puoi comunque lavorare, purché la cartella lingua esista e contenga i file coerenti. Quando manca la lingua attesa, la GPMC spesso mostra i nodi ma con descrizioni mancanti o traduzioni parziali.

Verifica rapida lato amministratore

Dopo la copia, non dare per scontato che sia tutto a posto. La verifica minima deve confermare tre cose: presenza dei file, lettura dalla console, visibilità delle policy di Office. Qui conviene essere metodici perché gli errori di template spesso sembrano problemi di permessi o di replica, ma in realtà sono mismatch di versione.

  1. Apri la GPMC e modifica una GPO di test.
  2. Controlla se compare il ramo relativo a Microsoft Office o al prodotto specifico.
  3. Espandi almeno una policy nota, per esempio una voce di privacy o aggiornamento, e verifica che il testo sia leggibile.
  4. Se una voce manca, controlla che il file .adml della lingua sia presente nel percorso corretto.

Per un controllo esterno al dominio puoi usare anche una semplice verifica del percorso, utile quando sospetti che il problema sia la replica o la copia incompleta:

dir \\domain.local\SYSVOL\domain.local\Policies\PolicyDefinitions\*.admx
 dir \\domain.local\SYSVOL\domain.local\Policies\PolicyDefinitions\it-IT\*.adml

Se uno dei due elenchi è vuoto, non andare oltre: prima chiudi il gap sul filesystem o sulla replica. La console non può inventarsi file che non esistono.

Installazione locale: quando ha ancora senso

La copia locale dei template ha senso solo in casi limitati: workstation standalone, laboratorio, test rapido o ambienti senza un dominio AD. In questo scenario i file vanno nel repository locale dei modelli amministrativi della macchina amministrativa, ma il vantaggio operazionale è inferiore rispetto al Central Store.

Il punto critico è che il repository locale segue il sistema operativo dell’host, non il dominio. Se un collega apre la stessa GPO da un altro PC, potrebbe vedere template diversi. Per questo, appena il contesto supera il singolo admin, la soluzione locale diventa un debito tecnico.

Problemi tipici e come leggerli senza perdere tempo

Quando qualcosa non torna, conviene partire dal sintomo e non dalla teoria. La console è vuota? Il problema è quasi sempre path, lingua o versione. Le policy ci sono ma non si applicano ai client? Allora il problema si sposta su link della GPO, filtri di sicurezza, scope, o lato client con aggiornamento policy non avvenuto.

  1. Template non visibili in editor: controlla Central Store, lingua e riapertura della console.
  2. Policy visibile ma non applicata: verifica gpresult /h sul client e l’effettivo scope della GPO.
  3. Messaggi di risorsa mancante: quasi sempre ADML sbagliato o cartella lingua errata.
  4. Conflitto tra versioni Office: stai usando template di una release diversa da quella installata o gestita.

Un comando utile lato client, per capire se la GPO sta arrivando davvero, è questo:

gpresult /h C:\Temp\gpresult-office.html

Aprendo il report puoi vedere se la GPO è applicata, se è stata filtrata, e se il computer o l’utente rientrano davvero nel perimetro previsto. È un controllo più utile di molte supposizioni fatte a occhio dentro l’editor.

Un approccio più pulito: laboratorio, poi produzione

Se il dominio è grande, non copiare i template direttamente nel Central Store produttivo senza una prova. La pratica più sicura è preparare un ambiente di staging o una GPO di test, validare la visibilità delle policy, controllare che i nomi siano coerenti e solo dopo promuovere il materiale nel dominio principale.

Questo approccio riduce il blast radius: se un ADMX incompatibile rompe la lettura della console, il danno resta confinato alla macchina di test o alla GPO di laboratorio. Il rollback è banale: rimuovi i file introdotti, ripristina il set precedente e riapri l’editor. Se lavori sul Central Store, mantieni sempre una copia versionata della directory PolicyDefinitions prima di sostituire il contenuto.

Policy Office che vale la pena conoscere subito

Non tutte le impostazioni hanno lo stesso peso. In molti ambienti le prime policy da governare sono quelle che impattano sicurezza e supporto: macro, aggiornamenti, telemetria, componenti cloud e percorso di salvataggio. Se parti da questi punti, ottieni un beneficio immediato e misurabile.

  1. Macro: riduci l’esecuzione di contenuti non firmati o non attendibili.
  2. Aggiornamenti: allinea il canale e la finestra di update al tuo change management.
  3. Privacy e diagnosi: definisci cosa è ammesso inviare fuori dal perimetro.
  4. Componenti cloud: decidi in modo esplicito se e come abilitare integrazioni esterne.
  5. Path di salvataggio: evita comportamenti divergenti tra reparti e profili utente.

La logica è quella di sempre: meno eccezioni locali, più coerenza centralizzata. Office è spesso trattato come applicazione “da ufficio”, ma in realtà è uno dei client più sensibili a policy, versioni e integrazioni esterne. Proprio per questo vale la pena governarlo con template ben installati e verificati.

Checklist finale operativa

Se vuoi chiudere il lavoro senza lasciare punti fragili, la checklist minima è questa: i file ADMX sono nella radice del Central Store, gli ADML sono nella sottocartella lingua giusta, la GPMC è stata riaperta, una GPO di test vede i nodi di Office, e un client di prova riceve la policy attesa. Se uno di questi elementi fallisce, non considerare l’installazione conclusa.

In pratica, l’obiettivo non è “vedere i template”, ma poterli usare in modo ripetibile da qualunque amministratore del dominio. Se il tuo setup rispetta questo criterio, hai installato i modelli amministrativi di Microsoft Office nel modo giusto: pulito, verificabile e sostenibile nel tempo.