Article ID: 873449 - View products that this article applies to.
This article has been archived. It is offered "as is" and will no longer be updated.
The behavior of the Group Policy administrative template has been changed in several ways in Microsoft Windows XP Service Pack 2 (SP2). These changes will also be adopted in all future Windows service packs.
This article describes the changes to the Group Policy administrative template and how the changes will affect overall Group Policy functionality.
The IF VERSION / END IF conditional element
SummaryYou can control the display of certain features or settings by using the IF VERSION / END IF conditional element, based on the version of Group Policy Object Editor (Gpedit.msc). The version is important, because newer versions of the Windows operating system may have features or settings that may not be correctly interpreted by earlier versions of Group Policy Object Editor. Similarly, behaviors may change between versions of Group Policy Object Editor. The IF VERSION / END IF conditional element lets earlier versions of Group Policy Object Editor parse or ignore some parts of the administrative templates.
The following table lists the version numbers of Group Policy Object Editor:
You can use Group Policy Object Editor version 5 in Windows XP SP2 to prevent the display of some settings and to separate the Windows XP SP2 version of Group Policy Object Editor from earlier versions. Therefore, any setting with a version of 5 or a later version will not be displayed when you view Group Policy settings from a client computer where Group Policy Object Editor cannot interpret this version. In particular, Windows 2000 clients cannot view settings with Group Policy Object Editor version 5 or a later version. These settings include but are not limited to the following:
Collapse this tableExpand this table
IssuesYou may try to use the IF VERSION / END IF conditional element to exclude some of the explanation information for several policies. The strings that contain this information are more than the earlier versions of Group Policy Object Editor can read. However, earlier versions of Group Policy Object Editor still try to "read" the information that is enclosed by the IF VERSION / END IF conditional element before Group Policy Object Editor determines whether to make that information visible in Group Policy Object Editor.
The LISTBOX constructThe Group Policy administrative templates (.adm files) include several settings that you can use to define how a setting will ultimately be written into the Group Policy of a client. One of these definitions, or constructs, is the LISTBOX construct. The LISTBOX construct allows the administrator to enter data in Group Policy Object Editor that contains multiple values. If you use this construct, the defined settings will be written as a REG_MULTI registry value type. Therefore, you can store multiple values within one registry value setting.
For an example of this construct, see the "Run these programs at user logon" policy setting that is located in the following path:
User Configuration\Administrative Templates\System\Logon\"Run these programs at user logon"Note An administrator may define multiple programs to run, and they will all be written to a single registry value.
The ADDITIVE keyword
SummaryYou use the ADDITIVE keyword with the LISTBOX construct. When you specify the ADDITIVE keyword for a LISTBOX construct, the behavior of programs that are on that setting changes from the default Group Policy behavior.
Typically, the Group Policy handles value definition conflicts in a "last writer wins" method. For example, if a user has multiple Group Policy objects (GPOs) applied to them, and if each GPO has a different definition for the "Run these programs at user logon" setting, the effective Group Policy for the user would contain the value from the last-applied GPO. Typically, this is the GPO with the highest precedence that applies to the user in the domain object, the site object, or the organizational unit that is closest to the user in Active Directory hierarchy.
The ADDITIVE keyword actually invokes a different behavior than a "last writer wins" method. Instead, the ADDITIVE keyword causes the Group Policy to process the targeted policies cumulatively. Therefore, the values from multiple GPOs are applied to the effective policy setting in a merged format.
Before Windows XP SP2, the ADDITIVE keyword was rarely used. However, many more Group Policies now use this keyword. For example, the Windows Firewall Define Port Exceptions setting uses this new behavior.
IssuesThe following issues have been identified with the behavior of the ADDITIVE keyword:
Additional registry settingsWhen you use Group Policy Results and Group Policy Modeling in the Group Policy Management Console (GPMC), an HTML-formatted report is generated. This report describes which policy settings are configured for a particular target. Because of the way GPMC interprets administrative template (.adm) files, some new Group Policy settings that are delivered with Windows XP SP2 appear in the GPMC reports under the Extra Registry Settings category, instead of under the User Configuration category or under the Computer Configuration category. This behavior occurs because the GPMC does not recognize entries in the .adm file that are enclosed by the "#if version >= 5" / "#endif" construct. These entries may include Windows Firewall and Microsoft Internet Explorer policy settings that use the LISTBOX ADDITIVE functionality.
An example of using the LISTBOX construct is the Windows Firewall: Define Port Exceptions Group Policy setting that is under both the Domain Profile and Standard Profile nodes. This Group Policy setting is located in Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall.
Additionally, the GPMC does not show the display names for these Group Policy settings. GPMC does show the following information:
Article ID: 873449 - Last Review: January 16, 2015 - Revision: 2.0