Using Administrative Template Files with Registry-Based Group Policy

Download Using Administrative Template Files with Registry-Based Group Policy

On This Page

	Introduction
	Overview of Registry-Based Policy and Administrative Template Files
	Design Considerations for Creating Policy Settings
	How to Write a Simple .Adm File for Registry-based Group Policy
	Testing Administrative Template Files
	Maintaining and Managing .Adm Files
	What’s New for Administrative Template Files in Windows XP SP2
	Language Reference for Administrative Template Files
	Related Links

Introduction

Administrators can use Group Policy to deliver and apply one or more desired configurations or policy settings to a set of targeted users and computers within an Active Directory® directory service environment. The majority of available policy settings are provided through Administrative Template files (.adm files) and are designed to modify specific keys in the registry. This is known as registry-based policy. For many applications, the use of registry-based policy delivered by .adm files is the simplest and best way to support centralized management of policy settings.

Intended for IT administrators and developers, this document describes how to implement registry-based Group Policy by using .adm files.

For detailed instructions about enabling applications for Group Policy, see “Group Policy” in the Microsoft Platform Software Development Kit at http://go.microsoft.com/fwlink/?LinkId=26258.

Top of page

Overview of Registry-Based Policy and Administrative Template Files

By using registry-based policy, operating system components and applications can respond to registry key settings that administrators can manage centrally with Group Policy. These policy settings determine the behavior of the application for targeted computers or users. As long as a component or application has been policy-enabled (that is, its behavior changes based on registry values indicated in the .adm file), you can manage its features and settings through registry-based policy.

.Adm files are UNICODE text files that Group Policy uses to describe where registry-based policy settings are stored in the registry. All registry-based policy settings appear and are configured in the Group Policy Object Editor under the Administrative Templates node. .Adm files do not apply policy settings; they simply enable administrators to view the policy settings in the Group Policy Object Editor. Administrators can then create Group Policy objects (GPOs) containing the policy settings that they want to use. For example, you might have one GPO that contains various policy settings for managing the Active Desktop feature.

With the release of Microsoft® Windows XP Service Pack 2 (SP2), IT administrators have more than 1,300 Administrative Template policy settings available for their use. In addition, administrators and developers can add their own custom settings.

Registry-based Group Policy uses .adm files in the following manner:

  Note
Windows XP SP2 includes modifications to the LISTBOX ADDITIVE behavior in .adm files (implemented by a new version of gptext.dll, the .dll used by the Group Policy Object Editor.) For details about these changes, see the, “What’s New for .Adm Files in Windows XP SP2” section later in this document

For more information about the architecture of Administrative Templates, see Administrative Templates Extension Technical Reference at http://go.microsoft.com/fwlink/?LinkId=35291.

Default .adm Files

The Group Policy Object Editor displays the policy settings within the .adm files that are included with the operating system by default. These .adm files are:

Most Group Policy settings are contained in the System.adm file. The .adm files that ship with Windows Server 2003, Windows XP Professional, and Windows 2000 Server operating systems are located in the %windir%\inf\ folder. (for example, C:\Windows\inf). For more information about .adm file maintenance, see the “Maintaining and Managing .Adm Files” in this document.

When to Use Registry-Based Group Policy

In general, if a policy setting can be configured using a simple user interface, and any configuration input can be stored in the registry as plain text, you should consider using registry-based policy. Specifically, registry-based Group Policy is an appropriate solution for the following scenarios:

True Policies vs. Preferences

Group Policy settings that administrators can fully manage are known as “true policies.” In contrast, settings that users configure or that reflect the default state of the operating system at installation time are known as “preferences.” Both true policies and preferences contain information that modifies the registry on users’ computers. True policy settings take precedence over preference settings.

Registry values for true policies are stored under the approved registry keys as listed in Table 1. Users cannot change or disable these settings.

Table 1    Approved Registry Key Locations for Group Policy Settings

Preferences are set by the user or by the operating system at installation time. The registry values that store preferences are located outside the approved Group Policy keys listed in Table 1. They are located in other areas of the registry. Users can typically change their preferences at any time. For example, users can decide to change the location of their local dictionary to a different location, or set their wallpaper to a different bitmap. Most users are familiar with setting preferences that are available to them through the operating system or application user interface.

It is possible for an administrator to write an .adm file that sets registry values outside of the approved Group Policy registry trees included in Table 1. In this case, the administrator is only ensuring that a given registry key or value is set in a particular way. With this approach, the administrator configures preference settings, instead of true policy settings, and marks the registry with these settings (that is, the settings persist in the registry even if the preference setting is disabled or deleted).

If you configure preference settings by using a GPO in this manner, the GPOs that you create do not have Access Control List (ACL) restrictions. As a result, users might be able to change these values in the registry. When the GPO goes out of scope (that is, it is unlinked, disabled, or deleted), these values are not removed from the registry. In contrast to this, true registry policy settings do have ACL restrictions to prevent users from changing them, and the policy values are removed when the GPO that set them goes out of scope. For this reason, true policies are considered to be policy settings that can be fully managed. By default, the Group Policy Object Editor only shows policy settings that can be fully managed. To view preferences in the Group Policy Object Editor, you need to click the Administrative Templates node, click View, then click Filtering, and then clear Only show policy settings that can be fully managed.

Although Group Policy settings take priority over preferences, they do not overwrite or modify the registry keys used by the preferences. If a policy setting is deployed that conflicts with a preference, the policy setting takes precedence over the preference setting. If a conflicting policy setting is removed, the original user preference setting is restored.

How to Use Policy Settings and Preferences

Applications commonly include a user preference and a policy setting that perform similar or related  functions. For example, you might want to offer users the ability to configure part of a component through a user preference setting, and also centrally control this setting by using a registry-based policy setting.

