Deploying Group Policy Settings in SP2

This section helps you get started in deploying Group Policy settings delivered in SP2. First, it explains hotfixes that you might need to apply to your management workstations. Second, it shows recommended ways of deploying new policy settings in your environment.

The following guidelines assume you are using Group Policy to manage your users and computers in a Windows 2000 Server or Windows Server 2003 domain.

On This Page

Before Installing SP2
Group Policy Deployment Roadmap for SP2
Managing Replication of .ADM Files in Your Domain

Before Installing SP2

SP2 includes modifications to tools used to administer Group Policy. This includes changes to gptext.dll and changes to the LISTBOX ADDITIVE functionality in administrative template files.

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 XP with  SP1 or Windows Server 2003), 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:

• Windows 2000

• Windows XP with SP1

• Windows Server 2003

To obtain these hotfixes see Microsoft Knowledge Base article 842933.

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 SP2.

Multiple Pop-up Error Messages

Some .adm files installed by SP2 do not fully load on earlier versions of gpedit, which is present by default in Windows Server 2003, Windows XP with SP1, and Windows 2000. If this is attempted, multiple error messages appear when the system.adm and inetres.adm files are loaded in gpedit. The error messages indicate that a string is too long. This occurs because earlier versions of gpedit cannot correctly handle the “#if ver >= 5 / #endif” construct in the SP2 .adm files. Although clicking OK on all the pop-up error messages does result in the .adm files loading correctly, the new 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.

1. Install Windows XP SP2 on the administrative computer.

2. Open existing GPO in Group Policy Object Editor. The .adm file stored on the administrative computer is uploaded to domain controller. GPO is "upgraded" to SP2.

3. This .adm file is replicated to all domain controllers in the domain.

4. If the GPO is opened by other administrative workstations in the domain that are not running Windows XP with SP2 or the latest version of gpedit, error messages appear.

     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 Microsoft Knowledge Base article 842933.

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

For more information about the replication of .adm files, see Recommendations for managing Group Policy administrative template (.adm) files.

Using Group Policy to Temporarily Disable the Delivery of SP2 Through Windows Updates and Automatic Updates

Microsoft recommends that you deploy SP2 as soon as possible. However; if you are not using Systems Management Server (SMS), Software Update Services (SUS) or another update management solution and require more time to plan the rollout of SP2, you can use a Group Policy setting to temporarily disable the delivery of SP2 by using Windows Update and Automatic Updates. To do this, use the Do not allow delivery of Windows XP Service Pack 2 (SP2) through Windows Update or Automatic Updates policy setting, which is available in the new NoXPSP2Update.adm file. If you enable this policy setting, SP2 is not available to users through Windows Update, and the Automatic Update client does not download this package.

Administrators can download the NoXPSP2Update.adm file from the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=33543.

  Note
The mechanism for temporarily disabling the delivery of SP2 is available only for a limited time. After this time period, this policy setting will have no effect. Please see the Windows XP SP2 Web page on the Microsoft TechNet Web site for information about the expiration date.
The Do not allow delivery of Windows XP Service Pack 2 (SP2) through Windows Update or Automatic Updates policy setting does not prevent installation of Windows XP SP2 through other mechanisms such as SMS, SUS, product disk and so on.
The Do not allow delivery of Windows XP Service Pack 2 (SP2) through Windows Update or Automatic Updates policy setting does not disable Automatic Updates or access to Windows Update. Nor does it prevent delivery of updates other than Windows XP SP2 through Windows Update or Automatic Updates

Group Policy Deployment Roadmap for SP2

This section provides best practice recommendations for deploying policy settings delivered with SP2.

1. Assess whether you need to install the previously described hotfix, as shown in the following diagram.

   

2. After you have completed the steps in the diagram, you are ready to begin the phase of deploying SP2 to the computers in your organization, as explained in the section “Group Policy Deployment Roadmap for Windows XP SP2” later in this paper.

3. Evaluate new policy settings based on how you want to manage new functionality in SP2. See the sections in this paper for more information on new policy settings in SP2.

4. Test policy settings, as shown in the following diagram.

   

5. After you test your policy settings, you should pilot selected policy settings in your production environment, as shown in the following diagram.

   

For detailed information about deploying GPOs, see Staging Group Policy Deployments.

Upgrading Existing GPOs

To upgrade existing GPOs so that they contain the option to configure the policy settings in SP2, you need to open each GPO. GPMC provides the easiest way to view all the GPOs in a domain.

To upgrade existing GPOs

1. Log on to a computer with SP2 installed.

2. Open GPMC and click the domain that contains the GPOs you want to upgrade.

3. Click the Group Policy objects container. This contains all the GPOs in the domain.

4. Right-click the GPO you want to upgrade and select Edit. The GPO opens in the Group Policy Object Editor. This upgrades the GPO with the latest .adm files on your local computer. This .adm file is then automatically replicated to domain controllers throughout your environment.

5. Open each GPO that you want to upgrade.

For a script to perform this task, check the TechNet Script Center: Script Repository.

Using Remote RSoP in Windows XP with SP2

To manage and troubleshoot Group Policy, you are often required to check which policy settings are in effect for a given user or computer. The functionality for Resultant Set of Policy (RSoP) is included in GPMC, which contains: the following

• Group Policy Results. Reports which policies are in effect for a target user or computer.

• Group Policy Modeling. Provides a simulation of how a planned policy setting would affect a target user or computer.

In SP2, the Windows Firewall is enabled by default. Because Windows Firewall blocks unsolicited incoming requests, remote RSoP will not work on target computers without modifying the firewall settings. You need to take several steps in order to be able to use remote RSoP. If you are already using GPMC, as recommended, these extra steps are minimized. These steps are summarized in Table 1.

Table 1   Configuring Remote RSoP in Windows XP with SP2

  Caution
Enabling Windows Firewall: Allow remote administration exception opens RPC and DCOM, and this can make the target computer more vulnerable to network attacks.
If at all possible, it is preferable to open only the exception required for a given management application or service rather than enable the Windows Firewall: Allow remote administration exception policy setting. Administrators should read the documentation for the particular application they want to run and find out what is recommended for working with the firewall. In most cases, the application (MMC, for example) documentation includes guidance as to which ports it needs to have open.
For detailed information about deploying Windows Firewall, see “Deploying Windows Firewall Settings for Microsoft Windows XP Service Pack 2” at the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=23277.

Managing Replication of .ADM Files in Your Domain

Each GPO is stored in the Sysvol share of each domain controller. By default, the .adm file is copied to each policy object in the file path:

%SYSTEMROOT%\sysvol\domainname\Policies\POLICYGUID\Adm

SP2 contains more than 600 new Administrative Template settings bringing the total size of the default set of Administrative Templates to more than 3 MB. When you multiply this size by each policy setting that Sysvol contains, you can see that much space is devoted to these templates. If you are concerned about the size of sysvol domain controllers in your organization, you might want to manage how .adm files behave.

For more information, see article 316977, “Group Policy Template Behavior in Windows Server 2003,” in the Microsoft Knowledge Base.