MORE INFORMATION
The IF VERSION / END IF conditional element
Summary
You 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:
|
| Version 3 | Windows 2000 |
| Version 4 | Windows XP Service Pack 1 (SP1) and Windows Server 2003 |
| Version 5 | Windows XP SP2 |
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:
- DCOM: Define Activation Security Check exemptions
- Offline Files: Administratively assigned offline files (Computer Policy)
- Offline Files: Prohibit 'Make Available Offline' for these files and folders (Computer Policy)
- Offline Files: Administratively assigned offline files (User Policy)
- Offline Files: Prohibit 'Make Available Offline' for these files and folders (User Policy)
- Windows Firewall: Define Program exceptions (Computer Policy)
- Windows Firewall: Define Port Exceptions (Computer Policy)
Issues
You 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 construct
The 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"
An administrator may define multiple programs to run, and they will all be written to a single registry value.
The ADDITIVE keyword
Summary
You 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.
Issues
The following issues have been identified with the behavior of the ADDITIVE keyword:
- When a LISTBOX ADDITIVE setting is disabled at the lowest level of a Group Policy hierarchy, the expected behavior would be for the cumulative policy settings from higher in the hierarchy not to take precedence and for the effective setting to be disabled. This behavior does not occur. Instead, the user still receives the inherited settings.
Note This issue actually occurs when the administrator defines the policy settings in Group Policy Object Editor. - The settings that use LISTBOX ADDITIVE are not visible when you modify a GPO in Windows 2000. This behavior occurs because all instances of the LISTBOX ADDITIVE setting have been enclosed by an IF VERSION >= 5 / END IF conditional element. This behavior is intentional.
Architectural changes made it impractical to correct the LISTBOX ADDITIVE setting behavior in Windows 2000. Therefore, we decided to prevent those settings from being modified on a Windows 2000-based client computer.
Warning Do not try to modify the IF VERSION / END IF conditional statements to make these settings editable. You will be able to view and modify the settings, but the expected behavior of the resulting policy will depend on the operating system version of the last client to modify the policy. Because the operating system version is impossible to control or monitor, the policy results would be unpredictable.
Additional registry settings
When 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:
- The name of the registry key
- The state of the setting, or whether it is enabled or disabled
- The winning GPO. The winning GPO is the GPO that actually applies the Group Policy setting based on precedence and inheritance rules.