Select Page

Microsoft has recently put out several articles explaining some of the nuances of ADMX files in the new world of Windows-as-a-Service–where new Windows builds come out frequently and often ship with new versions of ADMX templates. I’ve blogged previously about the role of ADMX–how is essentially builds the UI that you see under Administrative Templates policy within the GP Editor. I’ve also stated in the past that with each new subsequent release of Windows, ADMX files have traditionally been a superset of the previous versions of those files, and that you could safely replace the old version with the new and start managing GP from the latest version of the OS, and life was good. That, unfortunately, is no longer the case. As Microsoft states in this recent support article, Microsoft has started to actually remove settings from ADMX files that were present in previous versions of Windows. Why is this is a problem? Well, it’s only a problem if you had actually enabled policy in any of those deprecated settings, within your existing GPOs. Once you remove a setting from an ADMX file that was previously set in an existing GPO, that setting becomes unmanageable (i.e. you can no longer configure it) and it appears in a GPMC settings report as an unresolved “Extra Registry Setting”, as shown here:

Extra Registry Settings from unresolved ADMX files

Extra Registry Settings from unresolved ADMX files

 

Once these settings are “stuck” in a GPO, the only easy way to make them manageable is to rebuild or reload the ADMX entries that represent them (NOTE: You can also use the Group Policy PowerShell module to manually manipulate (i.e. change or remove these settings) if needed, but that’s a story for a different day!)

Strategies for Managing ADMXs

So, in that MS Support article above, Microsoft has provided guidance on which settings have been removed between previous ADMXs and the current ones, so that you know what to look out for. But it doesn’t really help you figure out how to manage these situations, where a new set of ADMX files come along that deprecate settings that you’ve implemented in existing GPOs. This is especially true if you are using the Central Store to provide for centralized storage of your ADMX files. If you remember, the Central Store is simply a folder in SYSVOL on your DCs, that you can use to store all of your current ADMX (and ADML) files. If the Central Store folder exists in a domain, all users who report on or manage GPOs will use the ADMX files in the Central Store. I’ve not been a big fan of the Central Store in the past because of this limitation, but it does force a certain rigor on IT shops to ensure everyone is using the same version of ADMX files. Once the Central Store exists, there is no longer an option for an individual administrator to use the contents of their local C:\Windows\PolicyDefinitions folder to manage GPOs in the domain…or is there?

Three years ago I blogged about a feature that Microsoft was adding to Windows Server at the time, that would allow you to override the Central Store on a per-machine basis. This feature is now supported in current versions of Windows (e.g. 10, 2012-R2, 2016, etc.) out-of-the-box, but does require a manual registry hack to enable, as I detailed in that blog (see image below):

Overriding the Central Store via the Registry

Overriding the Central Store via the Registry

 

So, how can we use this technique in this new world of deprecated ADMX settings? Well, you can keep your Central Store updated with the latest and greatest ADMX files, but use this registry modification on a select Admin workstation that you use to manage exceptions to the centralized store of ADMX. As an example, if new version 1.5 of a particular ADMX file is released by Microsoft, and it removes a bunch of settings that were in version 1.4 of that ADMX, then any of those removed settings that you defined in your GPOs would show up as unmanageable “Extra Registry Settings” in GPMC when you put the 1.5 version of that ADMX in your Central Store–no one would be able to get to those settings to edit them. However, if you had an Admin workstation standing by with the ‘EnableLocalStoreOverride’ registry setting in place, and the 1.4 version of the ADMX files in the C:\Windows\PolicyDefinitions folder on that workstation, you’d be able to get into those orphaned settings, set them to “Not Configured” and then go back about your business of managing GPOs from your “normal”, Central Store-aware workstations! Easy.

Managing ADMX files is challenging enough without Microsoft introducing deprecated settings, but at least there is a way to work around them!

 

Darren