Group Policy Administrative Templates (ADMX): What are they? How are they used? And what if I need to update them?

on

Group Policy Administrative Templates are registry-based policy settings and provide an XML-based structure for defining the display of administrative template policy settings in the Group Policy Editor. Now I know the name of this blog is Thomas' head in the cloud so why all the focus on on-premise tech? It's because understanding how these templates work is extremely useful in Intune - namely for ingesting ADMX templates (external link to another blog that I'll replace one day when I get around to writing my own post on the topic) and also for general understanding of how Windows works. 

So anyway, ADMX files replace ADM files that used a different markup language. The difference between ADM and ADMX files is that if you choose to save the files in SysVol, each ADMX file only needs to be saved once, with the ADM files having to be saved for each group policy created. - ADMs are text-based documents and can be created or modified via a text editor.

I believe.

ADMs were used before I started in IT so I’ll only be focusing on ADMX.

Although each Windows PC contains its own set of Administrative Templates for Group Policy, they can be better managed in a central repository. This is all the more true when ADMX is added for different applications. However, the update can then turn out to be tricky.

When you edit a GPO in the Group Policy Editor, it gets the available settings from the ADMX files in %systemroot%\PolicyDefinitions.


If you use several workstations with different versions of Windows to manage Group Policy, then you have different templates everywhere or you have to bring them up to date on all PCs.

In addition, the ADMX templates are not only needed for the administration of Windows, but also for Office, Microsoft Edge, Chrome or other third-party applications. These are each subject to their own update cycles and would also have to be updated regularly on each PC.

 

Setting up the Central Store

In order to avoid this effort and to achieve the same release level of the templates on all admin PCs, Microsoft plans to set up a central store on a domain controller for them. A configuration of the GPO editor is not required for this, it automatically searches for the ADMX files only in the central store.

First thing you need to do is download appropriate ADMX msi package and extract the contents.


The location you want to extract the contents to with be the central store. You only need to do this on one Domain Controller. DFS replication will take care of getting these files distributed to all other DCs.

If you haven’t previously used ADMXs before, you’ll need to create the PolicyDefinitions directory:

\\FQDN\SYSVOL\FQDN\Policies\PolicyDefinitions\

for example:

\\lab.int\SYSVOL\lab.int\Policies\PolicyDefinitions

There you then copy the ADMX files as well as the language files (*.adml) with the localized texts that come into subdirectories such as en-US or dk-DK. The GPO editor then automatically loads the ADML of the language that is set on the Admin PC for displaying Windows.


It is important to keep different language versions separate. However, copying unnecessary language files to the Central Store is not recommended because these are then replicated to all domain controllers.

Even if other localized versions of Windows are used, it is strongly advised to install the ADML files from en-US. When the ADML files for the current Windows display language are not available, the English language files are loaded.

If your central store is new/empty, then delete staging_ from the file names:

Get-ChildItem -Recurse *.* | Rename-Item -NewName {$_.Name -replace "staging_", ""}


Now open up (or create a new) GPO in your Group Policy Management editor and…

...

...

WHAT THE HELL IS THIS?

An appropriate resource file could not be found for file \\FQDN\sysvol\FQDN\Policies\PolicyDefinitions\EVERYTHING.admx (error = 2): The system cannot find the file specified.

The .admx Files reported as missing are present in the specified folder.

D’oh.

So, what did I do wrong? Surely the files can be found as this error didn’t jump up until after I created the central store. Well, the way they are referenced is through the language packages. Namely, the .ADML files.

Remember when we renamed/remove the staging_ string? Well, I forgot to also rename the language pack that I’m using.

For example, ActiveXInstallService.admx is referenced by ActiveXInstallService.adml – not en_us_ActiveXInstallService.adml or da_dk_ActiveXInstallService.adml!

*SIGH*

Since my installation is localized using en_US, that’s where I'm going to start. You'll need to do the same for your other localizations (e.g. da_DK if you're like me and are based in Denmark). 

That looks better! 

Congratulations. You’ve now set up your Central Store and have opened yourself up to a lot of really cool stuff. So have a poke around, play with the different policies and dive into a ton of documentation.

Have fun!

Oh, by the way, there’s a reason why the above screenshot is in Computer Configuration > Policies > Administrative Templates > System > Device Guard.

So check this post out: Credential Guard: Protect Windows from pass-the-hash and pass-the-ticket attacks (Hint: I show you how to protect Windows from pass-the-hash and pass-the-ticket attacks).

And just to round this off (seeing as it really doesn't deserve a post of its' own), let's quickly go over how to update your templates...


Updating your Group Policy templates

Because Microsoft includes a new version of the ADMX files with each release of Windows, you need to update the Central Store on a regular basis. You can't simply delete all templates and import new ones if you've also included ADMX for other applications. You'd have to add them again if you didn't.

Furthermore, Microsoft does not always replace the templates exactly. File names change from time to time, and until Windows 10 1903, the Office templates were included in the ADMX download, but they are no longer. Furthermore, the ADMX's date is no longer a suitable filter criterion for deletion; this only applies to the modified templates.

One option is to keep all templates that aren't designed for Windows in a separate folder. After cleaning up the Central Store, you could restore them.

Alternatively, you could unzip the ADMX download, navigate to the appropriate directory, and use the following PowerShell command to delete all files in the store that are also included in the download (remember to change FQDN):

Get-ChildItem *.admx | foreach{ Get-ChildItem -Recurse ("\\FQDN\SYSVOL\FQDN\Policies\PolicyDefinitions\" + ` $_.basename + ".adm?") | Remove-Item -Verbose }

And as always, remember to make a backup before you do anything – especially in production. Just simply make a copy of the current PolicyDefinitions directory and then go ahead.