Add Administrative Templates to a Group Policy Object in Windows Server 2008 Domain


With Microsoft Windows Server 2008 and 2008 R2, there is a new file format for the Administrative Templates that controls and standardizes the operating system and software in Active Directory domains.

Administrative Templates for GPOs are used to set and control the registry. There are hundreds of Administrative Templates available for Windows Server in 2008. For more details, you can see our article: Understanding Administrative Templates in Windows Server 2008.

Administrative Template Types

You are not limited to the Administrative Templates that come in Windows Server 2008 by default. For example, if your environment uses Office 2010, you can download and install the Office 2010 Administrative Templates that will allow you to configure settings for almost every aspect of all of the different software components in Office 2010, from the commonly used Word and Excel, to the more specialized Visio and Project.

In earlier versions of Windows Server, the Administrative Templates had an .ADM file extension, and were Unicode-based text files. In Windows Server 2008 and 2008 R2, the Administrative Template files are XML files with an ADMX or an ADML extension. Thankfully, if you still have your Administrative Templates in the classic ADM file type, then you can still use them. They can be installed through the use of the Group Policy Management Console, as described in our previous article, Adding New Administrative Templates to a GPO.

If you have one of the new XML-based Administrative Templates, you do not install it through the console in the same way as the classic ADM files. Instead, you only have to place the ADMX files into a location where either the Group Policy Editor (GPEDIT.MSC) or the Group Policy Management Console (gpmc.msc) can find and read it.

Where To Put The ADMX Files

Will there be more than one administrator managing GPOs for your domain? If so, you should consider creating a central store for the Administrative Templates. The central store is easy to set up and keeps all of the Administrative Templates in one place, so all domain administrators have access to the same GPO Administrative Templates. A central store is not a requirement, and whether you are the only administrator or you just don’t want to create and use one, you can still install and use the ADMX/ADML files on a workstation (no XP though, you must be running at least Vista).

How To Create A Central Store

First, the central store needs a root folder to store all of the language neutral Administrative Templates. It then needs a folder created that holds each language specific Administrative Template that your domain environment will create Group Policies for.  On the PDC Emulator, create the folders like this:

Start an administrative session in PowerShell

I will be using only one language (I’ll use my language code in this example: EN-US). A full list of locales and languages are available at Microsoft’s Locale Identifiers page.

​$codes = “EN-US”

# If you want additional language codes, create $languageCodes as an array:
#  $languageCodes = “EN-US”, “EN-CA”, “FR-CA”

$path = “$env:systemroot\sysvol\domain\policies\PolicyDefinitions”

$codes | Foreach-Object {New-Item –Path “$path\$_” –Itemtype directory –Force}

You do not need to create the folder on each Domain Controller. When the Domain Controllers replicate, the folders will be created on each Domain Controller. Relying on the replication is the reason to create the folder on the Domain Controller that is holding the PDC emulator role.

Now that the central store is created, you only need to place the ADMX files into the correct section of the central store (language specific templates in the appropriate template folder, and the language neutral templates in the root folder).

Since the presence of a central store makes the group policy editing tools (GPEDIT and GPMC) stop looking in other places for Administrative Templates, you must populate the central store after creating it.

How to Populate the Central Store with PowerShell

Without populating the central store, all of the original Administrative Templates will not be seen by your group policy editing tools. To copy over all of the existing Administrative Templates from your workstation or Domain Controller, use PowerShell:

​$local = “$env:systemroot\PolicyDefinitions”
$centralStore = “$env:logonserver\sysvol\policies\PolicyDefinitions”
Copy-Item –Path “$local\*.*” –Destination $centralstore –Recurse

This will populate the central store with all of the policies.

How to Use Administrative Templates Without a Central Store

When you do not require a central store, you can still install the Administrative Template files directly into the Workstation that you are working with the Group Policy on.

You can save the language neutral files (those with an ADMX extension) directly into the $env:systemroot\PolicyDefinitions folder. There will already be some policy definitions present in that folder.

Language specific files (those with an ADML file extension) will need to be put directly into the language folder that it corresponds to (such as “EN-US”).


When you need to expand the capabilities of Group Policy, you can find Administrative Templates provided by the vendor of the software or hardware.  The classic “ADM” files which are used in previous versions of Windows Server still work in Server 2008. Additionally, there are new XML-based Administrative Templates identifiable by their ADMX file extension (or ADML for language specific templates.)

A central store can be set up on the domain controllers, which manages all of the Administrative Templates in use within the domain. Once set up, the central store makes adding the XML Administrative Templates available to all Group Policy Administrators in the domain, and adding more is as easy as copying files into the store.

Without a central store, you will just need to copy the Administrative Templates into the systemroot\PolicyDefinitions folder, and your group policy editor will pick up the new policies.