I can just make my own ADM or ADMX files to manage my applications.

I can just make my own ADM or ADMX files to manage my applications.

I can just make my own ADM or ADMX files to manage my applications.

Posted on by [email protected]

ADMX files are great for applications that have them. But there are three main challenges with ADM and ADMX files. Let’s make sure you understand exactly what they are.

Challenge 1: Not every application uses (or can ever use) ADM or ADMX files

Do you use Java, Flash, Firefox, OpenOffice, LibreOffice, Autocad or FileZilla?

Sure you do. But none of those applications use the registry for their major settings storage at all.

And hence these applications and applications like them, cannot use ADM or ADMX files to manage them. Because ADM(X) files can only deliver settings to the registry.

Here’s three examples (which we usually get asked about):

  • Java Control Panel applet’s main settings are NOT stored in the registry. They’re stored in a “preferences” file.
  • Firefox’s “Options” and “about:config” settings are NOT stored in the registry. They’re stored in “.JS” files.
  • Chrome stores some settings in the registry and others in its own special file format. They’re stored in “JSON” files.

Get the idea?

So PolicyPak can manage those applications – because we’re able to write to more than just the registry. And we have preconfigured Paks to get you managing those applications right away.

Challenge 2: No re-application of settings (ever)

Once your ADM or ADMX settings are deployed to the user or computer, they don’t re-apply by default when a user works around them.

That’s right: First, a user can work around your ADM or ADMX setting.

But more importantly, the Group Policy engine will not re-apply those settings and they’ll never be automatically corrected: not with a logoff, and not with a reboot.

To be 100% clear: if you use an ADM or ADMX file, after your user gets your desired setting, he’s welcome to work around your desired configuration setting. Then, when Group Policy re-applies (in the background or at logon, or reboot for the computer) those settings are NOT reapplied.

(You can watch Jeremy’s video demonstration on the subject noted at the bottom of this FAQ to see this problem in action.).

Challenge 3: No un-application of settings (ever)

Additionally, you might have heard of a problem called ADM / ADMX “tattooing”.

This situation occurs when the GPO is deleted (or the person changes job roles.)

When this happens, the Group Policy engine doesn’t (and cannot) remove set ADM & ADMX settings automatically.

So this means that when the policy with the ADM or ADMX file no longer applies, the user maintains these changes.

This is exactly what you DON’T want if he changes job roles or you don’t want the GPO to apply.

Why you need PolicyPak

Here’s the video from Jeremy Moskowitz, Microsoft MVP, Enterprise Mobility to help explain the challenges with ADM and ADMX.

  • Applications’ settings can be delivered anywhere and properly reverted (not “tattooed”) when no longer needed
  • Applications’ settings are always re-applied and auto-remediated when the application launches, and not just once when the settings are originally delivered.
  • Applications’ UIs are grayed or hidden to prevent changes (in about 80% of applications).
  • Applications’ settings can be locked down with ACL Lockdown (in about 80% of applications) so users literally cannot change the settings at all.
  • Applications’ settings can be anything — not just registry based items. So PolicyPak can manage just about any application.