Windows XP Service Pack 2 Enterprise Implementation Guide

Abstract

This guide describes three methods for deploying Microsoft® Windows® XP Service Pack 2 (SP2) in enterprise environments: Microsoft® Software Update Services (SUS), Systems Management Server (SMS), and Group Policy. This guide provides step-by-step instructions for using each method to deploy SP2. The audience for this guide is information technology (IT) implementers who are responsible for executing the deployment planning advice described in the Windows XP Service Pack 2 Enterprise Planning Guide.

Important

  • If you are installing SP2 from the CD, the service pack installer file is called Xpsp2.exe. If you are downloading SP2 from the Microsoft Web site, the installer file is called WindowsXP-KB835935-SP2-xxx.exe (xxx stands for a specific language code, such as ENU for English). Both installer files are identical, they just have different names.

  • If you are downloading SP2 from the Web, for the purposes of this document, use WindowsXP-KB835935-SP2-xxx.exe wherever you see Xpsp2.exe.

Bb457083.3squares(en-us,TechNet.10).gif

On This Page

Overview
Designing the Deployment
Preparing the Service Pack
Developing Software Update Services
Developing Systems Management Server
Developing Group Policy
Managing New Group Policy Settings
Testing the Service Pack Deployment
Rolling Out SP2
For More Information

Overview

This guide describes and provides step-by-step instructions for using SUS, SMS, and Group Policy to deploy Windows XP SP2In this guide, you will find the following sections:

Designing the Deployment

This section describes essential decisions you must make when developing your SP2 deployment. These decisions are in addition to the planning decisions that the Windows XP Service Pack 2 Enterprise Planning Guide describes.

Preparing the Service Pack

This section describes how to initially prepare the SP2 files for deployment, including unpacking the files and preparing customizations for Windows Firewall.

Developing Software Update Services

This section describes how to deploy SP2 by using SUS. You can skip this section if you are not using SUS to deploy the service pack.

Developing Systems Management Server

This section describes how to deploy SP2 by using SMS. You can skip this section if you are not using SMS to deploy the service pack.

Developing Group Policy

This section describes how to deploy SP2 by using Group Policy. You can skip this section if you are not using Group Policy to deploy the service pack.

Managing New Group Policy Settings

This section describes the new Group Policy settings that SP2 provides and suggests those settings you should investigate during your SP2 deployment.

Testing the Service Pack Deployment

This section describes lab and pilot testing of an SP2 deployment. It includes checklists for recording the results.

Rolling Out SP2

This section describes the final stages of your SP2 deployment and makes suggestions for progressing through the Deploying Phase.

Before you begin the technical implementation of your SP2 deployment, Microsoft recommends that you read the documentation the company provides. Windows XP SP2 provides a huge leap in security, and it is important to understand the new security features. Not only can the documentation change the way you test, customize, and deploy the service pack, but it might also alter your current security procedures and policies. The resources in the section “For More Information” are essential reading. In particular, see the Guide for Installing and Deploying Microsoft® Windows® XP Service Pack 2.

Designing the Deployment

Before deploying SP2 to your organization, your implementation team should review the environment and software distribution policies to determine the best deployment method. In addition, the team must determine how SP2 will be customized for distribution. Because every environment is different, these issues might not represent your scenario entirely; the team must spend time reviewing the organization’s requirements.

Review and answer the following questions to better understand how to design your deployment:

  • How will the service pack be deployed? Does your software distribution policy require that software deployments install silently? Does your software distribution policy allow computer restarts? The requirements and policies for software distribution in your organization may be different from those in other organizations and sometimes different among branches in the same company. SP2 is a major deployment, so your software distribution policy may not apply to this update. Also, the service pack installation requires a computer restart, so you need to incorporate that into the deployment.

  • How many users will be working remotely during the service pack deployment schedule? You must determine the number of employees who will be working offsite, because this number may cause you to alter the deployment schedule. With a large deployment, you may want to designate a day for employees working off-site to visit the office (if possible) during the deployment. Consider creating a deployment window configured over a 3–4 day period, instead of over 3–4 hours, to accommodate the remote workers. You can even create a target collection for remote users only and distribute to them last.

  • What deployment schedule is required? Determine the best time to deploy SP2. Use several factors to determine the distribution window, such as the time of day with the least amount of network traffic or when employee productivity is at its lowest (possibly over the lunch hour or first thing in the morning).

  • Deploy to segmented groups? By container? By subnet? By business function? When using SMS to deploy SP2, you can easily make software products available to as many or few computers in your organization as necessary. The client computers that need to install the service pack must be members of a collection (referred to as the target collection). The target collection can contain a single client, all the client computers assigned to a specific site, or any subset of client computers. When the program is distributed to the target collection, all the client computers that are members of that collection receive the program. This method allows you to distribute programs to specific users, specific user groups, and any group of client computers that shares a common set of hardware or software attributes.

    If Microsoft® Active Directory® directory service is implemented in your organization, you can target a collection based on Active Directory containers. You can create a collection that targets systems based on organizational units (OUs), domains, site, and group membership; or you can create a collection that targets users based on domains, OUs, and group membership. To target systems for software distribution using Active Directory containers, at least one Active Directory discovery method must be enabled at the site.

    By planning to segment service pack delivery, you can minimize the impact to the network. Such planning also allows you to reduce your troubleshooting window. It is much easier to troubleshoot a handful of computers than the entire computer base at once.

Installation Options

Table 1 describes the command-line options that SP2 supports during installation. Determine the command-line options you must use to support your requirements. (These command-line options do not apply to Group Policy deployments of SP2.)

Table 1. Service Pack Command-Line Options

Command-Line Option

Description

/u or /passive

The installation runs unattended. If you use this option, only critical error prompts appear on the screen during the installation process.

/f

This option forces other applications to close at shutdown.

/n

Does not back up files for later removal of the service pack.

/o

The installation overwrites OEM files without prompting.

/z

The computer is not restarted after the installation is complete.

/forcerestart

The computer restarts after the installation is complete.

/norestart

This switch performs the same function as the /z option—namely, it specifies that the computer will not restart when the installation is complete.

/q or /quiet

The installation uses quiet mode (the same as unattended mode, but with the user interface (UI) hidden from view). If you use this option, no prompts appear on the screen during the installation process.

/l

This option lists installed updates, critical updates, and security updates.

/s: foldername

This option combines the operating system with the service pack in a shared distribution folder (where foldername represents the actual folder name) for an integrated installation.

/uninstall

This option uninstalls the package.

/help

This option displays the same information as the /? option.

/d: foldername

This option backs up files for removing the service pack into the folder you specify.

Deployment Types

