In large organisations with tens of thousands of domain joined assets, it’s perhaps not all that surprising that Active Directory Functional Levels (ADFL) and Domain Controller OS versions can lag some way behind the versions of the organisation’s newest clients. Legacy applications, technical debt, fear – what ever the reason for DCs and ADFL staying at particular versions, we still need to be able to manage the latest OS versions.

With each major Microsoft Windows OS version more and more configuration settings are added and yet others deprecated or removed. So supporting Windows 7 alongside the latest Windows 10 clients (and everything in between) presents us with some challenges.

The Problem

What happens for example when you have Server 2008 R2 DCs running ADFL 2003, and you want to configure group policy settings that were introduced in Windows 8 or 10? Well, you set up a Windows 10 admin machine, join it to the domain, install the Group Policy Management RSAT tools, log in with a suitable admin account and start to build your GPO.

But then you can’t find a particular setting that you wanted to manage. Confused, you go back to your test/development system where you have a similar DC and client set up with all the same versions (you do have a test system don’t you!?) where you find the setting you wanted without issue. So what’s going on here?

It’s very common (and best practice) for a large organisation to create a central policy store to hold the relevant ADMX/ADML files for use in the domain. When this is configured, by default the Group Policy Management Console (GPMC) will use those central ADM files, whether it is run directly on a DC or on an admin machine elsewhere in the domain. So in this example we find that our ADMX files in the central store are dated some time in 2009, way before our particular configuration setting was introduced. As such, by default we don’t see the configuration setting we want to use in the GPMC, even if we run it on a Windows 10 client.

We don’t see this behaviour in our test environment as we likely didn’t configure a central policy store – it’s not there by default, you have to manually create it. As such GPMC falls back to using the ADMX files installed on the client on which it is running, so we see all our latest and greatest settings while building a GPO if we run GMPC on a Windows 10 machine.

The Solution

Thankfully there is a solution in the form of a hotfix and registry modification for Windows 7 through to Windows 8.1 which is detailed here. Microsoft unfortunately don’t detail Windows 10, however it turns out that the registry key change (setting HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\EnableLocalStoreOverride to ‘1’) works on Windows 10 out of the box.

So now we can simply close the GPMC, set the registry key detailed above to 1, then reload GPMC and all our expected settings are available again!

Reading the Microsoft article linked above in detail it is actually recommended that you keep the central policy store at the oldest version you need to support and use a newer admin machine to make updates to newer group policy settings, meaning that the two can co-exist quite happily on the same domain.

That said, wouldn’t it be better if large organisations just didn’t let themselves get in to such a dark place with running 12+ year old Operating Systems!? 🤔