An example of where both a policy and preference can co-exist is the configuration of the wallpaper on a Windows desktop. Users can set their desktop wallpaper to be displayed (or not displayed) by using the Display icon in Control Panel. You can also use a policy setting to configure desktop wallpaper.  To specify the desktop wallpaper that displays on users’ desktops, administrators can use the Active Desktop Wallpaper policy setting (found in the Group Policy Object Editor, under the User Configuration\Administrative Templates\Desktop\Active Desktop. As a result, the user can choose to display or not display the wallpaper, but the administrator can choose which wallpaper is displayed when the display setting is ON.

Table 2 lists the resultant behavior for Group Policy settings and preferences.

Table 2   Results of Group Policy Settings and Preferences

Top of page

Design Considerations for Creating Policy Settings

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.

When to Create Policy Settings

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

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:

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:

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:

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:

  Note
Policy names are limited to 256 characters. However, depending on the font used on the user’s workstation, a smaller number of characters are displayed, and all others truncated. On most systems, you can assume that you have the ability to display policy names up to 65 characters. (Using a Resolution of 1024 / 768 with small fonts installed).
When Group Policy names are translated into additional languages, they typically require additional characters. Therefore, if you are using English to name a Group Policy, limit the name to 49 characters. This limitation allows your title to grow by 33 percent during translation, without causing any truncation issues.

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.

  Note
Do not try to supplement a Group Policy setting title in the user interface with tip text that can be displayed in the user interface. Include any tips for using the policy setting in the Explain text.

Use the following guidelines when you create the Explain text:

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

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

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.

  Note
You need to enable the Active Desktop to use this setting.

  Note
This setting does not apply to Terminal Server sessions.

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:

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:

  Caution
Treat the .adm files that ship in the operating system as read-only files. These files are often updated when you install service packs or future releases of the product. Policy settings should never be removed from .adm files that are included in the operating system by default.

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:

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.

Top of page

How to Write a Simple .Adm File for Registry-based Group Policy

This section shows you how to create a simple .adm file for delivering registry-based Group Policy settings. The code samples provided are parts of a single .adm file. Please refer to “Language Reference for Administrative Template Files,” later in this document for full details about the .adm language.

The sections of the sample .adm file illustrate how to set a registry value to:

To Set a Registry Value to Turn a Feature ON or OFF

This sample code displays a check box. The value is set in the registry with the REG_DWORD type. By default, the check box is clear. If the check box is selected, it writes the value 1 to the registry. If the check box is clear, it writes the value 0 to the registry.

CLASS USER 
 
CATEGORY!!SampleCategory 
    KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Samples" 
 
    POLICY!!Sample_ADM_FeatureOnOff 
        #if version >= 4 
            SUPPORTED!!SUPPORTED_WindowsXPSP1 
        #endif 
        EXPLAIN!!Sample_ADM_FeatureOnOff_Help 
        VALUENAME "ADM_Sample_FeatureOnOff" 
            VALUEON 1 
            VALUEOFF 0 
    END POLICY 
END CATEGORY

To Set a Registry Value to Allow the Selection of One or More Values from a List

You can use DROPDOWNLIST to display a combo box with a drop-down style list. You can pre-populate the list of items that are displayed in the list and the corresponding registry value to be written for each item in the list.

POLICY!!Sample_ADM_DropDownList 
    #if version >= 4 
        SUPPORTED!!SUPPORTED_WindowsXPSP1 
    #endif 
    EXPLAIN!!Sample_ADM_DropDownList_Help 
    PART!!Sample_ADM_DropDownList DROPDOWNLIST REQUIRED 
        VALUENAME "Sample_ADM_DropDownList" 
            ITEMLIST 
             NAME !!Sample_ADM_DropDownList_Always    VALUE NUMERIC 1 DEFAULT 
             NAME !!Sample_ADM_DropDownList_WorkStationOnly    VALUE NUMERIC 2 
             NAME !!Sample_ADM_DropDownList_ServerOnly    VALUE NUMERIC 3 
         END ITEMLIST 
    END PART 
END POLICY

To Set a Registry Value to Display a List with Add and Remove Buttons

You can use registry-based Group Policy to display a list box that contains Add and Remove buttons.

By default, only one column appears in the list box, and for each entry, a value is created where the name and value are the same. For example, a name entry in the list box creates a value called name that contains data labeled name.

POLICY!!Sample_ADM_ListBox 
    #if version >= 4 
        SUPPORTED !!SUPPORTED_WindowsXPSP1 
    #endif 
    EXPLAIN!!Sample_ADM_ListBox_Help 
    PART!!Sample_ADM_DropDownList LISTBOX 
        KEYNAME "Sample_ADM_ListBox" 
    END PART 
END POLICY

To Set a Registry Value for EDITTEXT and Static Text

This setting allows the user to type alphanumeric text in an edit field. The text is set in the registry with the REG_SZ type.

The following code is an example of how you can use the EDITTEXT PART type.

POLICY!!Sample_ADM_EditText 
    #if version >= 4 
        SUPPORTED !!SUPPORTED_WindowsXPSP1 
    #endif 
    EXPLAIN!!Sample_ADM_EditText_Help 
    PART!!Sample_ADM_EditText EDITTEXT 
        VALUENAME "ADM_Sample_EditText" 
    END PART 
END POLICY

To Set a Registry Value for Displaying a Numeric List to the Administrator

To display a list of numbers from which administrators can select one of the predefined numeric values, you can use a NUMERIC PART type.

POLICY!!Sample_ADM_Numeric 
 
    #if version >= 4 
 
        SUPPORTED !!SUPPORTED_WindowsXPSP1 
 
    #endif 
 
    EXPLAIN!!Sample_ADM_Numeric_Help 
 
    PART!!Sample_ADM_Numeric NUMERIC 
 
        VALUENAME "ADM_Sample_Numeric" 
 
    END PART 
 
END POLICY

To Set a Registry Value for Displaying a Numeric List to the Administrator, Using SPIN Control

To display a list of numbers from which administrators can select one of the predefined numeric values, you can use a SPIN control.

POLICY!!Sample_ADM_Spinner 
    #if version >= 4 
        SUPPORTED !!SUPPORTED_WindowsXPSP1 
    #endif 
    EXPLAIN!!Sample_ADM_Spinner_Help 
    PART!!Sample_ADM_Spinner NUMERIC 
        VALUENAME "ADM_Sample_Spinner" 
        MIN 5 MAX 23 DEFAULT 14 SPIN 3 
    END PART 
END POLICY

To Set a Registry Value to Display an ActionList to an Administrator

To specify a set of arbitrary registry changes to make in response to a control being set to a particular state, you can use the ACTIONLIST option.

POLICY!!Sample_ADM_ActionList 
    #if version >= 4 
        SUPPORTED !!SUPPORTED_WindowsXPSP1 
    #endif 
    EXPLAIN!!Sample_ADM_ActionList_Help 
    ACTIONLISTON 
        KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Sample\ActionOnList" 
            VALUENAME "Action1" 
            VALUE NUMERIC 1 
        KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Sample\ActionOnList" 
            VALUENAME "Action2" 
            VALUE NUMERIC 7 
        KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Sample\ActionOnList" 
            VALUENAME "Action1" 
            VALUE NUMERIC 100 
    END ACTIONLISTON 
    ACTIONLISTOFF 
        KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Sample\ActionOnList" 
            VALUENAME "Action1" 
            VALUE NUMERIC 0 
        KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Sample\ActionOnList" 
            VALUENAME "Action2" 
            VALUE NUMERIC 0 
        KEYNAME "SOFTWARE\Policies\Microsoft\ADM_Sample\ActionOnList" 
            VALUENAME "Action1" 
            VALUE NUMERIC 0 
    END ACTIONLISTOFF 
END POLICY

Top of page

Testing Administrative Template Files

This section provides recommended procedures for testing .adm files. You should always test policy settings before deploying them in GPOs. Your test plan should examine and document the following for each policy setting:

First, test your new policy settings individually. Next, test how each policy setting interacts with other policy settings that are similar, or policy settings that are also designed to manage the affected component.

Suppose for example that you create a policy setting to configure the wallpaper that is displayed on your clients’ desktops. The list of policy settings that ship with Windows Server 2003 includes other wallpaper policy settings. In this scenario, you should test how these policy settings interact. Any issues that arise should be addressed or documented in the Explain text.

Testing should ensure that the user interface is policy-aware. If the user interface is not aware of the policy setting, the user experience might be confusing. For example, if your policy setting restricts access to a certain item in a component, then no access to this component and its configuration should be available in the user interface. Some ways to achieve this are:

Creating an .Adm Test File

To simplify testing, create a sample .adm file for your policy setting. By doing this step, you can isolate testing of the new policy settings until they are ready to be merged into a larger .adm file, if appropriate.

Your test plan should include the following validations:

Loading an .Adm File into the Group Policy Snap-in

After you create an .adm file, you can load it into the Administrative Templates section of Group Policy Object Editor by performing the following procedure.

To load your .adm file into Group Policy Object Editor

Top of page

Maintaining and Managing .Adm Files

This section provides guidance to ensure that your .adm files are properly configured for your administrative workstations.

Each domain-based GPO maintains a single folder in the Sysvol folder of each domain controller. This folder, known as the Group Policy template, contains all of the .adm files that were used in the Group Policy Object Editor when the GPOs were last created or edited.

Each Windows Server operating system includes a standard set of .adm files that are loaded by default into the Group Policy Object Editor. By default, the following .adm files are pre-loaded with a Windows 2000 or later operating system:

Windows Server 2003 and Windows XP include the following additional .adm files:

Importance of Timestamps for .Adm Files

Each administrative workstation that is used to run the Group Policy Object Editor stores its .adm files in the %windir%\Inf folder. When GPOs are created and first edited, the .adm files from this folder are copied to the Sysvol and replicated to all the domain controllers. This includes the standard .adm files and any custom .adm files that are created by the administrator.

  Note
If you create a GPO and do not edit it, you will create a Group Policy template without any associated .adm files.

By default, when you edit GPOs, the Group Policy Object Editor compares the timestamps of the .adm files in the workstation’s %windir%\Inf folder (local .adm files) with those that are stored in the Sysvol (these are the .adm files used by the GPO that is being edited). If the local .adm files are newer, the Group Policy Object Editor copies these files to the Sysvol, overwriting any existing files of the same name. This comparison occurs whenever the Administrative Templates node (under Computer or User Configuration) is selected in the Group Policy Object Editor, regardless of whether the administrator actually edits the GPO.

  Caution
Because of the importance of timestamps on .adm file management, it is recommended that you do not edit system-supplied .adm files. If a new policy setting is required, it is highly recommended that you create a custom .adm file. This prevents the override of system-supplied .adm files whenever service packs are released.

Duplicate CATEGORY Sections

If the .adm file that you add includes a duplicate CATEGORY to one that is used in an existing .adm file, the policy settings are merged.

An error can occur when the existing and the added .adm file contain the same CATEGORY, and both of them have a default KEYNAME specified (regardless of whether it is the same name). If these conditions are met, the following error message appears.

Key name specified more than once. Likely causes are: 1) the KEYNAME tag is defined multiple times in this category, 2) this KEYNAME is already defined in another category with the same name, 3) this KEYNAME is already defined in another category with the same name in a different .adm file.

