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:
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:
You can create a central store for a domain by performing the following procedure:
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:
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?
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.
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
Incident management used to be about debugging code, but in an always-on world the stakes…
Our esteemed Windows expert asks his readers for advice on the best way of coming…
Want to make managing RBAC permissions at the subscription/management group level a breeze? Start using…
Google has patched a dangerous zero-day vulnerability in its Chrome browser. But now it’s up…
The document management software market is booming as companies continue their massive migration toward remote…
It’s been 2½ years since the GDPR went into effect. While most businesses have adapted…