SP2 supports several deployment scenarios. Knowing which deployment scenario (or combination of scenarios) you will use will determine factors such as server location (where the service pack files are stored in relation to the bulk of the users), server configuration (hardware, software, and so on to ensure the optimum server load), and network capacity planning (to make sure that the service pack deployment does not cripple the network or cause significant performance problems for the other business applications). The following list describes the scenarios for installing SP2:

  • Deploying the service pack so that computers use local service pack source files. With this method, you can run the installer from a centralized location, but the installer stores the service pack source files locally on each computer. This method ensures that Windows XP can replace system files without a connection to the share containing the service pack’s source files. Items affected include server location, server configuration, and network capacity.

  • Deploying the service pack so that computers use shared remote service pack source files. With this method, you can store service pack source files in the shared distribution folder rather than on local computers. However, Windows XP must have a connection to the share containing the service pack’s source files to replace system files. Items affected include server location, server configuration, and network capacity.

    Note: This guide does not cover these two methods. For more information, see Guide for Installing and Deploying Microsoft® Windows® XP Service Pack 2.

  • Deploying the service pack using SUS. For guidance on using SUS to install SP2, see the section “Developing Software Update Services.” Items affected include server location, server configuration, and network capacity.

  • Deploying the service pack using SMS For guidance on using SMS to install SP2, see the section “Developing Systems Management Server.” Items affected include server location. (SMS has the ability to throttle and thereby minimize its network use.)

  • Deploying the service pack by using Windows Installer and Group Policy. To use this method, you should have a good understanding of Windows Installer as well as a working knowledge of Group Policy and Active Directory. For more information about Windows Installer, Group Policy, and Active Directory, see the Windows Deployment and Resource Kits website. For guidance on using Group Policy to install SP2, see the section “Developing Group Policy.” Items affected include server location, server configuration, and network capacity.

Remote Users

Slower dial-up connections can cause significant issues for ensuring that the service pack is delivered and installed. SMS can deploy the service pack to the remote workstations efficiently by using bandwidth-sensitive technologies such as Microsoft® Internet Information Services (IIS), checkpoint restart, and Background Intelligent Transfer Service (BITS).

Also consider planning the deployment for a time when the remote employees are in the office (possibly during a company event), and then handle the smaller, normally remote group differently. Or, you may decide that creating and distributing service pack installation CD-ROMs is the best option for remote users.

Firewall Customizations

When designing your SP2 deployment, the implementation team should develop a plan based on your testing of the new Windows Firewall feature. For SP2 to work in your environment, you will need to either customize how Windows Firewall works or disable it altogether. The following guides explain how to customize and deploy the Windows Firewall features:

Chaining Post-SP2 Updates

Windows XP updates have Qchain.exe functionality built into the Update.exe installation program that allows you to install SP2 and then install any number of post-SP2 updates without having to restart the computer between installations. Consider the following points when chaining updates with SP2:

  • If multiple updates replace the same file, such as a system file (dynamic-link library (DLL) file), during installation, Qchain.exe ensures that the correct version is retained. If you install multiple updates, be sure to use the /z option, as shown in Table 2.

  • If the update you are installing does not use Update.exe as its installation engine, you might need to install that update separately.

Table 2 identifies the command-line options that the update supports.

Table 2. Update Command-Line Options

Command-Line Option

Description

/f

Forces other applications to close after installation and before restart

/n

Does not back up files for later removal of updates

/z

Does not restart the computer after the installation is completed

/q

Uses quiet mode; shows no UI

/o

Overwrites OEM files without prompting

/u

Uses unattended Setup mode; requires no user interaction and shows only critical errors

/l

Lists installed updates

For more information about performing a combination installation in which SP2 and post-SP2 updates are installed together, see The Guide for Installing and Deploying Updates for Microsoft® Windows® XP Service Pack 2.

Integrated Installation vs. Standalone Installation

There are two installation methods for SP2:

  • Integrated. An installation in which the operating system and the service pack are installed together as a single installation. Use integrated installations for new computers or to replace the operating system during a desktop deployment.

  • Standalone. A service pack that is not integrated with other software and can be used to update the operating system it is designed for. Use standalone installations to update computers already running Windows XP Professional to SP2.

This guide does not describe the integrated installation process. For more information about integrated installations, see Guide for Installing and Deploying Microsoft® Windows® XP Service Pack 2. For guidance on planning and executing an integrated installation to new computers, see the Solution Accelerator for Business Desktop Deployment Standard Edition and Solution Accelerator for Business Desktop Deployment 2.0 Enterprise Edition.

Preparing the Service Pack

Even before developing a plan for deploying SP2, you should download and prepare the service pack for deployment. Going through the steps that follow will give you the information you need to complete your deployment plan. Several key pieces of information will aid in deployment planning:

  • The compressed and uncompressed size of the service pack. Knowing the size of the service pack will help you determine how to deploy it and where to store it during deployment. Knowing the size will also give you the necessary data for checking and verifying network links and speeds. If you will be using SMS, you will be able to preconfigure the SMS client to ease the burden of a large deployment.

  • The components that can be customized for SP2 deployment, such as Windows Firewall. One size will probably not fit all if you need to control the features and options of SP2. Understanding your options for a custom deployment is important for developing a strong deployment policy.

  • Review the Readme and Release Notes files after the service pack is uncompressed. Any service pack that Microsoft releases contains important information in the Readme and Release Notes that can alter the way you distribute that service pack. Review these files immediately after the service pack is downloaded and uncompressed.

  • The new features that could change the computing landscape. SP2 incorporates new features and functions. For a full description of these changes and how they may affect your enterprise’s environment, see Changes to Functionality in Microsoft Windows XP Service Pack 2.

Step 1. Obtain the Service Pack

Download SP2 from Windows XP Service Pack 2 Resources for IT Professionals. For enterprise customization and deployment, you need to download the network installation package.

Step 2. Unpack the Service Pack

The network installation package (Xpsp2.exe) is a self-extracting package that contains all the files required for SP2 installation on any computer already running Windows XP. This package copies all SP2 files to the target computer, making it effective for administrators who want to set up a shared network folder for deploying the service pack on multiple computers. The service pack can be deployed in its compressed file as downloaded from the Microsoft website, but for an enterprise, you will want to unpack the service pack to allow customization prior to deployment. To unpack SP2, perform these steps:

  1. Download the full network installation of SP2 (Xpsp2.exe), and save it to a newly created directory on your hard drive or network share.

  2. Create a folder to contain the SP2 files you are about to extract.

  3. In the Run dialog box or at a command prompt, type path\xpsp2.exe –x, where path is the path to the file you downloaded. In the dialog box that appears, select the folder you created in Step 2.

Xpsp2.exe provides an additional command-line option that allows you to skip the requirement to provide the path for service pack extraction. Table 3 lists the two methods for extracting the service pack.

Table 3. Command-Line Options for Extraction

