Deployment considerations for Group Policy

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Deployment Considerations for Group Policy

This topic describes deployment issues related to managing Group Policy in enterprise environments. This includes interoperability issues such as handling a mix of client operating system versions, a mix of domain versions, as well as new features included with Windows Server 2003.

To view an item, click the appropriate link:

  • Applying Group Policy on different client operating systems

  • Using Administrative template files in mixed environments

  • Administering a mix of Windows 2000 and Windows Server 2003 domains

  • Upgrading Windows 2000 domains to Windows Server 2003 domains and interaction with Group Policy Modeling

  • Using Group Policy features across forests

  • Group Policy for sites

  • Using Group Policy and Internet Explorer enhanced security configuration

Applying Group Policy on different client operating systems

Group Policy can apply to client computers running any of the following operating systems or later:

  • Any version of Windows 2000.

  • Any version of Windows XP Professional.

  • Any version of Windows Server 2003.

Except for Local Group Policy objects (LGPOs), Group Policy requires Active Directory. In order for computer configuration settings to apply, the computer account must be in an Active Directory domain. In order for user configuration settings to apply, the user account must be in an Active Directory domain.

Group Policy is not applied to computers running any of the following operating systems:

  • Windows 95

  • Windows 98

  • Windows Millennium

  • Windows NT

Using Administrative template files in mixed environments

Administrative templates, (or .adm files), enable administrators to control registry settings using Group Policy. Windows comes with a predefined set of Administrative template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a Group Policy object (GPO). These .adm files are stored in two locations by default: inside GPOs and in the %windir%\inf folder on the local computer.

As new versions of Windows are released, new policy settings are added. In addition to supporting these new settings, each successive version of Windows supports all registry policy settings that were available in earlier versions of Windows. For example, the Windows Server 2003 family supports all registry policy settings available in Windows 2000 and Windows XP.

It is important to understand that .adm files are not the actual settings that are deployed to client operating systems. The adm file is simply a template file that provides the friendly name for the setting and an explanation. This template file is used to populate the user interface. The settings that are deployed to clients are contained in the registry.pol file inside the GPO. On Windows XP and Windows Server 2003, each registry setting contains a "Supported on" tag that indicates which operating system versions support that policy setting. If a setting is specified and deployed to a client operating system that does not support that setting, the settings are ignored.

Because all successive iterations of .adm files include settings from earlier versions, and because there is no harm if a new setting is applied inadvertently to a computer running an earlier operating system that does not support that setting, it is recommended to always create and edit GPOs from a computer that has the latest .adm files available. Note that the behavior for handling .adm files in GPMC and the Group Policy Object Editor differs.

Handling .adm files in Group Policy Object Editor

  • The Group Policy Object Editor uses .adm files to display available policy settings in the Administrative Templates section of a GPO.

  • By default it attempts to read .adm files from the GPO (from the Sysvol on the domain controller). Alternatively, the .adm file can be read from the local workstation computer. This behavior can be controlled by a policy setting.

  • By default, if the version of the .adm file found on the local computer is newer (based on the time stamp of the file) than the version on the Sysvol, the local version is copied to the Sysvol and is then used to display the settings. This behavior can be controlled by a policy setting.

  • If the GPO contains registry settings for which there is no corresponding .adm file, these settings cannot be seen in the Group Policy Object Editor. However, the policy settings are still active and will be applied to users or computers targeted by the GPO.

Handling .adm files in GPMC

  • GPMC uses .adm files to display the friendly names of policy settings when generating HTML reports for GPOs, Group Policy Modeling, and Group Policy Results.

  • By default, GPMC uses the local .adm file, regardless of time stamp. If the file is not found, then GPMC will look in the GPO's folder on Sysvol.

  • The user can specify an alternate path for where to find .adm files. If specified, this takes precedence over the previous locations.

  • GPMC never copies the .adm file to the Sysvol.

Administering a mix of Windows 2000 and Windows Server 2003 domains

