How to Implement the Central Store for Group Policy Admin Templates, Completely (Hint: Remove Those .ADM files!)



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at (hosted at Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either as you do today, or at our new site Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!



Pre Req: This post assumes you are not using the TS method of managing GPOs documented, at

In the field we commonly see two scenarios around the Central Store for Group Policy administrative templates. The first is that the Group Policy Central Store does not exist, meaning that the Policy Definitions folder with the administrative templates (.admx and .adml files) does not exist in SYSVOL. The second is that the Policy Definitions folder exists, but the .adm files are not removed from individual group polices thus negating a large benefit of the Central Store. In this post we want to walk you through how to fully implement the Central Store with a little help from our friend PowerShell.

First, you need to implement the Central Store. There seems to be some misunderstanding around the Central Store. For example, it is common to hear the question “How will this change affect the policies being applied to all the computers!?” The answer is, “It won’t. The .adm or .admx files are only used by GPO administrators – those who create/edit the policies.” Administrative templates (.adm or .admx) have NO effect on how group polices are processed on clients. To implement the central store simply follow the steps in Basically, you are copying the Policy Definitions folder, from a Windows 7/Windows 2008 R2 client/server, to SYSVOL. You can confirm your group policy management console is using the Central Store by verifying where Administrative Templates are referenced. Also note that when the Central Store is in place the GPMC will always reference this and not any local .ADMX files.


Here we can clearly see that we are using the Central Store. Once you have the Central Store implemented, you’ll want anyone that creates or manages GPOs to use the GPMC from an up-level OS (NOT Windows XP or Windows Server 2003). For example, if everyone that creates and manages GPOs is on either Windows XP or Windows Vista, you’ll want to all use Vista, not a mix of XP and Vista. This also applies if you have a mix of Windows XP and Windows 7 or Windows Vista and Windows 7, you would all want to use Windows 7 to create and manage your GPOs from now on.

Next, we have to convert any custom .adm files that may be in use using the .ADMX migrate found here,  Next we need to remove the existing .ADM files from all GPOs. Previously, the creation of each new GPO added five .adm files (conf.adm, inetres.adm, system.adm, wmplayer.adm, wuau.adm) to SYSVOL. Since these five files total about 4 MB, this means 4 MB of redundant files for every GPO in your environment. If you have dozens, hundreds or thousands of GPOs, how can you remove these duplicate files (after implementing the Central Store)? PowerShell to the rescue!

PowerShell code is included as an attachment to the blog as well as the text at the bottom of this post.

The syntax works something like this:

.\remove-adm.ps1 –backupPath “C:\wherever” –logPath “C:\whereverlogs\mylogname.csv”


First, you can run this command with the –whatif parameter to generate a report but not actually remove anything. The script removes any of the five the standard .adm files, and it also checks to see if any other .adm files have been converted to .admx and included in the Central Store. Everything is logged in a CSV file, whether you use the –whatif parameter or not.  Simply open the .csv file, and sort by “ADMXInCentralStore”. If this value is true, the .ADM file can be removed.

If something goes horribly wrong, you are able to restore the .adm files you’ve deleted with the following command.

.\remove-adm.ps1 –logFile <path to old log file> -restore



That’s it. You are done. All of your .adm files are gone from SYSVOL and your Central Store is fully implemented. If you are feeling extra aggressive you can update the FRS file filter using the directions in to prevent any new .adm files that are accidently added to SYSVOL from being replicated by FRS. Now sit back and enjoy all that file space you’ve saved in SYSVOL!

UPDATE : We have an updated version of the script located at,

Mark Morowczynski & Tom Moser