Command-Line Option

Description

/x

This option extracts service pack files without starting Update.exe. You are prompted to provide the path for the folder to which you want to extract Xpsp2.exe.

/u /x:foldername

This option extracts service pack files to the service pack folder (designated here by foldername) without prompting and without starting Update.exe.

Step 3. Customize Windows Firewall

SP2 includes significant enhancements to Windows Firewall, formerly known as the Internet Connection Firewall (ICF), included in previous Windows XP versions. One enhancement is that Windows Firewall is enabled by default during a standalone or integrated installation of SP2. As a result, network administrators need the flexibility to modify the default configuration of Windows Firewall during and after SP2 installation. The implementation team might need to modify the default Windows Firewall configuration for the following reasons:

  • A non-Microsoft firewall is enabled. If your enterprise already uses a non-Microsoft firewall, it is recommended that you install SP2 with Windows Firewall disabled.

  • You have preinstalled programs that require specific, unsolicited incoming traffic. Testing for application compatibility will determine which applications require Windows Firewall customization to allow uninterrupted service.

  • You need to pre-open specific network ports because of particular environment requirements. SP2 is designed to lock down a computer running Windows XP and put it into a fully secure mode of operation. Therefore, you must customize Windows Firewall to work with the applications and services in your environment. For example, connections to a Microsoft® SQL Server™ application may not work correctly until Windows Firewall is configured to allow specific port access.

Windows Firewall can be preconfigured by modifying the Windows Firewall .inf file, called Netfw.inf, in which the default Windows Firewall configuration resides. During standalone or integrated installation of SP2, Windows Firewall imports its configuration from this .inf file, which means that any modifications made to the.inf file prior to installation will automatically be incorporated into the default Windows Firewall configuration.

This guide does not cover the specific steps for customizing Windows Firewall. Instead, see the following resources:

Developing Software Update Services

The following sections describe how to use SUS to deploy SP2:

  • “Server Structure.” This section helps you evaluate your current SUS infrastructure.

  • “Server Configuration.” This section describes how to configure the SUS servers.

  • “Client Configuration.” This section describes how to configure SUS clients for SP2.

Server Structure

SUS can be deployed in many configurations, but most configurations fall into one of two categories: single SUS server deployment or hierarchical SUS server deployment. This section describes both structures for use with SP2 deployment.

Single SUS Server Deployment

In this configuration, all clients in the enterprise leverage the single SUS server for all client updates and service packs—including SP2. All updates are approved on one server and delivered to all clients who use this server.

This configuration might be acceptable for a small company or a small workgroup (25 or fewer clients). However, it might not be ideal if the company is larger, has multiple departments or wants more control over when the service pack is deployed.

In this configuration, multiple departments, workgroups, or business units would use the same SUS server. However, this single SUS server topology does not provide the maximum flexibility for larger environments. In larger environments, you will not typically want all computers in the same workgroup to install SP2 at the same time. Therefore, consider using a hierarchical SUS server deployment..

Hierarchical SUS Server Deployment

A hierarchy of SUS servers has several advantages:

  • You can download the service pack just once from Microsoft and maintain it on your intranet.

  • You can choose when to deploy SP2 (and other software updates) to clients without the risk of deploying to all computers at once.

  • You can control the bandwidth and distribute the load. Client groups will use different servers, possibly on different subnets.

You can convert an existing single SUS server deployment to a hierarchal model with a parent SUS server containing multiple child SUS servers (see Figure 1). If you have not yet deployed any SUS servers, you can develop your own SUS hierarchy from scratch. In all cases, this guide assumes that you have successfully loaded SUS on one server in your environment.

In this model, no client computers use the parent SUS server to receive updates. All clients use one of the child SUS servers to receive SP2. It is suggested that you also maintain a separate test SUS server with a representative client sample to first gauge the impact of SP2 before rolling it out to larger production.

This SUS hierarchical design provides administrators with more control over which client collections should be updated.

Figure 1. Suggested SUS Hierarchy

Figure 1. Suggested SUS Hierarchy

Note: To download Microsoft SUS, see Software Update Services Home.

Server Configuration

To have an SUS hierarchy, both the parent and the child SUS servers must be configured correctly. To do so, set options on the Set Options page of the parent and child SUS servers:

  • On the Set Options page of the parent and child SUS servers, select the Save updates to a local folder option.

  • On the Set Options page of the parent servers, select all the locales that the child servers will need to use. On each child server, select only the locales that that child server needs to support. Make sure that sufficient disk space is available for all locales.

    Note: Attempting to synchronize locales on second-tier SUS servers that the parent SUS server has not downloaded may produce errors in the SUS logs.

  • On the Set Options page of the child servers, select the Synchronize from a local Software Updates Services server option, and then type the name of the parent SUS server (see Figure 2).

    Figure 2. Child Server Configuration

    Figure 2. Child Server Configuration

This guide also suggests that you clear the Synchronize list of approved items updated from this location (replace mode) option, which ensures that approved updates at the parent are not automatically approved at the child SUS servers. This way, you can manually approve your chosen updates for a specific collection of computers.

Note: Configure your child SUS servers to synchronize automatically with the parent SUS server at least one hour after the parent server is scheduled to pull updates from Microsoft’s servers.

Client Configuration

After your parent and child SUS servers are deployed, you must specify which client computers should use which child server. Clients will receive the SP2 package only from child servers, not from parent servers.

A typical Active Directory domain environment has many OUs with computer accounts already set up. You can instruct your Windows XP client computers to update from a specific SUS child server in one of two ways: by using Group Policy Objects (GPOs) linked to the OUs or by using group memberships.

Using GPOs Linked to OUs To Deploy SP2

You can link GPOs to OUs that contain computer objects, as shown in Figure 3. All computers within the OU will use the specific SUS server dictated in the GPO. Therefore, when SP2 is approved on a specific child server, all computers in the OU will install it within 24 to 48 hours.

Figure 3. Using OUs to Deploy SP2

Figure 3. Using OUs to Deploy SP2

Because you can control which client computers are leveraging a specific SUS server, this method is excellent for controlling bandwidth use. However, this method is not ideal for ensuring that installations of SP2 will be staggered among computers in the workgroup. Again, you should ensure that not every computer in a specific workgroup or business unit is affected at the same time.

Using Group Membership To Deploy SP2

Instead of linking the GPO at the OU level, you can create security groups for your client computers that span different OUs. Then, create and link GPOs at the domain level but filter by specific security groups that contain those computer accounts. As Figure 4 shows, three security groups that span OU boundaries are created:

  • COMPUTER-GROUP1 contains Sales-Computer1, Marketing-Computer1, and HR-Computer1.

  • COMPUTER-GROUP2 contains Sales-Computer2, Marketing-Computer2, and HR-Computer2.

  • COMPUTER-GROUP3 contains Sales-Computer3, Marketing-Computer3, and HR-Computer3.

    Figure 4. Using Group Membership To Deploy SP2

    Figure 4. Using Group Membership To Deploy SP2

