Windows 10 Group Policy ADMX Templates

Windows 10 Logo
Windows 10 Logo

Estimated reading time: 5 minutes

Overview

Administrative Templates files are divided into .admx files and language-specific .adml files for use by Group Policy administrators. The changes that are implemented in these files let administrators configure the same set of policies by using two languages. Administrators can configure policies by using the language-specific .adml files and the language-neutral .admx files.

Administrative Templates file storage

Windows uses a Central Store to store Administrative Templates files. The ADM folder is not created in a Group Policy Object (GPO) as it is in earlier versions of Windows. Therefore, Windows domain controllers do not store or replicate redundant copies of .adm files.

Note: If you use a client that is running an earlier version of Windows to change a policy that is created or administered on a Windows 8.1-based or a Windows 10-based computer, the client creates the ADM folder and replicates the files.

For more information, click the following article number to go to the article in the Microsoft Knowledge Base:
816662 Recommendations for managing Group Policy Administrative Template (.adm) files

The Central Store

To take advantage of the benefits of .admx files, you must create a Central Store in the SYSVOL folder on a Windows domain controller. The Central Store is a file location that is checked by the Group Policy tools. The Group Policy tools use any .admx files that are in the Central Store. The files that are in the Central Store are later replicated to all domain controllers in the domain.

To create a Central Store for .admx and .adml files, create a folder that is named PolicyDefinitions in the following location (for example) on the domain controller:

contoso.comSYSVOLcontoso.compolicies

Copy all files from the PolicyDefinitions folder on a source computer to the PolicyDefinitions folder on the domain controller. The source location can be either of the following:

  • The C:Windows folder on a Windows 8.1-based or Windows 10-based client computer
  • The C:Program Files (x86)Microsoft Group Policyclient folder if you have downloaded any of the Administrative Templates separately

The PolicyDefinitions folder on the Windows domain controller stores all .admx files and .adml files for all languages that are enabled on the client computer.

The .adml files are stored in a language-specific folder. For example, English (United States) .adml files are stored in a folder that is named “en-US”; Korean .adml files are stored in a folder that is named “ko_KR”; and so on.

If .adml files for additional languages are required, you must copy the folder that contains the .adml files for that language to the Central Store. When you have copied all .admx and .adml files, the PolicyDefinitions folder on the domain controller should contain the .admx files and one or more folders that contain language-specific .adml files.

Note: When you copy the .admx and .adml files from a Windows 8.1-based or Windows 10-based computer, verify that the most recent updates to these files are installed. Also, make sure that the most recent Administrative Templates files are replicated. This advice also applies to service packs, as applicable.

Group Policy administration

Windows 8.1 and Windows 10 do not include Administrative Templates that have an .adm extension. We recommend that you use computers that are running Windows 8.1 or later versions of Windows to perform Group Policy administration.

Updating the Administrative Templates files

In Group Policy for versions of Windows that are earlier than Windows Vista, if you change Administrative Templates policy settings on local computers, the Sysvol share on a domain controller within your domain is automatically updated to include the new .ADM files. Those changes are then replicated to all other domain controllers in the domain. This might increase the network load and storage requirements.

In Group Policy for Windows Server 2012 R2 and Windows 8.1, if you change Administrative Templates policy settings on local computers, Sysvol is not automatically updated to include the new .admx or .adml files. This change in behavior is implemented to reduce network load and disk storage requirements and to prevent conflicts between .admx and .adml files when changes are made to Administrative Templates policy settings across different locations.

To make sure that any local updates are reflected in Sysvol, you must manually copy the updated .admx or .adml files from the PolicyDefinitions file on the local computer to the SysvolPolicyDefinitions folder on the appropriate domain controller.

The following update enables you to configure the Local Group Policy editor to use Local .admx files instead of the Central Store:
2917033 An update is available to enable the use of Local ADMX files for Group Policy Editor

Known Issues

After you copy the Windows 10 .admx templates to the SYSVOL Central Store and overwrite all existing *.admx and *.adml files, click the Policies node under Computer Configuration or User Configuration. When you do this, you may receive the following error message:
Dialog Message text
Namespace ‘Microsoft.Policies.Sensors.WindowsLocationProvider’ is already defined as the target namespace for another file in the store.

File: <forest.root>SysVol<forest.root>PoliciesPolicyDefinitionsMicrosoft-Windows-Geolocation-WLPAdm.admx, line 5, column 110
Note In the path in this message, <forest.root> represents the domain name.

To resolve this problem, follow the steps that are documented in the following Knowledge Base article:

3077013 “‘Microsoft.Policies.Sensors.WindowsLocationProvider’ is already defined” error when you edit a policy in Windows

Source: Microsoft
Click to rate this post!
[Total: 0 Average: 0]

Share this content:

Avatar for Andrew Armstrong

About Andrew Armstrong

Founder of TechyGeeksHome and Head Editor for over 15 years! IT expert in multiple areas for over 26 years. Sharing experience and knowledge whenever possible! Making IT Happen.

View all posts by Andrew Armstrong

Leave a Reply

Your email address will not be published. Required fields are marked *