Design Considerations for Creating Policy Settings

Applies To: Windows Server 2003

This section addresses essential issues for creating and configuring custom policy settings in .adm files.

Use the following questions as a guide to help you design Group Policy settings.

• What is the default behavior (that is, when the policy is set to Not Configured)?

• What is the behavior when the policy is Enabled, Disabled, or Not Configured? The Enabled behavior should always be the opposite of the default behavior (that is, Not Configured).

• Do administrators need to explicitly disable a feature?

• Do the proposed policy settings affect users or computers or both?

• What are some potential future ramifications of the new policy settings? When new products are released, you must continue to maintain the previous .adm settings to manage computers running legacy software. New products and settings must be able to co-exist with earlier versions.

When to Create Policy Settings

An administrator should consider creating a policy setting for the following purposes:

• To help administrators manage and increase security of their desktop computers.

• To hide or disable a user interface that can lead users into a situation in which they must call the helpdesk for support.

• To hide or disable new behavior that might confuse users. A policy setting created for this purpose allows administrators to manage the introduction of new features until after user training has taken place.

• To hide settings and options that might take up too much of users' time.

Controlling Feature Releases to Users

An administrator can use .adm files to provide policy settings to manage new features of a new or updated application. By creating a single GPO for all new features, or by creating a GPO for each logical grouping of new features, an administrator can reduce the need for support and potential user frustration. A GPO should also be considered for specific features that administrators need to control after the new features have been enabled.

By enabling policy settings in this area, the administrator can control how and when users get new product features. By grouping related features, the administrator can prevent users from using a new feature set until they have been trained.

Create Policy Settings to Reduce Need for Support

To reduce the need for support, administrators can start by determining the top issues that users have and considering ways in which they can use policy settings to prevent support calls. For example, you could use policy settings to control software settings in the following scenarios:

• When proper configuration settings require advanced knowledge of the application.

• When there are complicated or advanced configuration settings that the typical user does not need to use.

In these scenarios, it would be appropriate to use Group Policy to give an administrator the ability to control access to the configuration settings.

Control Data

You can create policy settings to populate data for your application. Such data usually exists in small sets in the form of numbers, text strings, and so on. For example, a phone dialer could use policy settings to enable administrators to mandate that certain items exist in the phone directory.

When Not to Create a Policy

Although registry-based Group Policy provides an effective way of managing components and applications, there are some circumstances where its use is not recommended. For example:

• Do not create a policy for all of your application settings because large applications typically contain hundreds or even thousands of settings, and only a subset of these needs to be managed through Group Policy. Be selective about the features you want to enable or disable. Because Group Policy provides centralized management of the setting, you should evaluate whether administrators would want this kind of management before adding the policy setting.

• Do not create a policy if you do not intend to provide support for the policy setting. Treat each policy as a feature that needs to be tested, validated, and supported.

User Interface Design

Effective policy settings should be clearly written and displayed. You must also ensure that the user interface is clear and easy to understand. For example, review these user interface design options for disabling My Network Places:

• Create an error message. For example, the user clicks My Network Places and the following error message appears: "This option has been disabled by your administrator." In response, the user calls the administrator or support desk to ask why this feature has been disabled.

• Disable the user interface. For example, a user interface feature in My Network Places is disabled (grayed-out). This implies to the user that there is a way to enable the user interface. In response, the user might spend a lot of time trying to get this feature to work. In the end, the user might either give up in frustration or call the support desk.

• Hide the user interface feature. For example, a user interface feature in My Network Places is hidden. In response, the user does not recognize that anything is missing or unavailable. This is the preferred choice in this scenario.

• Do nothing. For example, when a user clicks My Network Places, and the screen does not change (that is, nothing happens). In response, the user assumes that something is wrong and calls the support desk.

Policy Names

You set the name of the policy setting at the same time that you create it. The name of the policy setting is displayed in the Group Policy Object Editor. Use the following guidelines for creating policy names:

• Use a verb that reflects the effect of the policy setting. Examples of verbs commonly used in policy setting names include: allow, permit, turn on, prohibit, hide, and prevent.

• Do not use the terms "enabled" or "disabled" in your policy setting names. Instead, consider using the terms "turn on" and "turn off," or "allow" and "prevent."

• Avoid overly technical jargon that might not be understood by administrators who are not experts in a particular component. Include technical details of the policy setting in the Explain text.

• Use short, descriptive names that accurately reflect the function of the policy setting, for example, Turn off Internet File Association service.