Then, three individual GPOs are linked to the domain that specify which SUS server each group uses. However, the GPO is filtered by security group. In this example, the GPOs named Use SUS Child Server 1, Use SUS Child Server 2, and Use SUS Child Server 3 are all linked to the domain.

In Figure 5, the Authenticated Users group is removed from the Security Filtering section of the GPO, and COMPUTER-GROUP1 is added. Therefore, the Use SUS Child Server 1 GPO will apply only to computers in the Computer-Group1 security group.

Figure 5. Using Security Filtering Within a GPO To Deploy SP2

Figure 5. Using Security Filtering Within a GPO To Deploy SP2

For each new GPO you create, you need to specify the settings that tell each collection of client computers what time to install SP2 and which child SUS server to download from. These settings reside in Computer Configuration\Administrative Templates\Windows Components\Windows Update. Four policy settings dictate SUS client-side behavior:

  • Configure Automatic Updates. After you enable this policy setting, as shown in Figure 6, you can specify at what time this collection of computers will install SP2 from the SUS server. However, the most important setting to modify is the Configure Automatic Updates setting. When set to 4, the client will install the approved software updates at the appointed time, including SP2 if it is selected at the appointed child SUS server. Note that it could take 24 to 48 hours for this setting to take effect after SP2 is approved at the child SUS server.

    Figure 6. Configuring Automatic Updates

    Figure 6. Configuring Automatic Updates

  • Specify intranet Microsoft update service location. You must enable this policy setting for client computers to locate a child SUS server. Then, in both the Set the intranet update service for detecting updates text box and the Set the intranet statistics server text box, type the name of the child SUS server in the form of http://servername.

  • Reschedule Automatic Updates scheduled installations. If a client computer is turned off at the time scheduled for SP2 installation, you can choose to have the service pack installed at the next computer restart before the user logs on to the computer. Enable this policy to ensure that the SP2 is installed.

  • No auto-restart for scheduled Automatic Updates installations. This setting allows you to choose whether to restart the computer if the user is logged on to the computer. If this setting is enabled, logged-on users are asked if a computer restart is okay. If this setting is disabled or not configured, logged-on users are informed that they have 5 minutes to save their work before a computer restart is forced.

Developing Systems Management Server

Using SMS is the easiest and surest method for deploying SP2 to your enterprise successfully and accurately. If you already use SMS for software distributions and security updates, you should have developed a software distribution policy and framework. This framework should consist, at the very least, of each of the following steps:

  • Assess the environment on an ongoing basis by constantly reviewing the software distribution architecture, managing SMS client breadth and health, and conducting inventories.

  • Download SP2, determine its relevance to the environment, verify the authenticity of the service pack by installing it on an isolated system, and determine the enforcement time frame. For more information, see the section “Preparing the Service Pack.”

  • Evaluate and plan the SP2 deployment to ensure that testing, risk assessment, and release processes are in place. For more information, see the section “Designing the Deployment.”

  • Deploy SP2, which includes distributing and installing the service pack, monitoring and reporting on progress and success or failures of the deployment, dealing with exceptions, and conducting a review of the deployment.

Assessing the Environment

Prior to developing the deployment plan and delivery schedules, review your current SMS infrastructure, including the ability to deliver software and any SMS client requirements for participating in the rollout. Review the following guidelines to make your SP2 deployment a success.

Find and Fix Problematic Clients

Locate any SMS clients that have not recently reported and also those whose records may not be present in the SMS Administrator Console. In some cases, you may need to reinstall or repair the SMS client to make sure that the computer is suitable for SP2 installation.

Gather and Verify Computer Inventory

Before SP2 deployment, make sure that all SMS clients have reported their inventory. To ensure that the SMS data is accurate for creating queries and collections, change the hardware and software schedule so that SMS clients perform inventory cycles a day or so prior to deploying SP2. If you need to force hardware and software inventory before the SMS client receives the updated inventory schedule (remote clients, for example), you can distribute the VBScript scripts shown in Listing 1 and Listing 2 to force inventory cycles.

Listing 1. Force Hardware Inventory

Set cpApplet = CreateObject("CPAPPLET.CPAppletMgr")
Set actions = cpApplet.GetClientActions
For Each action In actions
    If Instr(action.Name,"Hardware Inventory") > 0 Then
        action.PerformAction
End if
Next

Listing 2. Force Software Inventory

Set cpApplet = CreateObject("CPAPPLET.CPAppletMgr")
Set actions = cpApplet.GetClientActions
For Each action In actions
    If Instr(action.Name,"Software Inventory") > 0 Then
        action.PerformAction
End if
Next
Test SMS Software Deployment

There are two primary forms of testing for successful SP2 deployment:

  • Test the production environment’s implementation of software distribution in terms of connectivity and reporting.

  • Test SP2 itself for installation on computers representative of the production environment.

To test the SMS 2003 environment, the inventory, the collections, and connectivity, deploy a test package (that is, an inert payload) to one or more collections within the production environment. When an administrator deploys a distribution package that contains only a test package, it generates all the SMS 2003 reports and status messages that indicate how successfully the update reached all targeted computers. However, the test package has no impact on the production environment; it does not alter the target computers or force any restarts.

Note   SMS 2003 Toolkit 1 includes a tool for test packages and is available as a free download from Systems Management Server 2003 Toolkit 1.

Increase the Advanced Client Cache Size

When the SMS Advanced Client is installed using defaults, a 250 MB download cache size is created. SP2 is roughly 270 MB, so you will need to increase the download cache size allocated for the SMS clients in preparation for SP2 deployment. The VBScript script shown in Listing 3 checks to see if the default cache size of 250 MB is used, and if so, increases the available download cache size to 1 GB. (You can modify the nValueToSet value to specify the cache size you want to use.) Distribute this script to all your Windows XP computers.

Listing 3. Increase the Advanced Client Download Cache

On Error Resume Next
 
Dim nValueToCheck
Dim nValueToSet
 
Dim oUIResource
Dim oCache
 
Set oUIResource = CreateObject("UIResource.UIResourceMgr")
Set objCacheInfo = oUIResource.GetCacheInfo
 
nValueToCheck = 250
nValueToSet = 1000
 
' Set the cache size if it's less than or equal to 250
if objCacheInfo.TotalSize <= nValueToCheck then
    objCacheInfo.TotalSize = nValueToSet
end if

Preparing for Deployment

You must perform some preliminary steps prior to SP2 deployment in your organization. Using your deployment plan to fill in the data required, perform the steps described in the following sections.

