Tài liệu Using Administrative Template Files with Registry- Based Group Policy pdf

Using Administrative Template Files with RegistryBased Group Policy Microsoft Corporation Published: September 2004 Abstract This white paper explains the concepts, architecture, and implementation details for registrybased Group Policy in Microsoft® Windows® operating systems It shows how to create custom Administrative Template (.adm) files and includes a complete reference for the adm language In addition, it includes information about changes in adm files for Windows XP with Service Pack (SP2) The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication This White Paper is for informational purposes only MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT Complying with all applicable copyright laws is the responsibility of the user Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred © 2004 Microsoft Corp All rights reserved Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries The names of actual companies and products mentioned herein may be the trademarks of their respective owners Table of Contents 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 16 Testing Administrative Template Files 20 Maintaining and Managing Adm Files 22 What’s New for Administrative Template Files in Windows XP SP2 .28 Language Reference for Administrative Template Files 31 Related Links 57 Introduction 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 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 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 (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 Language Reference for Administrative Template Files 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 Registry-based Group Policy uses adm files in the following manner: • The Group Policy Object Editor reads the adm files By default, when an administrator opens a GPO, 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 • The Group Policy Object Editor console (gpedit.msc) displays the settings, and, depending on the adm file, the policy settings can be displayed in a localized language • The Group Policy Object Editor uses adm files to configure user interface settings such as dialog boxes, radio buttons, and drop-down lists, thereby enabling administrators to manage these settings centrally • The Group Policy Management Console (GPMC) uses adm files to display policy settings when using Group Policy Results or Group Policy Modeling, also known as Resultant Set of Policy (RSoP) 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: • System.adm Provides policy settings to configure the operating system System.adm is installed by default in Windows Server™ 2003, Windows XP, and Windows 2000 Server operating systems • Inetres.adm Provides policy settings to configure Internet Explorer Inetres.adm is installed by default in Windows Server 2003, Windows XP, and Windows 2000 Server operating systems • Wuau.adm Provides policy settings to configure Windows Update Wuau.adm is installed by default in Windows Server 2003, Windows XP Service Pack (SP1), and Windows 2000 Server Service Pack (SP3) operating systems • Wmplayer.adm Provides policy settings to configure Windows Media Player Wmplayer.adm is installed by default in Windows Server 2003 and Windows XP operating systems Wmplayer.adm is not available on 64-bit versions of the Windows Server 2003 operating system and Windows XP 64-Bit Edition Using Administrative Template Files with Registry-Based Group Policy • Conf.adm Provides policy settings to configure NetMeeting Conf.adm is installed by default in Windows Server 2003, Windows XP, and Windows 2000 Server operating systems Conf.adm is not available on 64-bit versions of the Windows Server 2003 operating system and Windows XP 64-Bit Edition 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 registrybased policy Specifically, registry-based Group Policy is an appropriate solution for the following scenarios: • Creating available and unavailable (on/off, or yes/no) functionality You can use registry-based policy as if it were a switch, to turn functionality on or off For example, you can create a policy setting to allow administrators to control whether a certain item is displayed on the desktop • 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 the possible language selections, and when the policy setting is enabled, the administrator can select a language from the precreated 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 are provided with a text dialog box into which they can enter the name and path of the bitmap file to be used This information is then stored in the registry as plain text 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 Users cannot change or disable these settings Language Reference for Administrative Template Files Table Approved Registry Key Locations for Group Policy Settings For Computer Policy Settings: For User Policy Settings: HKLM\Software\Policies (The preferred location) HKCU\Software\Policies (The preferred location) HKLM\Software\Microsoft\Windows\C urrentVersion\Policies HKCU\Software\Microsoft\Windows\C urrentVersion\Policies 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 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 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 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 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 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 Using Administrative Template Files with Registry-Based Group Policy 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 lists the resultant behavior for Group Policy settings and preferences Table Results of Group Policy Settings and Preferences Scenario Policy Present Preference Present Resultant Behavior No policy or preference No No Default behavior Preference Only No Yes Preference configures behavior Policy only Yes No Policy configures behavior Both policy and preference Yes Yes Policy configures behavior Preference is ignored In all cases, policy overrides preference 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 • 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? Language Reference for Administrative Template Files • 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 10 Using Administrative Template Files with Registry-Based Group Policy 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 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 Language Reference for Administrative Template Files 45 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 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 46 Using Administrative Template Files with Registry-Based Group Policy 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: • The value is set in the registry as a REG_DWORD type • You can optionally have the value written as a REG_SZ type by using the TXTCONVERT keyword Table shows the options for the NUMERIC type Table Options for NUMERIC Option Description DEFAULT value Specifies the initial numeric value for the edit field If this option is not specified, the field is initially empty MAX value Specifies the maximum value for the number The default value is 9999 MIN value Specifies the minimum value for the number The default value is REQUIRED Specifies that the Group Policy Object Editor does not allow a policy containing this PART to be enabled unless a value has been entered for this PART Language Reference for Administrative Template Files SPIN value Specifies increments to use for the spinner control The default is SPIN SPIN removes the spinner control TXTCONVERT 47 Writes values as REG_SZ strings (“1”, “2”, or “128”) rather than as binary values The valid keywords for NUMERIC are: • KEYNAME • VALUENAME • MIN • MAX • SPIN • DEFAULT • REQUIRED • TXTCONVERT • END • CLIENTEXT Examples of NUMERIC Use The following example illustrates use of the NUMERIC PART type using the DEFAULT option PART!!MyVariable NUMERIC DEFAULT 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" 48 Using Administrative Template Files with Registry-Based Group Policy DEFAULT 30000 MAX 30000 MIN 300 END PART The following example illustrates use of the NUMERIC PART type using the TXTCONVERT option, which writes values as REG_SZ strings (such as “60”) instead of binary values PART !!ScreenSaverTimeOutFreqSpin NUMERIC DEFAULT 900 MIN MAX 599940 SPIN 60 TXTCONVERT VALUENAME "ScreenSaveTimeOut" END PART COMBOBOX PART Type This PART type displays a combo box It accepts the same options as EDITTEXT, as well as the SUGGESTIONS option, which begins a list of suggestions to be placed in the drop-down list SUGGESTIONS are separated with spaces and must be enclosed in quotation marks (") when a value includes spaces If a suggestion name includes white space, it must be enclosed in quotation marks The list ends with END SUGGESTIONS Example The following example illustrates the use of the SUGGESTIONS option SUGGESTIONS Alaska Alabama Mississippi ”New York“ END SUGGESTIONS Keywords The valid keywords for COMBOBOX are: • KEYNAME • VALUENAME • DEFAULT • SUGGESTIONS • REQUIRED • MAXLENGTH • OEMCONVERT • END Language Reference for Administrative Template Files 49 Note GPMC requires that you define the key name and value name before you specify DROPDOWNLIST • NOSORT • EXPANDABLETEXT • CLIENTEXT • END DROPDOWNLIST PART Type Displays a combo box with a drop-down list style The user may choose only one of the entries supplied DROPDOWNLIST Syntax DROPDOWNLIST uses the following syntax PART !!text DROPDOWNLIST ITEMLIST NAME name VALUE value NAME name VALUE value END ITEMLIST 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 !! in front of the variable name name This is text that will be displayed in the drop-down list for a particular item value The value to be written to the specified registry key if this item is selected Values are assumed to be strings, unless they are preceded by NUMERIC The following example shows both string and numeric values: VALUE “Some value” VALUE NUMERIC The valid keywords for DROPDOWNLIST are: • KEYNAME • VALUENAME 50 Using Administrative Template Files with Registry-Based Group Policy • REQUIRED • ITEMLIST • END • NOSORT • CLIENTEXT LISTBOX PART Type The LISTBOX PART component specifies various options such as drop-down list boxes, text boxes, and text in the lower pane of the Group Policy Object Editor LISTBOX accepts the options shown in Table Table LISTBOX Options LISTBOX Option Description ADDITIVE By default, the content of list boxes overrides any values set in the target registry This means that a control value is inserted in the policy file that causes existing values to be deleted before the values set in the policy file are merged If this option is specified, existing values are not deleted, and the values set in the list box is in addition to whatever values exist in the target registry EXPLICITVALUE This option makes the user specify the value data and the value name The list box shows two columns, one for the name and one for the data This option cannot be used with the VALUEPREFIX option VALUEPREFIX prefix The prefix you specify is used in determining value names If a prefix is specified, the prefix and an incremented integer are used, instead of the default value naming scheme described previously For example, a prefix of “SampleName” generates the value names “SampleName1”, “SampleName2”, and so on The prefix can be empty (“”), which causes the value names to be “1”, “2”, and so on By default, only one column appears in the list box, and for each entry a value is created whose name and value are the same For instance, a “name” entry in the list box creates a value called “name” that contains data called “name” When using a LISTBOX, use the ADDITIVE keyword unless you have a specific reason not to so The valid keywords for LISTBOX are: Language Reference for Administrative Template Files 51 Note Windows XP SP2 fixed issues relating to the LISTBOX ADDITIVE functionality For more information, see the “Changes to LISTBOX ADDITIVE” section in this document • KEYNAME • VALUEPREFIX • ADDITIVE • NOSORT • EXPLICITVALUE • EXPANDABLETEXT • END • CLIENTEXT ACTIONLIST You can use an action list to specify a set of arbitrary registry changes to make in response to a control being set to a particular state Syntax The ACTIONLIST syntax is as follows: ACTIONLIST [KEYNAME key name] VALUENAME value name VALUE value END ACTIONLIST key name This is an optional path to the registry key 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 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 52 Using Administrative Template Files with Registry-Based Group Policy value Values are treated as strings unless they are preceded by NUMERIC, as in the following examples: VALUE "Some value" VALUE NUMERIC If VALUE is followed by DELETE (for example, VALUE DELETE), the registry entry is deleted Table 10 lists the two variants for ACTIONLIST that can be used with POLICY and CHECKBOX Table 10 Variants for ACTIONLIST Variant Description ACTIONLISTON Specifies an optional action list to be used if the check box is selected ACTIONLISTOFF Specifies an optional action list to be used if the check box is not selected ACTIONLIST Example The following example illustrates the use of ACTIONLISTON and ACTIONLISTOFF POLICY "Deny connections requests" EXPLAIN "If enabled, TS will stop accepting connections" ACTIONLISTON VALUENAME "fDenyTSConnections" VALUE NUMERIC END ACTIONLISTON ACTIONLISTOFF VALUENAME "fDenyTSConnections" VALUE NUMERIC END ACTIONLISTOFF END POLICY Additional Elements The adm language supports the following elements: KEYNAME The KEYNAME keyword is used within a CATEGORY to define which key within the registry is modified as a result of an action here KEYNAME should be followed by the registry path to the key that contains the value that you want to change 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 the KEYNAME contains a space, you must enclose the string in quotation marks (") Language Reference for Administrative Template Files 53 VALUENAME Defines the options available within a POLICY First identify the registry value that is to be modified as a result of using the keyword VALUENAME For example, VALUENAME MyFirstValue The following example illustrates the use of VALUENAME The Disable Boot / Shutdown / Logon / Logoff status messages policy prevents the display of system status messages POLICY!!DisableStatusMessages KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\System" EXPLAIN!!DisableStatusMessages_Help VALUENAME "DisableStatusMessages" END POLICY Unless you specify otherwise, the value is written in the following format when the user checks or clears the option: • Checked Uses a REG_DWORD type with a value of • Cleared Removes the value You can specify options other than these defaults by using VALUEOFF and VALUEON If the option is to be selected within the lower pane of the Group Policy Object Editor, the VALUENAME needs to be within a PART scope CLIENTEXT The CLIENTEXT keyword is used to specify which client-side extension to the Group Policy Object Editor needs to process the particular settings on the client computer By default, the registry extension processes all settings configured under the Administrative Templates node The CLIENTEXT keyword changes the default behavior and causes the specified extension to process these settings after the registry extension has placed them in the registry CLIENTEXT must be used within either the POLICY scope or the PART scope and should follow the VALUENAME statement The following example illustrates use of CLIENTEXT POLICY !!DQ_Enforce #if version >= SUPPORTED !!SUPPORTED_Win2k #endif EXPLAIN !!DQ_Enforce_Help VALUENAME "Enforce" VALUEON NUMERIC VALUEOFF NUMERIC CLIENTEXT {3610eda5-77ef-11d2-8dc5-00c04fa31a66} END POLICY 54 Using Administrative Template Files with Registry-Based Group Policy The GUID that follows the CLIENTEXT keyword is the GUID of the client-side extension The client-side extensions are listed in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlog on\GPExtensions VALUEON and VALUEOFF You can use VALUEON and VALUEOFF to write specific values based on the state of the option To enable this functionality, you can write the adm file as described in the following examples: KEYNAME key name POLICY!!MyPolicy VALUENAME ValueToBeChanged VALUEON “Turned On” VALUEOFF “Turned Off” END POLICY KEYNAME key name POLICY!!MyPolicy VALUENAME ValueToBeChanged VALUEON VALUEOFF 10 END POLICY Using Simple Policies and Policies with the VALUEOFF and VALUEON Statements This section presents two examples that illustrate the difference between using the default policy states and specifying VALUEON and VALUEOFF statements There is a significant difference between the two example policies Example In this example, no explicit VALUEON or VALUEOFF statements are used This means that the Administrative Templates use the default behavior when the user changes the state of this policy POLICY!!EnableSlowLinkDetect EXPLAIN !!EnableSlowLinkDetect_Help KEYNAME "Software\Policies\Microsoft\Windows\System" VALUENAME "SlowLinkDetectEnabled" END POLICY Table 11 lists the default behavior Table 11 Example Policy Defaults State Policy setting enabled Behavior A DWORD with the value is written Language Reference for Administrative Template Files 55 to the registry Policy setting disabled The registry value is deleted Policy setting not configured Nothing is changed in the registry Note the policy-disabled state The value is not written to the registry with the value of 0— instead it is explicitly deleted This means that a component reading the policy will not find the value in the registry, and will fall back to using the default in the code Example In this example, the state values are explicitly defined, so when the user changes the policy, the Administrative Templates use these values POLICY!!EnableSlowLinkDetect EXPLAIN!!EnableSlowLinkDetect_Help KEYNAME "Software\Policies\Microsoft\Windows\System" VALUENAME "SlowLinkDetectEnabled" VALUEON NUMERIC VALUEOFF NUMERIC END POLICY Table 12 lists the behaviors in Example Table 12 Example Policy Defaults State Behavior Policy setting enabled A DWORD with the value is written to the registry Policy setting disabled A DWORD with the value is written to the registry Policy setting not configured Nothing is changed in the registry EXPLAIN The EXPLAIN keyword is used to provide online Help text for a specific Group Policy In Windows 2000, the Properties page for each policy setting includes an Explain tab, which provides details about the policy settings Each Group Policy that you create should include one EXPLAIN keyword, followed by at least one space, and then the EXPLAIN string in quotation marks (") or a reference to the Help string For example: 56 Using Administrative Template Files with Registry-Based Group Policy POLICY!!Pol_NoConfigCache #if VERSION >= EXPLAIN!!Pol_NoConfigCache_Help #endif VALUENAME "NoConfigCache" PART!!Lbl_NoConfigCacheHelp1 END PART END POLICY TEXT [Strings] Pol_NoConfigCache_Help="Prevents users from changing the automatic synchronization behavior at logoff." In the preceding example, Help is offered for one of the Offline Files options The EXPLAIN keyword wrapped in the #if VERSION allows this adm file to be used with the Windows 2000 Group Policy Object Editor (version 3) Line Breaks To start text on a new line or to create a line break, use this syntax: \n = Starts a new line \n\n = Creates a line break #If Version for Version Comparison The IF VERSION conditional statement is used to control the display of certain policy settings and features in the Administrative Templates node, based on the version of the Group Policy Object Editor that you are using IF VERSION allows for part of the adm files to be conditionally parsed and ignored by earlier versions of the Group Policy Object Editor tool For example, the SUPPORTED tag is not supported on versions of the Group Policy Object Editor earlier than version For this reason any statement using the SUPPORTED tag should be enclosed by #If Version…#endif You can specify that any part of your adm file be evaluated only in specific versions of the Group Policy editing tools, as shown in Table 5, in the “.Adm File Language Versions” section of this document To compare versions, use the following syntax: #if Version (operator) x #endif The valid operators are listed in Table 13 Table 13 Valid Operators for the Version Statement Number Operator > (GT) Signifies Greater than For example, a > b means a is greater than b Language Reference for Administrative Template Files < (LT) Less than For example, a < b means a is less than b == (EQ) Equal For example, a == b means a is equal to b != (NE) Not equal >= (GTE) Greater than or equal to For example, a >= b means a is greater than or equal to b