Long-Standing Encumbrances

The development strands of the ADMX files are, to put it kindly, less than perfect. Before Windows 10, so-called "Super Sets" stipulated that all previous settings are always included in the latest version. It didn't matter whether the policies came from a server or from a client service pack, all the legacy values were always included in every new version. This status was frozen in Windows 10, so there will be no further changes or adjustments of the legacy settings (2000/XP/2003/Vista/7/8/8.1). The current Windows 10 policies still contain settings that were only applied under Windows 2000 when they were distributed to a client or user – a cleanup process never took place.

In Windows 10, the idea arose that policies would be removed from the ADMX settings if they belonged to an unsupported operating system and would no longer take effect in the new build. A review was conducted every six months (this is now annual) to determine what to keep and what to remove.

To its own chagrin, Microsoft itself has broken the rule that an operating system only has a half-life of three builds. Enterprise editions starting with 1809 have a lifetime of five builds in the fall releases. The exception is 1803, which was supported for five years despite being a spring release. On top of this is LTSC (formerly LTSB) with a 10-year lifetime. Now specific 1607, 1809, and 21H2 guidelines need to be kept "forever" because of an LTSB/C edition.

Windows 11 now joins this chaos as a completely new system – at least in terms of nomenclature and the ADMX development thread. Support for Windows 10 ends in October 2025, and Windows 11 has existed in parallel since fall 2021. Different ADMX files are available for download for the two operating system versions, with some settings from version 10 missing from version 11, and vice versa. Administrators now have to deal with two ADMX variants and may wonder what to do with Windows Server 2022 and its ADMX files. You will find no easy solution for this messy system.

The Problem with the PolicyDefinitions Store

You can only establish a versioned PolicyDefinitions store if you set up complex scripts that include permanent renaming of existing folders for each version. Incidentally, editing a script appropriate for the operating system so that it chooses the "correct" PolicyDefinitions folder is not recommended. This action leads to more chaos and errors than to opportunities for the script to improve the situation.

In this confusion, it is difficult for an administrator to find their way through the jungle. Best practices now dictate simply using the latest templates at all times, mixing server and client ADM files in a huge merge, and replacing existing ADMX files with newer ones. For clients, you need to agree on a version. The recommendation is to use the version (Windows 10 or 11) used by the majority of clients in your organization.

Remember that nothing dire can happen; there are no wrong ADMX files. However, you could have a better fit for the current use case. If this happens, make sure you use PowerShell before rebuilding the entire PolicyDefinitions store just to change a registry value or make the HTML report look nicer.

Overrated Client

Many administrators still see the issue of group policies strongly anchored to the client, and it is the first system they control and monitor with group policies. The terminal device is the weakest link in the chain and is always assumed to be the first to break when an attack occurs. The question you need to answer, though, is: What is the method that hackers are most likely to use to attack a system these days? The route into the enterprise currently tends to rely on email, web portals, or the cloud, because they provide publicly available resources that are often secured by a far-too-weak and simplistic username-password construct. However, by the time the malware reaches the client, other systems have long since failed: Users use a password that appeared in a data leak. The anti-spam filter on the mail server forwarded the email. The proxy server has not prohibited access to the spoofed "company website" where the user data is stored.

These and similar cases are the rule today – the theory of the client as the weakest link in the chain is no longer tenable. The client is more likely to be the link in the chain through which distribution occurs at the end, but it is other systems that failed first. Sadly, the focus here is on the user.