Note: Microsoft has compiled a list of potential issues that you need to be aware of prior to deploying SP2 in an SMS environment. Review all the SMS client issues and workarounds included in the Clients Frequently Asked Questions.

Create Collections

Collections, in which membership rules are based on queries, are dynamic. After you create the initial membership list, clients are automatically added to or removed from the collection, as appropriate. After you create the initial membership list, SMS adds or removes client computers as their attributes change (although clients’ updates are not uninstalled when the client is removed from the collection). In a dynamic environment, SMS keeps collections current, thus ensuring that only the appropriate clients receive distributed programs.

A standalone SP2 installation can be performed only on a computer that is running Windows XP Home Edition or Windows XP Professional, so you need to create a collection based on queries that locate all Windows XP computers in your organization. To create a collection, perform these steps:

  1. In the SMS Administrator Console, click Site Database in the left pane, and then click Collections.

  2. Right-click Collections, point to New, and then click Collection.

  3. In the Collection Properties dialog box, complete these settings on the following tabs:

    • On the General tab, specify the general data for the collection.

    • On the Membership Rules tab, specify how and when resources are added to this collection. Add the Windows XP queries to the Membership rules area, as shown in Figure 7.

      Figure 7. Windows XP Collection Membership Rules

      Figure 7. Windows XP Collection Membership Rules

After the collection has been created, use the queries shows in Listing 4 to create your Windows XP collection.

Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

Listing 4. Windows XP Collection Membership Queries

select sms_r_system.ResourceID,sms_r_system.ResourceType,
sms_r_system.Name,sms_r_system.SMSUniqueIdentifier,
sms_r_system.ResourceDomainORWorkgroup,sms_r_system.Client from 
sms_r_system where OperatingSystemNameandVersion like '%Workstation 5.1%'
 
select SMS_R_System.ResourceID,SMS_R_System.ResourceType,
SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,
SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from 
SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on 
SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId 
where SMS_G_System_OPERATING_SYSTEM.Version = "5%"
Create the Package

Next, generate an empty record, or package, in which the program will be placed. To create a package, perform these steps:

  1. In the SMS Administrator Console, click Site Database in the left pane, and then click Packages.

  2. Right-click Packages, point to New, and then click Package.

  3. In the Package Properties dialog box, shown in Figure 8, complete these settings on the following tabs:

    • On the General tab, specify general data for a package, such as the package name and version.

    • On the Data Source tab, specify data source settings, such as the package source folder (that is, the folder in which the SP2 files are stored).

    • On the Data Access tab, configure access to the package data files, such as the distribution share name.

    • On the Distribution Settings tab, configure distribution point settings, such as scheduling updates to package data.

    • On the Reporting tab, configure how SMS identifies package status information.

    • On the Security tab, specify security settings for the new package.

SMS displays the new package in the SMS Administrator Console, and it adds the Users package access account, with read permission, to the access accounts for this package.

Figure 8. Creating a Package

Figure 8. Creating a Package

Create the Program

After the package record has been created, you need to place the actual program (full path and file name) information into it. To create the program information, perform these steps:

  1. In the SMS Administrator Console, click Site Database in the left pane, click Programs, and then click Packages, package, where package is the package you created in the previous section.

  2. Right-click Programs, point to New, and then click Program.

  3. In the Program Properties dialog box, shown in Figure 9, complete these settings on the following tabs:

    • On the General tab, specify general package properties.

    • On the Requirements tab, specify processor and operating system (Windows XP) platforms.

    • On the Environment tab, specify user settings, drive modes, and other properties.

    • On the Advanced tab, specify a prerequisite program and other advanced settings.

      Figure 9. Program Settings

      Figure 9. Program Settings

Distribute the Package

After the package has been created, SP2 is ready for deployment to the distribution points. To initiate SP2 deployment to the Distribution Points, perform these steps:

  1. In the SMS Administrator Console, click Site Database in the left pane, and then click Packages.

  2. Right-click the package you want to send to the distribution points, point to All Tasks, and then click Manage Distribution Points.

  3. Complete the Manage Distribution Points Wizard, as shown in Figure 10, and then click Finish.

SMS sends a copy of the package data to each new distribution point.

Figure 10. Manage Distribution Points Wizard

Figure 10. Manage Distribution Points Wizard

Deploying SP2

After all the deployment preparations have been completed and authorization for deployment has been received, you can deploy SP2. Deployment is more than simply throwing a switch and allowing the service pack to filter through the organization: The deployment must be monitored and may require troubleshooting. Deployment also means seeing that the SMS clients received the SMS advertisement, that the SMS clients initiated the program, and that they installed the program correctly and performed the post-installation tasks. The first step in deployment is to create and configure the advertisement, including setting the schedule for deployment:

  1. In the SMS Administrator Console, click Site Database in the left pane, and then click Advertisements.

  2. Right-click Advertisements, point to New, and then click Advertisement.

  3. In the Advertisement Properties dialog box, shown in Figure 11, complete these settings on the following tabs:

    • On the General tab, specify the advertisement name, the collection of clients, the package, and the program.

    • On the Schedule tab, schedule the program to run on clients based on the rollout schedule you have developed. If you do not schedule the advertisement, SMS makes the program available immediately.

    • On the Security tab, specify security settings for the new advertisement.

SMS sends the advertisement data, including the schedule information, to Client Access Points (CAPs) in the site.

Figure 11. Service Pack 2 Advertisement Properties Dialog Box

Figure 11. Service Pack 2 Advertisement Properties Dialog Box

Monitoring the Deployment

After SP2 deployment has begun, you will need to determine whether the clients have successfully run the advertisement. There are several SMS 2003 tools that you can use to check the status messages returned from SMS clients. One such tool, the Advertisement Status Viewer, gives a view of the deployment status of advertisement based on their status messages. To take full advantage of the status messages, the administrator first determines:

  • Which clients were in the collection but have not received the advertisement.

  • Which clients have received the advertisement but have not run it.

  • Which clients were unsuccessful in running the service pack.

Status messages tell only whether the advertisement was run. The installation program installs any new, approved updates. To check that the program is running successfully on clients, the SMS administrator analyzes the status messages to determine when the program was last successfully run on each client. The SMS administrator investigates delays, which can occur if, for example, an SMS client is not turned on or is not functioning correctly.

The SMS administrator also checks status messages to find out the number of desktop users who voluntarily installed the service pack versus those who underwent enforced installation and how the users who installed the service pack are managing restarts and scheduled installation.

Cleaning Up After Deployment

After SP2 deployment, you should review the deployment and perform additional measures to ensure continuing success with new computers that connect to the network. For example, remote employees may not have received the advertisement yet.