.Adm Files Used by the Group Policy Object Editor

By default, the first time the Group Policy Object Editor is started for a specified GPO, it copies the System.adm file from the current computer’s %windir%\inf\ directory to the GPO.

Subsequently, only those .adm files specified in the list are displayed. Each time you open Group Policy Object Editor, the Group Policy Object Editor also checks the listed .adm files and copies any newer versions from the local computer's %windir%\inf\ directory to the GPO.

.Adm Files Used by GPMC

By default, GPMC always uses local .adm files, regardless of their time stamp, and it never copies .adm files to Sysvol. If an .adm file is not found locally, GPMC looks for the .adm file in the Sysvol. In GPMC, you can specify an alternative location for .adm files. If an alternative location is specified, this alternative location takes precedence.

Controlling .Adm File Replication

Because .adm files are stored in the Group Policy template by default, they increase the Sysvol folder size. The File Replication Service (FRS) replicates all of the .adm files for GPOs throughout the domain. If you edit GPOs frequently, you might experience a significant amount of replication traffic. You can use a combination of the Turn off automatic updates of adm files and Always use local adm files for Group Policy Object Editor policy settings to reduce the size of the Sysvol folder and policy-related replication traffic.

Turn Off Automatic Updates of .Adm Files

The Turn off automatic updates of adm files policy setting is available under User Configuration\Administrative Templates\System\Group Policy in Windows Server 2003, Windows XP, and Windows 2000 operating systems. When this policy setting is enabled, the updating of an existing GPO remains local to the administrative workstation, and .adm files are not sent from the local computer to the Sysvol.

  Note