GPMC exposes features that are available in the underlying operating system. Because new features have been added to Group Policy since Windows 2000, certain features will only be available in GPMC depending on the operating system that has been deployed on the domain controllers. This section describes these dependencies. In general, there are three key issues that determine whether a feature is available in GPMC:

  • Whether the forest supports the Windows Server 2003 schema for Active Directory. Certain features are only available once the schema is upgraded. This is the first step that must be taken before any Windows Server 2003 domain controller can be deployed in an existing Windows 2000 forest. The schema is a forest-wide configuration and is upgraded by running ADPrep /ForestPrep. ADPrep is a utility included on the Windows Server 2003 CD. Note that it is possible to have the Windows Server 2003 schema in a forest with all Windows 2000 domain controllers.

  • Whether there is at least one domain controller in the forest that is running Windows Server 2003. Group Policy Modeling must be performed on a domain controller running Windows Server 2003.

  • Whether a domain contains the Windows Server 2003 domain configuration. This is implemented once ADPrep /DomainPrep is run in that domain. This is the first step that must be taken before any Windows Server 2003 domain controller can be deployed in an existing Windows 2000 domain.

Note that there is no dependency from the Group Policy perspective on whether a domain is in native mode or mixed mode.

Delegation of Group Policy Results and Group Policy Modeling

In order to delegate either Group Policy Modeling or Group Policy Results, the Active Directory schema in the forest must be the Windows Server 2003 schema. Note that you can use Group Policy Results even without this schema, but only users with local administrative privileges on the target computer can remotely access Group Policy Results data. Thus, if the forest does not have the Windows Server 2003 schema, the delegation pages in GPMC for organizational units and domains will not show these permissions.

Group Policy Modeling

Group Policy Modeling is a simulation that is performed by a service that can only run on a domain controller running Windows Server 2003 or later. As long as there is at least one domain controller running Windows Server 2003 in the forest, you can use Group Policy Modeling. GPMC will only show the Group Policy Modeling node in the user interface if the Windows Server 2003 schema is present.

WMI filtering

WMI filters are only available in domains that have the Windows Server 2003 configuration. Although none of the domain controllers need to be running Windows Server 2003, you must have run ADPrep /DomainPrep in this domain. Also note that WMI filters are only evaluated by clients running Windows XP, Windows Server 2003, or later. WMI filters associated with a Group Policy object will be ignored by Windows 2000 clients and the GPO will always be applied on Windows 2000. For more information, see WMI filtering using GPMC.

If ADPrep /DomainPrep has not been run in a given domain, the WMI Filters node will not be present, and the GPO scope tab will not have a WMI filters section.

Upgrading Windows 2000 domains to Windows Server 2003 domains and interaction with Group Policy Modeling

Group Policy Modeling is a new feature of Windows Server 2003 that simulates the resultant set of policy for a given configuration. The simulation is performed by a service that runs on Windows Server 2003 domain controllers. In order to perform the simulation in cross-domain scenarios, the service must have read access to all GPOs in the forest.

In a Windows Server 2003 domain (whether it is upgraded from Windows 2000 or installed as new), the Enterprise Domain Controllers group is automatically given read access to all newly created GPOs. This ensures that the service can read all GPOs in the forest.

However, if the domain was upgraded from Windows 2000, any existing GPOs that were created before the upgrade do not have read access for the Enterprise Domain Controllers group. When you click a GPO, GPMC detects this situation and notifies the user that Enterprise Domain Controllers do not have read access to all GPOs in this domain. To solve this problem, you can use one of the sample scripts provided with GPMC, GrantPermissionOnAllGPOs.wsf. This script can update the permissions for all GPOs in the domain. To use this script:

  • Ensure that the person running this script is either a Domain Admin or has permissions to modify security on all GPOs in the domain.

  • Open a command prompt and navigate to the %programfiles%\gpmc\scripts folder by typing:

    CD /D %programfiles%\gpmc\scripts
    
  • Type the following:

    Cscript GrantPermissionOnAllGPOs.wsf "Enterprise Domain Controllers" /Permission:Read /Domain:value
    

The value of domain parameter is the DNS name of the domain.

Using Group Policy features across forests