Explain Text

Explain text provides information about the behavior of the policy setting, its interaction with other policy settings, and can include any other information that you would like administrators to be aware of. When an administrator selects a policy setting, and then clicks the Explain tab, the Explain text appears in the policy setting's Properties dialog box. Explain text is limited to a maximum of 4096 characters, and Category Explain text is limited to a maximum of 256 characters.

Use the following guidelines when you create the Explain text:

• Draft the Explain text soon after creating the specification document for the policy setting. This serves as a high-level roadmap for developers, and assists testers in creating a test plan for the policy.

• Make sure your documentation team is available to help create the Explain text.

• Target the Explain text to the Group Policy administrator, rather than the end user.

Use the following template for the Explain text, and make sure that you include the following items:

• Write a one- or two-line description of the policy setting.

• Write a one- or two-line description of the feature that the policy setting affects.

• Use separate paragraphs within your Explain text for each policy setting state, as follows:

• If you enable this policy setting...<describe enabled behavior>.

• If you disable this policy setting...<describe disabled behavior>.

• If you do not configure this policy setting...<describe default behavior>.

• Include tips for using the policy setting.  

• Include notes or interactions that this policy has with other settings.  

As a best practice, you should also provide information about the following:

• Items that are not covered by this policy setting.

• Any other policy settings that are required for your policy setting to function.

• Any other policy settings that are related to the same component that your policy setting affects and which may have a higher or lower priority. For example, if you have a policy setting to restrict access to the LAN settings for a computer. This policy setting takes priority over more specific policy settings regarding the actual items you can configure within a LAN connection.

• Any related policies that the administrator needs to be aware of.

The following Explain text is from the Active Desktop Wallpaper policy setting in the User Configuration\Administrative Templates\Desktop\Active Desktop. This policy setting controls the desktop background (wallpaper) that is displayed on users' desktops.

Specifies the desktop background ("wallpaper") displayed on all users' desktops.

This setting lets you specify the wallpaper on users' desktops and prevents users from changing the image or its presentation. The wallpaper you specify can be stored in a bitmap (*.bmp), JPEG (*.jpg), or HTML (*.htm, *.html) file.

To use this setting, type the fully qualified path and name of the file that stores the wallpaper image. You can type a local path, such as C:\Windows\web\wallpaper\home.jpg or a UNC path, such as \\Server\Share\Corp.jpg. If the specified file is not available when the user logs on, no wallpaper is displayed. Users cannot specify alternative wallpaper. You can also use this setting to specify that the wallpaper image be centered, tiled, or stretched. Users cannot change this specification.

If you disable this setting or do not configure it, no wallpaper is displayed. However, users can select the wallpaper of their choice.

Also, see the "Allow only bitmapped wallpaper" in the same location, and the "Prevent changing wallpaper" setting in User Configuration\Administrative Templates\Control Panel.

Best Practices for Developing Registry-Based Policy Settings

It is strongly recommended that you do not try to create a single policy setting to control all aspects of your component. Group Policy is easier to implement and use if you have several smaller policy settings. This approach gives you more flexibility in designing and modifying your policy settings.

All policy settings should have an associated behavior for each of the three possible states shown in Table 3:

Table 3   Policy States and Associated Behaviors

Consider the following guidelines when you design your policy settings:

• Policy settings are never removed from the .adm files supplied by Windows operating systems. Even if subsequent versions of Windows no longer support the policy setting, Microsoft will continue to include that policy setting in .adm files for all future Windows operating systems that support Group Policy.

• Computer policy settings should override user policy settings.

• The Enabled behavior should be the opposite of the default behavior. For example, if a feature is on by default, the policy setting should be named using something like "Turn off <feature>", for example, Turn off reminder balloons. By default, reminder balloons are displayed when the Offline Files feature is enabled; they are used to notify users when they have lost the connection to a networked file and are working on a local copy of the file. If Turn off reminder balloons is set to Enabled, the system hides the reminder balloons, and prevents users from displaying them.

• Consider whether administrators need to explicitly disable a feature. You must understand the differences between the Not Configured state (which implies that the administrator does not care) and the Disabled state (which means that the administrator cares and wants to implement a very specific behavior).

• Make sure that your documentation team is involved with creating the Explain text. Well-written Explain text can help reduce support calls.