After the service pack deployment window, force another software and hardware inventory cycle on the SMS client computers to refresh the data in the SMS database. Use queries to verify that all targeted computers are now at the SP2 level. Use the query shown in Listing 5 to identify the Windows XP version levels for all computers in your organization.

Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

Listing 5. Reassess Windows XP Version Levels

select SMS_G_System_COMPUTER_SYSTEM.Name, 
SMS_G_System_OPERATING_SYSTEM.Version, 
SMS_G_System_OPERATING_SYSTEM.BuildNumber 
from  SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM 
on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId 
inner join SMS_G_System_OPERATING_SYSTEM on 
SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where 
SMS_G_System_OPERATING_SYSTEM.Version > "5%" order by 
SMS_G_System_OPERATING_SYSTEM.Version, 
SMS_G_System_OPERATING_SYSTEM.BuildNumber

If you note any Windows XP computers that did not install SP2 correctly or are not reporting correctly, inspect each one individually to make sure that the SMS data is correct and that SP2 can install correctly.

Developing Group Policy

You can use built-in technology in Active Directory to stage SP2 deployment. If you choose to use Group Policy to deploy SP2, this guide suggests that clients download SP2 from the closest possible non-network source. Deploying SP2 via Group Policy consists of three main steps:

  • Setting up a share and optionally using the Distributed File System (DFS)

  • Placing the service pack in the share or in all shares that DFS uses

  • Targeting specific computers with Group Policy Software Installation

    Note: If a Windows XP client computer is in the scope of a GPO, it must be restarted two times to process the request. At that point, SP2 will be installed while the computer is starting up.

Configuring DFS for SP2

This guide recommends that you set up a DFS configuration for SP2 deployment in a hub-and-spoke configuration. One example that should suit most organizations with multiple Active Directory sites is shown in Figure 12. In this configuration, place the SP2 initially in the designated hub server, then use the File Replication Service to deliver SP2 to the DFS spoke servers.

Figure 12. Hub-and-Spoke DFS Configuration

Figure 12. Hub-and-Spoke DFS Configuration

To set up the first DFS link, perform the following steps:

  1. Create a shared folder on a file server or on the hub DFS server. Then, unpack SP2 into the shared directory. For the command-line option for unpacking SP2 to a directory for distribution, see the section “Preparing the Service Pack.”

  2. Click Start, point to All Programs, point to Administrative Tools, and then click Distributed File System to launch the Distributed File System console.

  3. In the Distributed File System console, Click Action, and then click New Root to launch the New Root Wizard. Complete the wizard to create a new domain root.

  4. At the Welcome screen, click Next to access the Root Type screen. Your account must have rights to create a domain root. Select the domain root, and then click Next.

  5. On the Host Domain screen, confirm the domain name, and then click Next.

  6. On the Host Server screen, type the name of the server that will initially host the DFS root. Click Next.

  7. On the Root Name screen, which Figure 13 shows, type a root name and a comment if desired, and click Next.

    Figure 13. New Root Wizard

    Figure 13. New Root Wizard

  8. On the Completing the New Root Wizard screen, confirm your settings, and then click Finish.

For each spoke server, perform the following steps:

  1. Right-click the new root, and then click New Root Target to add a spoke DFS server.

  2. On the Host Server screen, type the name of the spoke server, and then click Next.

  3. On the Root Share screen, specify a directory to house the replica, and then click Next. The wizard automatically creates a share for the directory specified.

  4. On the Completing the New Root Wizard screen, verify your settings, and then click Finish.

To begin initial replication between the root and the spoke servers, perform the following steps:

  1. Right-click the root, and then click Configure Replication.

  2. On the Welcome to the Configure Replication Wizard screen, click Next.

  3. On the Select an Initial Master screen, select the root server as the initial master, and then click Next.

  4. On the Topology page, select the Hub and spoke option, and then click Finish.

    Note: For general DFS how-to information, see Distributed File System and File Replication Services.

Creating Group Policy Objects

Now that your distribution network is set up to deploy SP2 via DFS, you can create the GPOs to distribute the service pack to your client computers. To do so, you assign Update.msi to target computers. Update.msi is the Windows Installer package file for Service Pack 2. It’s in the service pack folder’s i386\update subfolder. Perform the following steps to assign Update.msi to computers:

  1. In the Group Policy Management Console, right-click the Group Policy Objects node, and then select New.

  2. In the Name text box, type a name for your GPO, and then click OK.

  3. In the Group Policy Objects node, right-click the new GPO, and then click Edit.

  4. In the Group Policy Object Editor in the Computer Configuration\Software Settings folder, right-click Software installation, point to New, and then click Package.

  5. In the File name text box, type the full Universal Naming Convention (UNC) path of the DFS root, including the path to the Update.msi file (for example, \\woodgrovebank.com\xpsp2\i386\update\update.msi), and then click OK.

Targeting Specific Computers

A typical Active Directory domain environment has many OUs with computer accounts already set up. When ready, you can target specific computers. There are three main ways to target specific computers:

  • By GPOs linked to OUs

  • By GPOs linked to OUs and then filtered by Windows Management Instrumentation (WMI) filters

  • By GPOs linked to the domain level, then filtered by security group membership

By Using OUs

You can link a GPO to OUs that contain computer objects. In this way, after the GPO is linked to a specific OU, all the Windows XP computers in that OU will install SP2. Note, however, that this method is not ideal for performance and stability, because not every Windows XP computer in a specific workgroup or business unit is affected at the same time.

Note: Non-Windows XP computers will initially attempt to load SP2 but will simply ignore the assignment. In fact, these computers will continue to try to load (and ignore) the SP2 assignment upon every restart. To mitigate this behavior, consider creating an OU that contains non-Windows XP computers, such as Microsoft® Windows 2000 Professional computers, so that they are not in the scope of management for the GPO. Alternatively, you can use security group filtering (described later) to define the scope of the GPO such that non-Windows XP computers are filtered out of the GPO.

By Using OUs and WMI Filters

Instead of deploying SP2 to all Windows XP computers within an OU, you can limit deployment to specific Windows XP computers. For instance, you might want to deploy SP2 only to Windows XP computers with 256 MB of RAM, 1 GB of free disk space, or other properties. To do so, you must create a WMI filter.  Perform the following steps to create a WMI filter:

  1. In the Group Policy Management Console, right-click the WMI Filters node, and then click New.

  2. On the New WMI Filter dialog box, type a name for your WMI filter.

  3. Click Add; in the WMI Query text box, type your WMI query, and then click OK.

  4. On the New WMI Filter dialog box, click Save.

Perform the following steps to link a WMI filter to a GPO:

  1. In the Group Policy Management Console, find the GPO for which you want the WMI filter to apply.

  2. On the Scope tab of the GPO, select the WMI filter you want to use in the This GPO is linked to the following WMI filter list.

  3. Click Yes to confirm the WMI filter.

    Figure 14. Targeting Computers by Using WMI Filters

    Figure 14. Targeting Computers by Using WMI Filters