In Windows 2000 operating systems, when you edit a GPO for the first time the local .adm files are uploaded to the Sysvol, without regard to how this policy setting is set. If this policy setting is enabled in Windows XP, .adm files are not uploaded when a GPO is edited for the first time. The first time that the GPO is edited might or might not be when the GPO is created.

Always Use Local .Adm Files for Group Policy Object Editor

The Always use local ADM files for Group Policy Object Editor policy setting is available under Computer Configuration\Administrative Templates\System\Group Policy in Windows Server 2003 and Windows XP Professional. When a GPO is created, this policy setting has no immediate effect, and the .adm files on the local computer are still uploaded to the Sysvol. However, when you edit an existing GPO, any .adm files that are stored in the Sysvol are ignored, and Group Policy Object Editor uses the .adm files from the local computer only. If a policy setting has been set in the GPO, but the corresponding .adm file that describes the policy setting is not available on the local computer, Group Policy Object Editor does not display that policy setting.

  Note
If this policy setting is enabled, the Turn off automatic updates of adm files policy setting is also implied.

To clear the Sysvol folder of .adm files

Maintaining .Adm files on Administrative Workstations

When you use the Always use local adm files for Group Policy Object Editor policy setting, make sure that each workstation has the latest version of the default and custom .adm files. If all .adm files are not available locally, some policy settings that are contained in a GPO will not be visible to the administrator. Avoid this by implementing a standard operating system and service pack version for all administrators. If you cannot use a standard operating system and service pack, implement a process to distribute the latest .adm files to all administrative workstations.

  Note
Because the workstation adm files are stored in the %windir%\Inf folder, any process that is used to distribute these files must run in the context of an account that has administrative credentials on the workstation.

Multilanguage Administration Issues

In some environments, policy settings must be presented to the user interface in several languages. Because the GPT folder can store only one set of .adm files, you cannot use the GPT folder to store .adm files for multiple languages.

For Windows 2000 operating systems, the use of local .adm files for the Group Policy Object Editor is not supported. If you are using Windows 2000, use the Turn off automatic updates of adm files policy setting. Because this policy setting has no effect on the creation of new GPOs, the local .adm files will be uploaded to the GPT folder in Windows 2000. Creating a GPO in Windows 2000 effectively defines the language of the GPO. If the Turn off automatic updates of adm files policy setting is in effect on all computers running Windows 2000, the language of the adm files in the GPT folder will be defined by the language of the computer that is used to create the GPO.

If you are using Windows 2000 workstations, use the Turn off automatic updates of adm files policy setting for administrators, and consider the adm files in the GPT folder to be the effective language for all Windows 2000 workstations.

For administrators who are using Windows Server 2003 and Windows XP operating systems, the Always use local adm files for Group Policy Object Editor policy setting can be used.  For example, this policy setting allows a French administrator to view policy settings by using the French .adm files that are installed locally, regardless of the adm file that is stored in the GPT folder. Note that when you use this policy setting, it is implied that the Turn off automatic updates of adm files policy setting is also enabled, to avoid unnecessary updates of the adm files to the GPT folder.

Consider standardizing on Windows Server 2003 for administrative workstations in a multi-language administrative environment. Configure both the Always use local adm files for Group Policy Object Editor and Turn off automatic updates of adm files policy settings.

Operating System and Service Pack Release Issues

Each operating system or service pack release includes a superset of the .adm files provided by earlier releases, including policy settings that are specific to operating systems that are different to those of the new release. For example, the .adm files that are provided with Windows Server 2003 include all policy settings for all operating systems, including those that are only relevant to Windows 2000 or Windows XP Professional. This means that only viewing a GPO from a computer with the new release of an operating system or service pack effectively upgrades the .adm files. Because later releases are typically a superset of previous .adm files this will not typically create problems, assuming that the .adm files that are being used have not been edited.

In some situations, an operating system or service pack release includes a subset of the .adm files that were provided with earlier releases. This has the potential to present an earlier subset of the .adm files, resulting in policy settings no longer being visible to administrators when they use Group Policy Object Editor. However, the policy settings will remain active in the GPO--only the visibility of the policy settings in Group Policy Object Editor is affected. Any active (either Enabled or Disabled) policy settings are not visible in Group Policy Object Editor, but remain active. Because the settings are not visible, it is not possible for the administrator to view or edit these policy settings. To work around this issue, administrators must become familiar with the .adm files that are included with each operating system or service pack release before using the Group Policy Object Editor on that operating system, keeping in mind that the act of viewing a GPO is enough to update the .adm files in the GPT, when the timestamp comparison determines an update is appropriate.

