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.)