First published on TechNet on Dec 12, 2011
Pre Req: This post assumes you are not using the TS method of managing GPOs documented, at https://blogs.technet.com/b/askds/archive/2009/12/09/windows-7-windows-server-2008-r2-and-the-group-policy-central-store.aspx
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 https://support.microsoft.com/kb/929841 .
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, https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc194417(v=msdn.10).
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 http://support.microsoft.com/kb/813338 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, https://blogs.technet.com/b/askpfeplat/archive/2012/03/14/central-store-and-adm-removal-q-amp-a-with-an-updated-script.aspx
Microsoft