To plan for this in your environment, it is recommended that you either:

  Note
The Always use local adm files for Group Policy Object Editor policy is typically used with the Turn off automatic updates of adm files policy setting, (that is, when it is supported by the operating system from which you are running Group Policy Object Editor).

Keyboard Shortcuts for Administrative Templates Node

You can use the following keyboard shortcuts to navigate the Administrative Templates namespace:

When the Properties page appears, move it out from in front of the Group Policy Object Editor window. Then, click back one of the Policies in the results pane. You can now use the cursor keys to navigate up and down the list. Notice that the information in the Properties page changes. This method also works for the text on the Explain tab. You can also use the Tab key to move back and forth between the tree pane and the results pane, while leaving the Properties page open.

Top of page

What’s New for Administrative Template Files in Windows XP SP2

Windows XP SP2 includes modifications to tools used to administer Group Policy. This includes changes to the LISTBOX ADDITIVE behavior, which is implemented through an update to gptext.dll. This section includes details of these changes.

For information about managing new features released in Windows XP SP2, see Managing Windows XP Service Pack 2 Features Using Group Policy at http://go.microsoft.com/fwlink/?LinkId=31974.

Changes to LISTBOX ADDITIVE

Policy settings defined by the LISTBOX keyword allow you to manage multiple values under one registry key. When LISTBOX is used, the specified settings are written as a REG_SZ registry value type, which allows for multiple values to be stored within one registry key.

An example of the use of LISTBOX is the Windows Firewall: Define Port Exceptions policy setting, located in Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall, under both the Domain Profile and Standard Profile nodes.

By default, when LISTBOX policy settings are used in multiple GPOs, the list of the values written to the registry is defined entirely by the last GPO applied (“last writer wins”). The additive keyword changes the behavior so that the aggregate values from multiple GPOs are applied. For example, suppose that you have two GPOs with the following values for the Windows Firewall: Define Port Exceptions policy setting:

Without the additive keyword, only the values D, E, and F in GPO y are applied to the registry of targeted computers.  This is because GPO y is the last GPO applied. With the additive keyword, all of the values from both GPOs are applied: A, B, C, D, E, and F.

The LISTBOX ADDITIVE behavior in Windows XP with SP2 gives you more flexibility in determining the values that will be applied to targets in a given Active Directory container.  For example, the ability to disable policy settings from lower precedent GPOs is a key tenet of Group Policy management. Prior to Windows XP with SP2, the disabled behavior had no effect for policy settings that used LISTBOX ADDITIVE. Furthermore, prior to Windows XP with SP2, LISTBOX ADDITIVE was only found in several, rarely used policy settings affecting offline files. In Windows XP with SP2, LISTBOX ADDITIVE is used more prominently including policy settings that affect Windows Firewall and Internet Explorer.

Therefore, in Windows XP with SP2, the disabled behavior now functions as expected: removing any entries inherited from other lower precedent GPOs.

For example, suppose GPOs with values A, B, and C is normally applied to all computers in a domain. But, as an OU administrator, you wish to prevent these values from taking effect on computers in your OU. You can create a new GPO to disable values A, B, and C. This is illustrated in the following example:

In this scenario, the values D, E, and F are applied to the computers in your OU.

Because, the disabled functionality only works when using the latest version of the gptext.dll, all policy settings that use LISTBOX ADDITIVE are enclosed by the #if version > 5 ...#end if construct. This eliminates the possibility of having multiple administrators experiencing different disabled behavior if they are using earlier versions of gptext.dll. Consequently, the policy settings that use LISTBOX ADDITIVE are not visible when editing a GPO from a computer running Windows Server 2003, Windows XP with SP1, or Windows 2000 operating systems.

If you have administrative workstations that are not using Windows XP with SP2, you will need to install a hotfix in order to manage these policy settings. For more information, see the “‘String too long...’ Hotfix for Earlier Operating Systems or Service Packs” section later in this document.

Managing Policy Settings on Earlier Operating Systems or Service Packs

The .adm files that use the LISTBOX ADDITIVE syntax do not fully load on earlier versions of the Group Policy Object Editor (gpedit), which is present by default in Windows Server 2003, Windows XP with SP1, and Windows 2000. If attempted, multiple error messages will appear when the system.adm and inetres.adm files are loaded in earlier versions of gpedit.

The error message is "The following entry in the [strings] section is too long and has been truncated." This occurs because earlier versions of gpedit cannot correctly handle the “#if version >= 5 / #endif” construct in the inetres.adm and system.adm files. Although clicking OK on all the pop-up error messages does result in the .adm files loading correctly, the new Windows XP SP2 policy settings that use the LISTBOX syntax will not be displayed. (This problem does not occur on computers running Windows XP with SP2 or computers that have been updated with the latest version of gpedit.)

This issue is of particular significance because of the way .adm files are distributed through a domain. By default, when a GPO is opened, a comparison is made between the timestamps of the .adm files stored in the GPO being edited and those on the local computer. If the local .adm files have a more recent timestamp then they are uploaded to the domain controller and replicated throughout the domain. From that point, all earlier versions of gpedit use the new .adm files. This scenario is illustrated in the following steps.

“String Too Long...” Hotfix for Earlier Operating Systems and Service Packs

If you or other administrators in your organization are going to manage policy settings on computers running earlier operating systems or service packs (for example, Windows Server 2003 or Windows XP with SP1), you need to install a hotfix in order for policy settings to appear correctly in the Group Policy Object Editor.

