Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

After writing a custom ADMX template and adding it to the PolicyDefinitions, I see the following warning when looking at the Policy Setting:

Note: This registry setting is not stored in a policies key and thus considered a preference. Therefore if the Group Policy Object that implements this setting is ever removed, this setting will remain.

What does this mean for me? And can I modify my ADMX to store its settings in a policies key?

share|improve this question
add comment

1 Answer

up vote 0 down vote accepted

You receive this warning because Group Policy distinguishes between two objects: Policies and Preferences. A full explanation can be found here, but I'll list the major differences as they apply to this situation.

Firstly, a setting must be stored in one of the following keys for it to qualify as a Policy:

  • HKEY_CURRENT_USER\Software\Policies
  • HKEY_LOCAL_MACHINE\Software\Policies
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies

As most custom ADMX files are written to modify existing registry keys, almost all of them are Preferences by default. If you see the warning you described, that means that your ADMX file defines preferences, not policies. Modifying it is impossible as it'd lose its effect, namely to modify a registry setting outside the Policies keys.

As for what this means, an in-depth explanation can be found in the link I mentioned above, but I'll simplify for this situation. Most ADMX templates are created to manage registry settings belonging to specific applications. Some developers will anticipate this and create policies for their application. An example of such a developer is Adobe who create the following key for their Acrobat Reader: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockDown\cDefaultLaunchURLPerms.

These policies are recognized by the application and any changes made to them through Group Policy will supersede application settings while the original value will be remembered. When the GP object that modified the policy moves out of scope or is otherwise deleted, the original value is restored.

Preferences on the other hand aren't recognized. They modify registry keys set by an application, but the application is not aware of the modification. Once applied, the preference will overwrite existing keys and the application will simply use those values. Because the application isn't aware that its keys have been set by GP, users can overwrite those keys. The Group Policy engine will only reapply the setting when the GP changes, so any preferences set this way may not be permanent.

Paradoxically, they are permanent in another way: as the preference overwrites an existing key, that change will not be undone when the GPO is deleted. Because of this, preferences should always include the key values for the Disabled setting, so that changes can be undone. Remember that you'll have to set the key to a default value if you want to remove the changes made by the preference, as the original value was not saved and can't be recreated.

share|improve this answer
    
Answered myself as I eventually found what I believe to be the right answer. Documented it some more to help myself understand and so others (or me if I forget it again) can find it. –  Lilienthal Jul 31 '12 at 9:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.