(For information about crafting WMI filters, see WMI Filters Overview.) In the example that Figure 14 shows, a GPO that assigns SP2 is linked to each OU containing Windows XP computer accounts. However, only Windows XP computer accounts that meet the criteria in the WMI filter will actually apply the service pack.

By Using Groups

Instead of linking a GPO to the OU level that instructs clients to download SP2, you can create Active Directory security groups that contain Windows XP client computers that span different OUs. Then, create and link a GPO to the domain level but filter the scope to specific security groups (see Figure 15).

Use the following steps to create a new group in Active Directory:

  1. In the Active Directory Users and Computers console, right-click any OU or folder, point to New, and then click Group.

  2. In the New Object – Group dialog box, type the name of the group. For instance, you may want to name the group XPCOMPUTER-GROUP1. Ensure that the Group scope is set to Global and that the Group type is set to Security; click OK.

  3. In Active Directory Users and Computers, right-click the new group, and then click Properties. On the Members tab, click Add, and then add the computers that should be members of this first group.

Perform the following steps to link the GPO to the domain:

  1. In the Group Policy Management Console, right-click the domain level, and then click Link an Existing GPO.

  2. Select the GPO you want the link to the domain.

Perform the following steps to filter the GPO by the group you previously created:

  1. On the GPO you just linked to domain, select the Authenticated Users group from the Security Filtering section, and then click Remove.

  2. In the Security Filtering section, click Add, and then select the newly created group.

In this example, the GPO named Assign XP/SP2 to Computers is linked to the domain. The default Authenticated Users group is removed from the Security Filtering section of the GPO, and XPCOMPUTER-GROUP1 and XPCOMPUTER-GROUP2 are added. Therefore, the Assign XP/SP2 to Computers GPO will apply only to Windows XP computers in the XPCOMPUTER-GROUP1 and XPCOMPUTER-GROUP2 groups.

Figure 15. Targeting Computers by Using Groups

Figure 15. Targeting Computers by Using Groups

Managing New Group Policy Settings

As soon as SP2 is delivered to a client and the computer is restarted, the computer and user are managed by the new Group Policy settings. There are approximately 600 new policy settings that will be recognized after SP2 is installed. For a list of SP2 policy settings, see Group Policy Settings Reference for Windows XP Professional Service Pack 2. This downloadable Microsoft® Office Excel spreadsheet makes it easy to determine which policy settings will affect SP2 clients. The spreadsheet also makes it easy to find the path to enable or disable specific policy settings and provides a copy of the corresponding policy settings’ Help text. To implement these settings in your domain so that they are available for all Windows XP clients, See Knowledge Base article 816662, “Recommendations for managing Group Policy Administrative Template (.adm) files.”

Although SP2 adds many new policy settings, you must choose carefully which new policy settings to implement because by doing so, you could be turning off the more secure behavior of the new SP2 defaults. Therefore, consult the Help text for each policy setting, then test and validate in the test lab each possible policy setting you think you might use in production.

Managing Windows Firewall

One SP2 feature that you will use Group Policy to manage is Windows Firewall. The Windows Firewall policy settings reside in Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall. Within the Windows Firewall node, you will find the same policy settings contained under Domain Profile and Standard Profile, as shown in Figure 16:

  • Domain Profile. When you configure the policy settings within the Domain Profile node, computers will only use these configured policy settings when authenticated to a domain controller.

  • Standard Profile. A different set of firewall configuration options is available within the Standard Profile node for when a computer is disconnected from the domain network. That is, the computer has physical connectivity to a network but is not able to contact a domain controller for authentication. For instance, you might want to turn off Windows Firewall for a computer when that computer is connected to the domain, but ensure that the firewall remains on when the user is in a hotel or connected to another network.

    Note: For more information about how a computer determines whether it should use the Domain Profile settings or the Standard Profile settings, see Network Determination Behavior for Network-Related Group Policy Settings.

    Figure 16. Windows Firewall Policy Settings

    Figure 16. Windows Firewall Policy Settings

It is recommended that most enterprises configure the following Windows Firewall policy settings:

  • Windows Firewall: Allow remote administration exception. This policy setting opens specific ports to allow for continued use of the Resultant Set of Policy (RSoP) functionality in Windows 2003 and in the Group Policy Management Console. Unless Windows XP client computers have the Windows Firewall: Allow remote administration exception policy setting is enabled, RSoP functions will result in an error because Windows Firewall has blocked the request. Additionally, if this policy setting is enabled, the normal suite of administration tools, such as Active Directory Users and Computers and Active Directory Domains and Trusts will continue to work properly if installed and run on Windows XP computers, because there is communication on port 445 between these administrative tools and the Windows XP computer.

  • Windows Firewall: Protect all network connections. Set this policy to Disabled to immediately disable the enhanced SP2 Windows Firewall and reverse the default status enabled on all SP2 client computers. Change this setting only if directed by your corporate policy or if you encounter an emergency condition where applications are unable to communicate as before.

Testing the Service Pack Deployment

SP2 constitutes a major upgrade to Windows XP, so testing the service pack before deploying to the production environment is particularly important. You should test the service pack in two areas: application compatibility and hardware compatibility. Before deploying SP2, test your applications to ensure that they are compatible with the new operating system level. An organization can have as many as several thousand applications installed across distributed networks, and compatibility problems with one or many of these applications can cause costly productivity troubles.

The applications that you need to test to ensure compatibility include core applications that are part of your standard desktop configurations, such as office productivity suites; line-of-business (LOB) applications, such as enterprise resource-planning suites; administrative tools, such as antivirus, compression, backup, and remote-control applications; and custom tools, such as logon scripts. Low-level applications—such as antivirus applications, kernel-mode drivers, and filter drivers—are especially likely to pose problems. You also need to ensure that your server applications are compatible.

Application compatibility testing begins with identifying and prioritizing the applications in use throughout your organization, which helps you determine the objectives and scope of the project. After establishing priorities and examining special considerations for server applications, you can develop the test plan. As you encounter compatibility problems during testing, you will need to develop solutions, test them, and then package them for deployment. To resolve application compatibility problems, perform the following tasks:

  1. Identify the applications that you need to test. Create an inventory of your applications and determining their level of importance to your organization. If you are using SMS, you can create queries and reports to identify all the applications in your organization. If your organization does not use SMS, you can use the Windows Application Compatibility Toolkit (ACT) 3.0, which contains the following tools:

    • Microsoft® Windows Application Compatibility Analyzer. Simplifies application inventory and compatibility testing

    • Windows Application Verifier. Assists developers and testers in locating common compatibility issues during the development cycle

    • Compatibility Administrator. Provides access to the necessary compatibility updates to support legacy applications in Windows.

  2. Identify application compatibility problems. This step includes testing and possibly debugging your applications to detect, locate, and correct logical or syntactical errors. It is suggested that instead of relying on your knowledge of how the applications are supposed to work, you enlist the help of the people who actually use the applications. Doing so will improve your ability to pinpoint application problems.

  3. Resolve application compatibility problems. Identify and create application compatibility solutions, including possibly modifying the source code and recompiling applications for which you have the source code, if the application was developed in-house. You may also need to contact the application vendor or developer for help with resolving application compatibility problems during your testing. Make use of ACT 3.0.

  4. Deploy or distribute applications and solutions. You can use various Windows XP Professional and Windows Server 2003 deployment and distribution tools, such as SMS.