The Windows Server 2003 family introduces a new feature called Forest Trust that enables you to authenticate and authorize access to resources from separate, networked forests. With trusts established between forests, you can manage Group Policy throughout your enterprise, which provides greater flexibility especially in large organizations. For more information on forest trusts, see Forests in Group Policy Management Console.

This section describes Group Policy behavior in an environment with forest trust enabled:

  • It is not possible to link a GPO to a domain in another forest.

  • With Forest trust, it is possible that a user in forest B could log onto a computer in forest A. In this case, when the computer starts up, it will process policy for the computer configuration from Forest A, as usual. When a user from Forest B logs on, where they receive their policy settings from depends on the value of the Allow Cross-Forest User Policy and Roaming Profiles policy setting.

    • When this setting is Not Configured, no user-based policy settings are applied from the user's forest. Instead, loopback Group Policy processing will be applied, using the Group Policy objects scoped to the computer. Users will receive a local profile instead of their roaming profile.

    • When this setting is Enabled, the behavior is exactly the same as Windows 2000 Server, User policy is applied from the user's forest and a roaming user profile is allowed from the trusted forest.

    • When this setting is Disabled, the behavior is the same as Not Configured.

    This setting is available on Windows Server 2003 located at: Computer Configuration\Administrative Templates\System\Group Policy\Allow Cross-Forest User Policy and Roaming Profiles.

  • It is possible to deploy Group Policy settings to users and computers in the same forest, but have those settings reference servers in other trusted forests. For example, the shares that host software distribution points, redirected folders, logon scripts, and roaming user profiles could be in another trusted forest.

  • Group Policy Modeling requires that both the user and the computer be in the same forest. If you want to simulate a user from Forest A logging on to a computer in Forest B, you must perform two separate Group Policy Modeling simulations: one for the user configuration and the other for the computer configuration.

  • Delegation across forests is supported for managing Group Policy. For example, you can delegate to someone in Forest B the ability to perform Group Policy Modeling simulations on objects in Forest A.

Group Policy for sites

GPOs that are linked to Active Directory site objects affect all computers in the site. Therefore, any Group Policy object that is linked to a site is applied to all computers in that site, without regard to which domain (in the forest) contains the computers.

This means that computers in multiple domains within a forest can potentially receive the same Group Policy object when you use site-linked GPOs. It also means that a given client computer could receive GPOs from multiple domains in the forest. Note that the GPO exists as a stored entity only in a single domain and it must be read from that domain when the affected clients read their site-linked Group Policy.

If multiple domains are set up across wide area network (WAN) boundaries, the site configuration should take this into account. If it does not, the computers in another domain access a site-linked GPO across a WAN link. This increases the processing time for Group Policy.

In general, it is recommended that you link GPOs to domains and organizational units rather than sites.

Using Group Policy and Internet Explorer enhanced security configuration

Windows Server 2003 includes a new default security configuration for Internet Explorer, called Internet Explorer Enhanced Security Configuration (ESC). ESC impacts the Security Zones and Privacy settings within the Internet Explorer Maintenance settings of a GPO. The Security Zones and Privacy settings can either be ESC enabled or not.

  • When you edit settings for Security Zones and Privacy settings in a GPO from a computer where ESC is enabled, that GPO will contain ESC-enabled settings. When you look at the HTML report for that GPO, the Security Zones and Privacy header will be appended with the text (Enhanced Security Configuration enabled).

  • When you edit settings for Security Zones and Privacy settings in a GPO from a computer where ESC is not enabled , that GPO will contain ESC disabled settings. ESC is not enabled on any computer running Windows 2000 or Windows XP, nor on computers running Windows Server 2003 where ESC has been explicitly disabled.

ESC settings deployed through Group Policy will only be processed on and applied by computers where ESC is enabled. ESC settings will be ignored on computers where ESC is not enabled (all computers running Windows 2000 and Windows XP, and Windows Server 2003 computers where ESC has been explicitly disabled). The converse is also true: A GPO that contains non-ESC settings will only be processed on and applied by computers where ESC is not enabled.

See Also

Concepts

Managing inheritance of Group Policy
Internet Explorer Maintenance overview for GPMC
Security settings overview for GPMC