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
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
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
I am continually disappointed by Microsoft’s recent trend of walking back support for products and features. This is another example of Microsoft inconveniencing system administrators with no clear benefit to anyone. I can understand wanting to make a clean break from pre-Windows 10 Operating Systems, but how difficult would it have been to create NEW ADMX files for ALL Windows 10 configuration? They have already added 30 or more for Windows 10 exclusive features.
I cannot disagree Matthew…sadly.
Sorry for being a bit dim witted, but;
Do you mean that the changes are being done on the admin workstation, then copy the 1.4 ADMX file to the central store in order for the changes to take effect on the clients, and then later on copy 1.5 to the central store?
No, ADMX files have no bearing on changes to clients. They only have a bearing on what you see in the GP Editor and what you see in GP Settings reports. So, what I was suggesting is copying the 1.4 ADMX files locally and using localstoreoverride to be able to see any settings based on the 1.4 ADMX files.
Hello,
To enable localstoreoverride, I unable to Get the Group Policy Key in below Registry path,I am using windows Server 2012 R2 Standard operating system machine.Please advise.
computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
Unfortunately, I don’t have enough information to be able to help you.
Hi Darren,
How would you use GPMC on the admin workstation to view the old settings using the 1.4 ADMX file locally?
LC — You need to use the ‘EnableLocalStoreOverride’ registry value I mentioned to be able to point GPMC at a different place than the Central Store.
Hi Darren,
Would like to inquire about this situation please
Server 2012 R2 DC with all PCs using Win 7 (yes, I know 🙂 ….we are preparing to migrate to Win10 before Jan 2020)
We have the Central Store in C:\Windows\SYSVOL\sysvol\our domain\Policies\PolicyDefinitions however the folder has just 3 files from Barracuda Email Security Gateway Outlook Add-In and the en-US folder that has the 3 corresponding ADML files. There are no other ADMX/L files in the store so I don’t know if I have a real store or just a “fake” store.
We are using GPOs just for 4-5 features.
I am preparing a Win10 1903 test image on a physical PC and would like to test some GPOs on it.
If I place the ADMX and ADML files from Win 10 1903 into the existing Central Store, will it break any of the current GPOs ? (The ADMX files for 1903 were released 3 days ago on July 16 2019). However if I remember from your article, the ADMX files are not in charge of applying the GPOs, they are just an interface of options in the GPEdit screen, right ? Some clarification would be appreciated.
Also MS is recommending in this article to create another folder inside the Central Store so after each version of Win 10 upgrade you’ll have the original ADMX files + the new ADMX in that new folder. Rename the original folder to something like “Store1709” and the new folder gets renamed to the “Original” name :PolicyDefinitions. This is how MS is recommending to have both versions in case something bad happens as you described.
However this works between Win 10 upgrades. What about my situation where I would like to control both Win 7 and Win 10 PCs for a short period of time, at least until all the PCs will be on Win 10 ?
https://support.microsoft.com/en-in/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra
Thank you
Radu-
If the Central Store exists, then GP Editor and GPMC reporting will always use that for that given domain. So in your case, it is a “real” store and it is probably not going to work if you only have 3 files in it (unless individual workstations that are managing GPOs are using the Central Store override registry value). Adding Win10 1903 ADMXs to an otherwise empty central store will not break any existing settings, but could possible prevent you from seeing some settings that were set with prior ADMXs but are no longer support in 1903. Microsoft’s recommendation about storing previous versions in the central store is not a bad one, as it gives you an easy rollback. You can also use the Central Store override registry value on a given workstation to override the use of the Central Store to evaluate the newer ADMXs against your current environment. That’s a good non-impactful way of doing it and it’s also not a bad approach for different OS versions, as long as you ensure that those machines that are managing each version of the OS-specific GPOs are always using the correct local version of ADMXs.
I appreciate this is an old post Darren but I am looking at using the override value on a Windows 10 1909 build but the Group Policy Key is no longer there. Are you aware if Microsoft have now removed this feature for newer builds of Windows?
Rob-
In all cases you need to create the value. It’s not there by default. I haven’t tested explicitly with 1909 but I doubt MS removed support for this. I would try adding the value and see if it helps.