These hotfixes are available for the following:

To obtain these hotfixes, see article 842933, ""The following entry in the [strings] section is too long and has been truncated" error message when you try to modify or to view GPOs in Windows Server 2003, Windows XP Professional, or Windows 2000," in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=4441.

If you are going to manage policy settings from workstation computers running Windows XP with SP2 only, you will be able to manage policy settings without applying any hotfixes. For example, you will be able to run the Group Policy Object Editor and view all the new policy settings delivered with Windows XP SP2.

  Important
Opening a GPO on a computer running Windows XP with SP2 causes all other administrative workstations to use the new .adm files (note that no changes need be made to the GPO for this to occur). This will generate error messages when earlier versions of gpedit are loaded. For more information about this issue, see article 842933, ""The following entry in the [strings] section is too long and has been truncated" error message when you try to modify or to view GPOs in Windows Server 2003, Windows XP Professional, or Windows 2000," in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=4441.

By installing the hotfix for Windows Server 2003, Windows XP with Service Pack 1, and Windows 2000, you ensure that the Windows XP SP2 .adm files load correctly on these platforms.

Top of page

Language Reference for Administrative Template Files

This section includes a complete reference guide for using the .adm language to create policy settings.

Each .adm file can contain zero or more policy settings, and each policy setting in turn can contain zero or more parts. The .adm language includes the following components:

.Adm File Language Versions

You can specify that any part of your .adm file be evaluated only in specific versions of the Group Policy editing tools. Table 5 lists the versions of the Group Policy editing tools.

Table 5   Versions of Group Policy Editing Tools

Comments