Common compatibility problems you should look for when testing SP2 are:

  • Setup and installation. An application may exhibit setup and installation problems because it:

    • Writes entries directly to the registry without using the Windows Installer service or the shell Application Programming Interfaces (APIs).

    • Checks for a specific version of the operating system.

    • Does not support hard drives larger than 2 GB.

    • Does not support long file names.

    • Tries to access hardware directly rather than by calling the appropriate APIs.

  • Kernel-mode drivers. The most common types of programs that exhibit kernel-mode driver problems are antivirus programs, personal firewall programs, disk defragmenting programs, and CD-writing programs.

  • Permissions. Permissions problems can occur when an application tries to access areas of the file system or registry that are accessible by all users and applications in an earlier version of the Windows operating system but are no longer accessible in Windows XP Professional.

  • Network Access. Because of Windows Firewall, some applications that require specific network port access may no longer function. Be sure to pinpoint these applications and test for complete functionality.

Even if a computer running Windows XP or Windows XP with Service Pack 1 operated correctly, spend time determining whether any hardware issues are likely to arise from SP2 installation. Consider these actions to minimize hardware compatibility problems even before testing in the lab.

  1. Before updating to SP2, check that the computer’s BIOS is the latest available version and that it is compatible with SP2. You can obtain an updated BIOS from the computer manufacturer. You may need to spend time before deploying SP2 making sure that all the computers in your organization are at the proper BIOS level.

  2. Use the Windows XP Professional Hardware Compatibility List (HCL), which is a list of hardware devices that have successfully passed hardware compatibility tests.

    A device that is not on the HCL might function but not be supported by Windows XP Professional. As a result, any update to the computer could cause the device to stop functioning. For devices that do not function on a computer running Windows XP Professional, contact the device manufacturer for a Windows XP Professional–compatible driver.

Lab Tests

To determine whether your applications and hardware are compatible with SP2, you must test them in a lab environment on computers that represent the hardware and software configurations in your organization. These configurations include variables such as:

  • A mix of clients, which should include varying levels of hardware and operating system revisions (for example, laptops and workstations running Windows XP with no service packs installed).

  • A mix of applications to be installed on a single computer.

The size and complexity of your test lab is determined by the complexity of the applications to be tested and by the network environment.

In addition to duplicating hardware and software configurations, you should simulate the way in which you install and use the applications in your production environment. Similarly, be aware of the function changes in SP2. Review the list of changes to functionality in the Changes to Functionality in Microsoft Windows XP Service Pack 2 white paper.

Pilot Tests

Conducting the pilot is the last major step before SP2 deployment. A pilot release is a deployment of SP2 to a subset of the live production environment or user group. The primary purposes of the pilot are to demonstrate that SP2 works in the production environment as well as it did in your lab and that it meets your organization’s business requirements.

Conducting a pilot reduces the organization’s risk of encountering problems during a full-scale deployment. You may also want to consider conducting multiple pilots consisting of separate pilots for different technologies or business groups. The pilot should run long enough that the pilot group can test SP2 in their daily activities to uncover any issues that could halt productivity—for example, several days to weeks. Figure 17 illustrates a typical pilot.

Figure 17. SP2 Pilot Workflow

Figure 17. SP2 Pilot Workflow

The pilot testers should provide feedback about how well the computer and applications are working after the installation. The release management team uses this feedback to resolve issues that arise or to create a contingency plan. Ultimately, the pilot leads to a decision to proceed with a full deployment or to slow down so you can resolve problems that could jeopardize your deployment.

For information about conducting a pilot program, see the Microsoft Solution Framework.

The most important data you receive during the pilot phase is the feedback from the pilot group. Consider distributing the questions shown in Table 4 for each member of the pilot group to answer during installation testing. Depending on the technical aptitude of the pilot testers, you may also want to include specific steps that testers should take to verify their answers. For example, in addition to asking whether SP2 installed correctly, give them a list of installation log files to check and instructions for verifying information in the Windows Event Viewer.

Table 4. SP2 Pilot Assessment

Question

Answer (Yes/No)

Did SP2 install correctly?

 

Were there any errors during installation?

 

Did the computer restart correctly after installation?

 

Were you able to log on to the computer after SP2 installation?

 

Did any error messages appear after you logged on?

 

Were you able to execute the applications you normally use after logging on?

 

Does your computer shut down correctly?

 

Does your computer restart correctly?

 

Notes:

 

Also, consider distributing a form similar to Table 5 to allow pilot testers to record information during the pilot phase.

Table 5. SP2 Pilot Diary

Date

Issues

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Rolling Out SP2

The exact steps of the deployment depend on the deployment method you have chosen. See the sections “Developing Software Update Services,” “Developing Systems Management Server,” and “Developing Group Policy” for more information about these steps. The following list describes other issues you should consider after beginning an SP2 rollout:

  • Communication. At least two days prior (or sooner, depending on your corporate communication and software distribution policy) to the date and time originally scheduled for SP2 deployment, communicate your plans to your users. In this way, users will have adequate time to prepare for the eventual deployment and installation, and business groups will have the option to delay the deployment if critical business concerns require it.

  • Deployment monitoring. This guide suggests that you put IT staff on the floor during the deployment. Although the deployment is largely an automated process, IT staff members can perform spot quality checks. (For users, it can be reassuring to have a technician close in case problems occur.)

  • Computer backup. For computers and users where business continuity is a primary concern, implement a disaster-recovery strategy, such as using disk-imaging technology to back up the computer. At the very least, consider using tools such as the User State Migration Tool (USMT) to back up users’ documents and settings.

  • SP2 removal. If you need to uninstall SP2 from a computer for troubleshooting purposes, you can use the Control Panel Add or Remove Programs item to remove the service pack and restore the computer to its previous state. If you use SMS software delivery to remove the service pack, you may not be able to visually inspect any error messages that the service pack may produce on the computer.

    Note: You can use the Add or Remove Programs item to remove the service pack only if you chose to create backup files when SP2 was installed.

For More Information