Creating a Group Policy Central Store

If you have a Windows domain, you are working with Group Policy (GP), is just the way it goes; and as everything else Group Policy needs maintenance and someone to configure it. In a single forest/domain, managing GP is easy, but for those of you that are working in big organizations with multiple domain controllers things start to get heavy for GP. As you might know by now, there are the so-called policy definitions; the ones you see when you open the Group Policy Management Editor. Those policy definitions are retrieved from files, ADMX files that sit on your domain controller (C:\Windows\SYSVOL\sysvol\{Domain Name}\Policies\). ADMX files are new starting with Windows 2008. Until now, in server 2003 we had ADM files.

The first downside with ADM files was that you could only address the registry settings of an application; so if that application was saving its settings in .xml, .ini files, you had to do some scripting or something to change its settings. The second downside was that for every language specific server, you had to download a complete set of ADM files. There is no need to do this anymore with ADMX, because the files remains the same for all the languages. All you have to do is download the ADML pack for your language, which is much smaller than the size of ADM, and you’re done.

Things get complicated when you have multiple domain controllers in your organization, and you are not the only one creating/editing GPO’s. Every time you use Group Policy Management Editor directly from your technician laptop/workstation not from the domain controller, those policy definitions are loaded from that local client (laptop/workstation). This is quite a big issue, as you will in just a minute.

If you are wondering how I loaded the Group Policy Management Editor from a client (Windows 7,8), just go to Microsoft’s web page and download the Remote Server Administration Tools for Windows 7 or Windows 8. Install the update, then go in Programs and Features and enables the tools you need. You have to do this only on Windows 7 clients, because in Windows 8 those tools are automatically enabled.

Let’s say you are running Windows 8 on your laptop, and your work colleges are running Windows 7. You open the Group Policy Management Editor and edit a GPO that applies to some Windows 8 clients. Since those policy definitions are only available on Windows server 2012 and Windows 8 only you and those running these OS versions can see the policy you just set. If you take a vacation and someone needs to edit that policy those running Windows 7 will be out of luck. As an example, here are a set of policies that exist on a Windows 8/2012 client, but missing on Windows 7/2008 R2.

   

Another good example is when you add the Office Administrative Templates files. Sometimes you see the policies and sometimes you don’t. As in the pictures bellow, on my Windows 7 machine I have the Office policies but on my Windows 8 machine I don’t.

   

Starting with Windows 2008/Vista, a new concept was introduced to overcome this impediment, and is called Group Policy Central Store. Using a central store you will have the same policy definitions loaded no mater what client you are using for editing GPO’s. All you have to do is copy some ADMX and ADML files from an updated OS into one of your domain controllers folder, the Sysvol folder, then the replication will do the rest. Let’s see how is done. For this demonstration I will copy the ADMX and ADML files from a Windows 8 machine that was recently updated. Even if right now you don’t have Windows 8 clients or 2012 servers in your environment you can safely copy the policy definitions from these OS’s, and you will get all the goodies.

ADM files are not supported with Central Store, you can only use ADMX.

The policy definition files are located in C:\Windows\PolicyDefinitions. Drill down to this folder, and as you can see there are quite a few ADMX files in here. In the en-US folder the language files (ADML files) are present. By default only English is available, and for extra you need to go to Microsoft and download the Administrative Templates files.

   

Now right-click the PolicyDefinitions folder and choose Copy. Again, this is done on my Windows 8 machine.

From the same client you can do a UNC path to \\Domain Controller\Sysvol\Your Domain\Policies and paste the PolicyDefinitions folder in here.

    

If you don’t want to use a UNC path, login to a domain controller and paste the PolicyDefinitions folder in C:\Windows\SYSVOL\domain\Policies. I prefer the first method anyway.

All you have to do right now is wait for the replication between domain controllers to finish. This is only available in medium to large environments with multiple domain controllers where AD sites are present and sites schedules are configured. When the replication is done, open the Group Policy Management console from you technician laptop/workstation and edit a GPO. The first thing you will notice is that Administrative Templates are now retrieved from a central store, and not from the local client.

    

One other thing that is different, (in my environment anyway) is that from a Windows 7 machine I can see policies that are available only on Windows 8/2012 systems. Why ? Because I copied the policy definitions files from a Windows 8 machine. Right now, even if I use a Vista system I will have the same Administrative Templates present in the console.

Need more languages ?  Just download the Administrative Templates files, unpack them and copy the language you want to the PolicyDefinitions folder on one of the domain controllers.

    

For those that are using Microsoft Office policies, just download this pack, extract the files and copy the content of the ADMX folder to the PolicyDefinitions folder to one of your domain controllers. Off course, copy just the language you need.

    

Now when you edit a GPO the same Administrative Templates are displayed in the console, no matter the client.

    

When you need to update the policy definition files (ADMX), all you have to do is overwrite the existing ones in the PolicyDefinitions folder on one of your domain controllers. This is so simple, and can do so much. You can use it in a small environment too, where you have only two or three domain controllers, and your administration will be eased.