• Each component should expose a user interface that always reflects the policy setting that is applied. For example, if a Group Policy setting removes the ability for the user to set a preference for a component, the user interface should clearly indicate this and access to that particular item in the component should be removed (for example, the item is disabled and grayed-out, or it is not visible to users).

Creating Custom .Adm Files

You can create custom .adm files to extend the use of registry-based policy settings to new applications and components. Creating and implementing custom .adm files involves the following tasks:

• The application or component must be enabled to use Group Policy-enabled. Many off-the-shelf applications for Windows are already Group Policy-enabled. For example, Microsoft Office is developed to work with Group Policy settings, and applicable .adm files are included in the Office Resource Kit. If a developer's application is not already Group Policy-enabled, the developer must write code that changes the application so that an administrator can apply the application-specific Group Policy settings. For more information, see Microsoft Platform Software Development Kit at https://go.microsoft.com/fwlink/?LinkId=20540.

• After the application or component is Group Policy-enabled, a developer or administrator must write an .adm file that includes the appropriate settings for that application. Custom .adm files are created as text files that describe policy settings. A framework language is provided for .adm files, as described in "Language Reference for Administrative Template Files" later in this document. When you create a new policy setting in a custom .adm file, it is more efficient if you copy and modify existing policy settings that are similar to the ones that you want to create, rather than write new policy settings from scratch. To use an existing .adm file as a template for a custom .adm file, first copy the original .adm file into a new file with a different file name, and then edit the new file. Similar policy settings can provide:

  • A model to use as a basis for your Group Policy settings.

  • Consistency with available policy settings.

  • Information about possible interactions between policies.

• Administrators use the Group Policy Management Console to view and manage GPOs and use the Group Policy Object Editor to view the Administrative Templates node under Computer Configuration or User Configuration.

Keep in mind that by itself, the .adm file does not actually apply Group Policy to the client computer. You must have a corresponding component or application that responds to the registry key that is affected by the policy setting.

The following code example illustrates a simple .adm file.

CLASS USER 
 
CATEGORY !!DesktopLockDown 
 
    POLICY !!DisableTaskMgr     
       EXPLAIN !!DisableTaskMgr_Explain 
       VALUENAME "DisableTaskMgr" 
       VALUEON NUMERIC 1 
       VALUEOFF NUMERIC 0 
       KEYNAME "Software\Policies\System" 
    END POLICY 
END CATEGORY 
[strings] 
DisableTaskMgr="Disable Task Manager" 
DisableTaskMgr_Explain="Prevents users from starting Task Manager" 
DesktopLockDown="Desktop Settings"

This sample code exists in the System.adm file. It allows you to configure a policy called Disable Task Manager, which appears in the Group Policy Object Editor namespace in User Configuration\Administrative Templates\Desktop Settings.

This policy setting defines the following behavior:

• If an administrator enables this policy setting, it creates a registry key called DisableTaskMgr and set its value to 1. The VALUEON tag implements this behavior. In this case, users cannot start Task Manager.

• If an administrator disables this policy setting, it creates a registry key called DisableTaskMgr and set its value to 0. The VALUEOFF tag implements this behavior. In this case, users can start Task Manager.

• In both cases, the DisableTaskMgr registry key is created below HKCU\Software\Policies\System in the registry. Note that the key is created under CLASS USER and not under CLASS MACHINE because this is a user policy setting.

• If an administrator sets this policy setting to Not Configured, it deletes the registry key called DisableTaskMgr. In this case, users can start Task Manager.

Table 4 lists where registry-based policy settings are stored in any of the four approved registry locations for Group Policy.

Table 4    Approved Registry Key Locations for Group Policy Settings

The registry keys are created when a GPO containing an enabled or disabled registry-based policy setting is applied. If the GPO is later removed (for example, unlinked from an OU in which a user resides), the registry keys associated with it are also removed. Security prohibits a standard user from changing the registry keys. A local administrator can overwrite these registry keys, and thus change or disable the behavior of the policy setting. For this reason, as a Group Policy administrator, you might want to enable the Registry policy processing policy setting (located in Computer Configuration\Administrative Templates\System\Group Policy) and select the following option: Process even if the Group Policy objects have not changed.

Selecting this option updates and reapplies the policy settings even if you -- the Group Policy administrator -- have not changed the policy settings. This provides an additional safeguard in the event that local administrators try to change policy settings through the registry. Policy settings are reapplied during the regular background refresh of Group Policy, which occurs by default every 90 minutes with a randomized delay of up to 30 minutes.