Is the Group Policy Central Store still relevant in the age of Windows 10?

For about the last decade, Active Directory admins have been able to take advantage of a Windows Server feature that made their life easier when it came to managing Group Policies in their environment. The feature I’m referring to is the Group Policy Central Store, and to refresh our understanding let me start off with a short excerpt from one of my books where I describe the purpose and operation of this feature:

Configuring a Group Policy Central Store

Prior to Windows Vista and Windows Server 2008, all of the default administrative template files (.adm files) were added to the ADM folder of each Group Policy Object (GPO) on a domain controller. Because GPOs are stored in the SYSVOL folder on domain controllers and each GPO typically occupies about 2MB of disk space, the more GPOs there were in the environment, the greater the size of the SYSVOL folder was. This condition was sometimes referred to as “SYSVOL bloat.” Furthermore, because the contents of the SYSVOL folder are automatically replicated to all domain controllers in the domain, this problem was multiplied considerably.

Beginning with Windows Vista and Windows 2008, however, this situation has changed in two ways:

• A new XML-based format for administrative template files called ADMX has replaced the earlier ADM format used for defining registry-based policies in GPOs. An associated format called ADML supports the multilingual display of policies.
• All of the policy definition files (.admx and .adml files) for a domain can be stored in a central store in SYSVOL. This means only one copy of each ADMX template needs to be stored in SYSVOL (instead of a copy of each ADM template for every GPO in the domain).

You can create a central store for a domain by performing the following procedure:

1. Create a folder named PolicyDefinitions in the following UNC path on a domain controller in the domain:
   \\domain_name\SYSVOL\domain_name\policies
   For example, for the corp.fabrikam.com domain, you would create the following folder:
   \\corp.fabrikam.com\SYSVOL\corp.fabrikam.com\policies\PolicyDefinitions
2. Copy all of the files from the %systemroot%\PolicyDefinitions folder on a Windows 8–based administrative workstation to the PolicyDefinitions folder on a domain controller. Alternatively, you can download “Administrative Templates (.admx) for Windows 8.1 and Windows Server 2012 R2” at http://www.microsoft.com/en-us/download/details.aspx?id=41193 and copy them to the PolicyDefinitions folder on a domain controller.
3. Wait for SYSVOL to replicate the changes to all domain controllers in the domain.

So, what’s the problem?

That’s the skinny concerning the Group Policy Central Store in Windows Server 2012 R2, and it really hasn’t changed any since. So, what’s the problem?

The problem seems to be Windows 10. Since it was first released just over four years ago, Windows 10 has gone through numerous releases called versions. There has been:

• Windows 10 v.1507 the original version which was released in July 2015
• Windows 10 v.1511 the so-called November Update released in November 2015
• Windows 10 v.1607 the Anniversary Update released in August 2016
• Windows 10 v.1703 the Creators Update released in April 2017
• Windows 10 v.1709 the Fall Creators Update released in October 2017
• Windows 10 v.1803 the April 2018 Update released, well, guess when (and so much for the fancy names too)
• Windows 10 v.1809 the October 2018 Update
• Windows 10 v.1903 the May 2019 Update which was only declared “ready for broad deployment” this September!
• And finally, Windows 10 v.1909 the November 2019 Update, which is supposedly just around corner (and who knows when this version will be declared ready for broad deployment)

That’s eight versions of Windows 10 released in only four years, with a ninth version just on the horizon.

And that’s eight or nine versions of ADMX/ADML template files for administering Group Policy settings for Windows 10 computers.

How on earth do you manage Group Policy in an Active Directory environment where Windows 10 versions keep changing and new ADMX files need to be deployed? And how do you manage this when you have more than one Windows 10 version present in your environment, for example when transitioning PCs from one Windows 10 version to the next?

Some suggested solutions

These are not easy questions to answer. In fact, most Windows admins I’ve talked with are still struggling with the best way of dealing with the situation.

For example, one administrator I heard about recommends setting up a separate Windows management workstation for each version of Windows 10 running in your environment. For example, if you have both v.1809 and v.1903 client computers, you would use your v.1809 workstation to administer Group Policy for your v.1809 clients by creating and configuring GPOs for managing them, and also have a v.1903 workstation to do the same for clients running v.1903.

The rationale behind this is that while the settings introduced in ADMX/ADML template files for newer versions of Windows usually don’t break things on computers running older versions of Windows, there can occasionally be problems that arise when you apply newer template files to older Windows installations. For example, there have in the past been a few cases where the name of a policy setting was changed with the release of a new template. There have also been occasions where a policy setting as removed as no longer applicable (see this old blog post for more about this) which can leave administrators in something of a quagmire if they previously enabled the setting on some systems and are no longer able to disable it using Group Policy. I can’t point to specific policy settings in Windows 10 versions where these kinds of things have occurred, but I’ve heard from reliable sources that they exist. And I’ve also heard stories about ADMX/ADML files having typos in them that resulted in parsing errors when you tried to open the files in the Group Policy Management Console (GPMC). In fact, I believe Microsoft even renamed one of the Windows 10 ADMX files early on and this caused a lot of confusion until it was rectified.

Then there’s the matter of trying to ensure consistency between Windows and Windows Server settings. For example, if your Windows 10 machines are running v.1903 while your servers are running Windows Server 2019, you may have a problem if you try and use the same ADMX/ADML template files to manage both your PCs and servers. That’s because Windows Server 2019 is actually built on Windows 10 v.1809 under the hood, so if you have v.1809 templates in your Central Store then you may not be able to manage certain features on your v.1903 PCs. Situations like this also lead some administrators to keep at least one admin workstation for each client and server version of Windows in their environment so the right template files can be used to manage Group Policy on each kind of client or server system. Because even if the issues you might potentially encounter are marginal edge cases, the last thing you want to have happen in your environment is something mysterious that takes you hours and hours to troubleshoot.

I’ve also heard some reports that even applying software updates for Windows 10 can occasionally result in changes to templates, something you can investigate if you like by examining the timestamps on your ADMX/ADML files before and after rolling out the latest batch of Patch Tuesday goodies. If you’re using a Group Policy Central Store in your environment, this kind of thing can quickly cause the templates stored there to go out of date.

If you do use a Group Policy Central Store

But if you do decide to continue having a Central Store for your Active Directory environment, let me finish off with one recommendation: always make backups of your PolicyDefinitions folder. Perform these backups regularly, and do them religiously. Be sure especially to back up your PolicyDefinitions folder before you install any new ADMX/ADML template files or make modifications to any of your existing ones.

And finally, if you run the gpresult.exe utility and see anything that says “extra registry settings” or something similar, then you can bet that something has gone wrong somewhere regarding your ADMX/ADML template files. The most likely cause of such an occurrence is that the policy you’re looking at was created using an earlier template file that’s no longer present in your Central Store because a newer file has replaced it by being copied over the old one. In such a situation you may find yourself needing to temporarily restore the older template file to your PolicyDefinitions folder to properly manage the affected setting.

What a pain.

Featured image: Freerange Stock