You can use two methods to add comments to an .adm file. You can precede the comment either with a semicolon (;) or with two forward slashes (//). You can place comments at the end of any valid line.

Strings

To add strings to an .adm file, precede the text with two exclamation points (!!). At the end of the .adm file, all strings must be defined in the [strings] section. The strings must be enclosed in quotation marks ("). Optionally, you can enclose a variable name or hard-coded string in quotation marks.

Example

POLICY 34]!!LimitSize 
   EXPLAIN!!LimitSize_Explain   ; This string is stored in the strings section 
   TIP1 “Limit Profile Size to”   ; This string is hard coded 
 
[strings] 
LimitSize="Limit profile size" 
LimitSize_Explain="Limits the size of user profiles"

Best Practice

Place all strings in the [strings] section of the .adm file. This facilitates conversion of the .adm file to other languages (that is, for localization), as you only need to modify the [strings] section of an .adm file to port it to different languages.

CLASS

This component defines where your policy setting is displayed in the Group Policy Object Editor.

The first entry in the .adm file is the keyword CLASS. This specifies whether the subsequent entries should be displayed under the Computer Configuration or User Configuration node of Group Policy Object Editor.

Syntax

The CLASS syntax is as follows:

CLASS name

Name

This defines the name of the CLASS, which must be MACHINE or USER.

If the .adm file contains a CLASS other than the valid classes (MACHINE or USER), the errors are ignored when loaded in Group Policy Object Editor.

Example

The following examples illustrate the use of the CLASS component.

CLASS MACHINE 
CLASS USER

  Note
You can define multiple CLASS USER or CLASS MACHINE sections in an .adm file. When the file is processed, all the CLASS USER sections are merged, and all CLASS MACHINE sections are merged. However, for ease of ongoing .adm file management, it is recommended that you define CLASS USER or CLASS MACHINE once.

CATEGORY

After you define the CLASS component, you can use the CATEGORY component to display a node name under which your policy setting is displayed in the Group Policy Object Editor.

  Note
You can create child nodes by nesting a CATEGORY within another CATEGORY.

Syntax

To specify a CATEGORY, use the following syntax.

CATEGORY!!name 
    KEYNAME key name 
    [policy definition statements] 
END CATEGORY

name

The CATEGORY name as it should appear in the Group Policy Object Editor list box. Optionally, you can enclose the variable name in quotation marks ("). Names with spaces must be enclosed in quotation marks.

key name

The key name is an optional path to the registry key to use for the CATEGORY.

Do not use HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER in the registry path as the preceding CLASS statement specifies the keys to use. If you specify a key name, all child categories, policies, and parts will use this key name, unless they specifically provide a key name of their own. Names with spaces must be enclosed in double quotation marks.

If a key name is not specified and if no higher level category specifies a key name, each policy in this category must specify its own key name: otherwise, the key name for the next category that does specify a key name will be used.

policy definition statements

A CATEGORY can include zero or more POLICY statements. A POLICY definition statement cannot appear more than once within a single category, as shown in the following sample code.

Example

CLASS USER 
 
; The following categories will be displayed 
; under User Configuration 
 
CATEGORY !!Desktop 
   KEYNAME "Software\Policies\System" 
 
   ; <INSERT POLICIES HERE> 
 
   CATEGORY !!InternalApps 
   KEYNAME "Software\Policies\InternalApps" 
 
    ; <INSERT POLICIES HERE> 
 
   END CATEGORY 
END CATEGORY 
 
[strings] 
Desktop="Desktop Settings" 
InternalApps="Line of Business Apps settings"

Supported Tag

The Group Policy Object Editor uses the Supported tag to populate the Requirements field. This tag informs the Group Policy administrator about the platforms or applications for which the policy setting is supported. For example, many of the policy settings included in the System.adm file use a Supported tag that specifies a specific service pack release. Often, the string used for the Supported tag will make reference to multiple operating system or service packs.

While operating system components generally use an operating system or service pack reference in this field, applications – which can be updated outside the release of a service pack – can refer to a specific version of an application. The Supported tag is an essential element in the data presented to Group Policy administrators to ensure they are equipped with the right information to make informed decisions about the use of the policy setting.

Because your .adm file may be localized, it is highly recommended that the Supported tag use the !!Stringname construct, which allows the referenced string to be localized easily. In addition, since the Supported tag is only supported in Windows XP and later operating systems, it should be enclosed within a Version construct, as follows (this ensures that the Windows 2000 version of Group Policy Object Editor does not attempt to interpret the Supported tag):

#if version >= 4 
        SUPPORTED!!SUPPORTED_MyApplication 
    #endif

CATEGORY Keywords

The valid keywords for CATEGORY are:

  Note
If you have a CATEGORY defined with a default KEYNAME in it, and the same category is found again later in the .adm file, that same default KEYNAME is still in effect. This means that you can get an error message about KEYNAME being defined twice, when it was actually just defined in the same category earlier. To remove the error condition, remove the duplicate category entry.

POLICY

To identify a policy setting that the user can modify, use the keyword POLICY. The policy and its associated controls are displayed in a dialog box that administrators use to set the state of the policy. You can use multiple POLICY key names under one KEYNAME.

The following examples illustrate the syntax of POLICY.

Syntax

POLICY name 
   [KEYNAME key name] 
   [EXPLAIN help string] 
   [VALUENAME value name] 
   [CLIENTEXT guid] 
   [part definition statements] 
END POLICY

name

The name of the policy as it should be displayed in the Group Policy Object Editor namespace.

key name

This is an optional path to the registry key to use for the category. Do not include HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER in the registry path as the preceding CLASS statement determines which of these keys is used.

If you specify a key name, all PART definition statements will use this key name unless they specifically provide a key name of their own.

If a key name is not specified and if no higher level category specifies a key name, each policy in this category must specify its own key name: otherwise, the key name for the next category that does specify a key name will be used.

help string

The Help string is the text displayed in the Explain tab of the dialog box for the policy setting.

value name

Value name is the registry value to modify. Selecting this option sets the value as a REG_DWORD of 1. Clearing the option removes the registry value. To specify values other than the default values, use the VALUEON and VALUEOFF statements directly following the corresponding VALUENAME statement. These statements are specified as follows:

VALUEON on value 
VALUEOFF off value

When you use these statements, the behavior is modified such that if the administrator selects the option, the value is set to on value. If the administrator clears the option, the value is set to off value.

guid

This is an optional value that specifies the globally unique identifier (GUID) of the snap-in extension.

part definition statements

A policy can contain zero or more PART statements to specify various options, including drop-down list boxes, text boxes, and text in the lower pane of the Group Policy Object Editor.

POLICY Example

CLASS MACHINE 
 
CATEGORY!!DiskQuota 
 
   KEYNAME "Software\Policies\MS\DiskQuota" 
 
   POLICY!!DQ_Enable 
      EXPLAIN !!DQ_Enable_Help 
      VALUENAME "Enable" 
         VALUEON  NUMERIC 1 
         VALUEOFF NUMERIC 0 
      CLIENTEXT {3610eda5-77ef-11d2-8dc} 
 
      PART!!DQ_EnableTip1    TEXT     
      END PART 
   END POLICY 
 
END CATEGORY 
 
[strings] 
DiskQuota="Disk Quotas" 
DQ_Enable="Enable disk quotas" 
DQ_Enable_Help="Enables and disables disk quota management" 
DQ_EnableTip1="Enable disk quotas for all NTFS volumes"

POLICY Keywords

The valid keywords for POLICY are:

PART

Use PART to specify various options, such as drop-down list boxes, text boxes, and text in the lower pane of Group Policy Object Editor.  

For a simple policy where you only need to set a registry key to either 1 or 0, you do not need to use PART. PART allows a richer system administrator experience, and collects more information from the administrator through simple controls.

Syntax

PART name part-type type-dependent data 
  [KEYNAME key name] 
  [VALUENAME value name] 
END PART

name

Specifies the PART name as it should appear in Group Policy Object Editor. You can enclose it in quotation marks ("). Names with spaces must be enclosed in quotation marks (").

part-type

A policy PART type. Table 6 lists the valid types for POLICY.

Table 6   Policy PART Types

type-dependent data

This is information about the PART.

key name

This is an optional path to the registry key to use. Do not include HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER in the registry path as the preceding CLASS statement determines which of these keys is used.

If no key name is specified, the previous key name in the hierarchy is used.

value name

The value name indicates the registry value to modify. Selecting this option sets the value to a REG_DWORD of 1, and clearing the option removes the registry value. If you want to specify values other than the default values, use the VALUEON and VALUEOFF statements directly following the corresponding VALUENAME statement. You specify these statements as follows:

VALUEON on value 
VALUEOFF off value

Keywords

The valid keywords for PART are:

Using PART Types to Add Controls to the User Interface

Using the valid keywords along with the PART component allows you to add text and various user interface controls to the properties page of the policy.

Because much of the syntax is related, the next section presents a task-based approach to writing the syntax for these PART types used to create the user interface elements above.

Using the different PART types, you can add text and controls to enhance a policy setting. These types need to be used with the PART component as previously defined.

CHECKBOX PART Type

This PART type displays a check box on the Property page of a policy setting. The value is set in the registry with the REG_DWORD type. The default behavior is as follows:

Syntax

PART text CHECKBOX 
   VALUENAME value name  
END PART

text

This represents the text to be displayed on the right of the check box that you are creating. You can hard code it and enclose it in quotation marks (") or you can make the string a variable by putting !! in front of the variable name.

value name

Indicates the registry value to which the selected value will be written. Selecting the option sets the value as a REG_DWORD of 1. Clearing the option removes the registry value. To specify values other than the default values, use the VALUEON and VALUEOFF statements directly following the corresponding VALUENAME statement. These statements are specified as follows:

VALUEON on value 
VALUEOFF off value

When you use these statements, the behavior is modified such that if the administrator selects the option, the value is set to on value. If the administrator clears the option, the value is set to off value.

To override the default behavior:

To have the check box selected by default use DEFCHECKED. In the preceding sample, the syntax would be:

PART !!SampleChkBox_NotChked CHECKBOX 
         DEFCHECKED 
           VALUENAME "test1" 
    END PART

You can use VALUEON and VALUEOFF. This example accomplishes the following::

PART !!SampleChkBox_NotChked CHECKBOX 
     VALUENAME "test1" 
     VALUEON “Enabled”  
     VALUEOFF NUMERIC 12    
   END PART

To modify more than one registry key, use an ACTIONLIST.

The valid keywords for CHECKBOX are:

TEXT PART Type

The PART type TEXT can be used to display text on the Property page of a policy setting. Text uses the following syntax.

PART text TEXT 
END PART

text

Text that is to be displayed is entered here. You can hard code it and enclose it in quotation marks ("), or you can make the string a variable by putting !! before the variable name.

The following example illustrates the use of TEXT. The Disable Active Desktop policy deactivates Active Desktop and prevents users from enabling or disabling Active Desktop, or from modifying the configuration.

TEXT Example

POLICY !!NoActiveDesktop 
 
   KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" 
   EXPLAIN!!NoActiveDesktop_Help 
     VALUENAME "NoActiveDesktop" 
 
     PART !!NoActiveDesktop_Tip    TEXT     
     END PART 
 
END POLICY

The valid keyword for TEXT is END.

EDITTEXT PART Type

The EDITTEXT option allows the user to input alphanumeric text into an edit field. The text is set in the registry with the REG_SZ type.

Syntax

PART !!text EDITTEXT 
   VALUENAME value name 
END PART

text

Text to be displayed is entered here. You can hard code it and enclose it in quotation marks (") or you can make the string a variable by putting two explanation points (!!) before the variable name. This text is displayed on the left side of the edit box.

value name

The value name indicates the registry value to which the users input entered in the Edit Text box will be written.

Table 7 lists the options for EDITTEXT.

Table 7   Options for EDITTEXT

The valid keywords for EDITTEXT are:

EDITTEXT Example

An example of use of the PART component with EDITTEXT and TEXT follows:

CLASS USER 
CATEGORY !!DesktopLockDown 
 
  KEYNAME "Software\Policies\System" 
   POLICY !!Wallpaper    
    EXPLAIN !!Wallpaper_Explain 
 
     PART !!Wallpaper_Tip1       TEXT 
     END PART 
 
     PART !!Wallpaper_Filename   EDITTEXT 
        VALUENAME Wallpaper 
        MAXLEN 60 
     END PART 
 
   END POLICY 
 
END CATEGORY 
 
[strings] 
DesktopLockDown="Desktop Settings" 
Wallpaper="Desktop Wallpaper" 
Wallpaper_Explain="Used to set the desktop wallpaper" 
Wallpaper_FileName="Filename" 
Wallpaper_Tip1="Specify UNC Path for selected wallpaper"

In the preceding example, the text entered into the edit field is written to the registry key HKEY_CURRENT_USER\Software\Policies\System\Wallpaper. The text can be a maximum of 60 characters.

When this policy setting is Not Configured or Disabled, this key is not written.

EXPANDABLETEXT Example

The following example writes a value to registry with data type REG_EXPAND_SZ.

For example:

PART!!MyVariable    EDITTEXT EXPANDABLETEXT 
VALUENAME ValueToBeChanged 
END PART

REQUIRED Example

The following example generates an error if the user does not enter a value when required.

PART!!MyVariable    EDITTEXT REQUIRED 
  VALUENAME ValueToBeChanged 
END PART

MAXLEN Example

The following example specifies the maximum length of text.

PART!!MyVariable    EDITTEXT 
  VALUENAME ValueToBeChanged 
  MAXLEN 4 
END PART

DEFAULT Example

The following example specifies a default value. This can be used for text or numeric data.

PART!!MyVariable    EDITTEXT 
  DEFAULT !!MySampleText 
  VALUENAME ValueToBeChanged 
END PART

NUMERIC PART Type

Displays an edit field with an optional spinner control (an up-down control) that accepts a numeric value.

NUMERIC Syntax

PART text NUMERIC  
   VALUENAME value name  
   MIN value  
   MAX value 
   DEFAULT value 
   SPIN value  
END PART

text

This represents the text to be displayed on the right of the spin control that you are creating. You can hard code it and enclose it in quotation marks (") or you can make the string a variable by putting !! before the variable name.

value name

Indicates the registry value to which the selected value will be written.

NUMERIC Default Behavior

The default behavior for the NUMERIC PART type is as follows:

Table 8 shows the options for the NUMERIC type.

Table 8   Options for NUMERIC

The valid keywords for NUMERIC are:

Examples of NUMERIC Use

The following example illustrates use of the NUMERIC PART type using the DEFAULT option.

PART!!MyVariable    NUMERIC 
  DEFAULT 5 
  VALUENAME ValueToBeChanged 
END PART

The following example illustrates use of the minimum and maximum valid values for a variable.

PART!!MyVariable    NUMERIC 
  MIN 100 
  MAX 999 
  DEFAULT 55 
  VALUENAME ValueToBeChanged 
END PART

The following example illustrates use of the NUMERIC PART type using SPIN. In this case, increments of 100 are used for the spin control.

PART !!ProfileSize    NUMERIC REQUIRED SPIN 100 
 
        VALUENAME "MaxProfileSize" 
        DEFAULT 30000 
        MAX     30000 
        MIN     300 
END PART

The following example illustrates use of the NUMERIC PART type using the TXTCONVERT option,