Select Page

Recently I’ve been answering a few questions about the role of ADMX files (Administrative Templates) in Group Policy. For those who are new to Group Policy or haven’t spent a lot of time with it, I have seen some misunderstanding around what these template files actually do, and their role in GP processing. So I thought I would take the time to discuss that a bit more.

What Are ADMX Files?

ADMX files (and their predecessor–.ADM files) have been around as long as Group Policy (and system policy) have been around. ADMX files are XML text files that describe what you see under Computer Configuration\Policies\Administrative Templates and User Configuration\Policies\Administrative Templates in Group Policy Editor. They are literally used by GP Editor to populate the hierarchical folder structure of settings you see when you edit a GPO and drill in under “Administrative Templates”. It is important to note that no other policy areas (e.g. Security Settings, Folder Redirection, etc.) uses ADMX (or ADM) files to populate the options you see in GP Editor.  ADMX files are provided by Microsoft in all Windows versions. You can also create your own customer ADMX files. Microsoft provides a free tool to help you do that. You can find the default ones that MS provides in the c:\windows\policydefinitions folder on any Windows system (server or desktop), as shown here:

The local ADMX folder in Windows

The local ADMX folder in Windows









You will also notice a sub-folder in that c:\windows\policydefinitions folder. On my machine, that sub-folder is called en-us. It will vary based on the language of your Windows installation (e.g. en-us stands for US English). That folders holds .ADML files. These files are the language-specific strings that correspond to the ADMX file. So every .ADMX file in the root of c:\windows\policydefinitions should have a corresponding .ADML file in the language-specific folder. If you have an ADMX file that is missing a corresponding ADML, you will likely have an error when you launch GP Editor.

Where Are ADMX (and ADM) Files Stored?

In the “old days”, when we only had ADM files, these files were stored in c:\windows\inf. When you created a GPO these ADM files would get copied up to the SYSVOL portion of the GPO, under a folder named ADM (this is actually still how it works, if you have GPOs that contain custom ADM templates). When Microsoft introduced ADMX/ADML files, they changed the model. ADMX files are not stored in each GPO. They are either found, as I’ve mentioned, in the c:\windows\policydefinitions folder, or in something called the Central Store. The Central Store is simply a folder that gets created on the SYSVOL share, at the same level that GPOs are stored in SYSVOL–namely under \\<domainName>\SYSVOL\<domainName>\Policies\PolicyDefinitions. Creating the Central Store is a simple matter of creating that “PolicyDefinitions” folder in SYSVOL and then copying the contents of your c:\windows\policyDefinitions folder (including the folder for the language-specific ADML files), into that SYSVOL folder. I have a small utility that you can use to automate this process if you’re unsure. Once the Central Store is created, all users in that domain who edit Group Policy, will reference ADMX files from the Central Store. If you wonder whether you are using the Central Store or not, just look at the Administrative Templates node in GP Editor. After the words “Administrative Templates”, you will see, in parentheses, whether the Central Store is in use, or you are still getting your ADMX files from c:\windows\policydefinitions (as below):

Determining whether the Central Store is in use

Determining whether the Central Store is in use



Note that once the Central Store is created in a domain, all users who edit Group Policy will reference the ADMX/L files found in the Central Store, and only those. If you need to add or update ADMX files, those must be done against the Central Store, and will affect everyone who edits Group Policy.

A quick note on ADM files. These are still supported in GP Editor. If you right-click the Administrative Templates node under either Computer or User Configuration, you will see an option to “Add/Remove Templates”. This pertains strictly to ADM files, and allows you to associate ADM files to GPOs that are likely also using ADMX files. When you add an ADM file to a GPO, that file is copied up to the ADM folder in SYSVOL, for that GPO, just like it used to be in the pre-ADMX days.

How Are ADMX Files Used by Group Policy?

So now that we know where ADMX files are stored, let’s talk about how they’re used. As I mentioned earlier, ADMX files, like ADM files before them, have no role at all in the *processing* of Group Policy by client computers or users. They don’t even need to be present when GP processing occurs. In fact, the only time ADMX or ADM files are ever read or considered, are when you are editing GPOs in GP Editor. When you expand the Administrative Templates node, and you see all of those folders, sub-folders and policy items–those correspond to GP Editor reading each ADMX file it finds, and building that tree of nodes dynamically. To illustrate this, if I open GP Editor and drill into Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer, the editor is reaching out to where my ADMX files are found, cracking open the inetres.admx file, and populating all the settings I end up seeing in GP Editor, as shown here:

How ADMX files correspond to what you see in GP Editor

How ADMX files correspond to what you see in GP Editor









Once you are finished editing that GPO, those ADMX files are not in use at all. They are not stored in the GPO, they are not downloaded by the client that is processing that GPO, and they are never referenced during GP processing. The only thing that is referenced, are the registry keys and values, stored in the SYSVOL part of the GPO in the registry.pol file, that you’ve instructed the GPO to set. But that’s a story for another day.

Hopefully this has cleared up the role of ADMX files and helps understand where they’re stored and when they’re used!