Creating on/off or yes/no functionality. You can use .adm file settings to act as a switch to turn functionality on or off. It is common for desktop features and functions to be controlled in this manner.

Defining a set of static modes. For example, you can set the language used on a computer. You can set up a static list of language selections, and when the policy setting is enabled, the administrator can select a language from that list. This action is typically shown in the user interface as a drop-down list.

Creating a policy setting that requires simple input that can be stored in the registry as plain text. For example, you can create a policy setting to define the screensaver or bitmap that is displayed on the user’s desktop. With this policy setting enabled, Group Policy administrators see a text dialog box into which they can type the name and path of the bitmap file to be used. This information is then stored in the registry as plain text.

To help manage and increase security of desktop computers.

To hide or disable a user interface option that can lead users into a situation that requires Help Desk support.

To hide or disable new behavior that might confuse users. This allows the Help Desk to gradually introduce these new features until all users can be trained properly.

To hide settings and options that tend to distract users or are too complex for them to configure without assistance from the Help Desk.

Implementing the entire list of settings and options for a large application. Large applications can contain hundreds or thousands of settings, which can slow down GPO processing and restrict users’ ability to configure the application to their own needs. Be selective about the features you enable or disable. You should implement only a subset of the available options, based on whether an administrator would want this kind of management over the application.

Implementing unsupported policy settings. You should only implement .adm file settings that will be fully tested, validated, and supported.

Do not alter the standard .adm files. This includes removing settings within the standard .adm files or adding new settings to them. Subsequent versions of the .adm files (released through updates or service packs) will add the settings back and overwrite any new custom settings.

Remember that computer policy settings always override user policy settings when they conflict.

Consider making the enabled behavior of all .adm file settings the opposite of what the default behavior exhibits. This will keep the configurations within the policy setting consistent with the default behavior of Windows.

Note

This design might make some settings work as a "double negative," but it keeps the consistency of the default behavior and Enabled state in tact. The Explain text that you include with your setting will help clarify what the Enabled and Disabled configurations produce.

Provide a thorough and detailed Explain tab. Well-written Explain text can help reduce support calls and troubleshooting for custom .adm file settings.