Export (0) Print
Expand All

Windows XP Service Pack 2 Enterprise Planning Guide

Published: August 18, 2004

Abstract

This guide describes planning considerations for deploying Microsoft® Windows® XP Service Pack 2 (SP2) in enterprise environments. It includes readiness assessment, application compatibility, training, and infrastructure planning. The audience for this guide is information technology (IT) architects and planners who are planning SP2 deployment. For information about using technology to implement this deployment plan, see the Windows XP Service Pack 2 Enterprise Implementation Guide.

Bb457084.3squares(en-us,TechNet.10).gif
On This Page

Overview
Roles and Responsibilities
Defining the Scope and Objectives
Assessing the Current Environment
Preventing Delivery through Windows Update
Testing Application Compatibility
Planning an SP2 Configuration
Choosing a Deployment Method
Planning the Infrastructure
Deploying to Mobile Users
Planning Communication
Training for IT Staff and Users
Designing the Deployment
For More Information

Overview

Windows XP Service Pack 2 (SP2) is a fast, free way to improve protection of your organization’s Windows XP–based computers. SP2 provides advanced security technologies and innovations from Microsoft and establishes a stronger security infrastructure that helps defend against viruses, hackers, and worms. SP2 also includes tools that enable manageability and control so that it is easier to be safe and improves overall productivity by helping users avoid time-wasting threats. For more information about the advantages of deploying SP2, see Windows XP Service Pack 2 Resources for IT Professionals.

These technologies in SP2 are not intended to replace periodic security updates as they are released, but rather, they are intended to help strengthen Windows XP's overall defenses against malicious attacks:

  • Network protection. These security technologies help to provide better protection against network-based attacks, like MSBlaster, through a number of innovations, including enhancements to Windows Firewall and a reduced Remote Procedure Call (RPC) attack surface. These enhancements include turning on Windows Firewall in default installations of SP2, closing ports except when they are in use, improving the user interface for configuration, improving application compatibility when Windows Firewall is on, and enhancing enterprise administration of Windows Firewall through Group Policy. The attack surface of the RPC service is reduced, and you can run RPC objects with reduced credentials. The DCOM infrastructure also has additional access control restrictions to reduce the risk of a successful attack.

  • Memory protection. Some malicious software attacks leverage software security vulnerabilities that allow too much data to be copied into areas of the computer’s memory. These vulnerabilities are typically referred to as buffer overruns. Although no single technique can completely eliminate this type of vulnerability, Microsoft is employing a number of security technologies to mitigate these attacks from different angles. First, core Windows components have been recompiled with the most recent version of Microsoft’s compiler technology, which provides added protection against buffer overruns. Additionally, Microsoft is working with microprocessor companies to help Windows support hardware-enforced data execution prevention (DEP) on microprocessors that contain the feature. Data execution prevention uses the CPU to mark all memory locations in an application as non-executable, unless the location explicitly contains executable code. This way, when an attacking worm or virus inserts program code into a portion of memory marked for data only, an application or Windows component will not run it.

  • E-mail handling. Security technologies help to stop viruses (such as SoBig.F) that spread through e-mail and instant messaging. These technologies include default settings that have enhanced security and improved attachment control using the Attachment Execution Service (AES) API. This results in security and reliability enhancements for communications applications such as Microsoft® Office® Outlook, Office®Outlook Express, and Windows® Messenger. As a result, potentially unsafe attachments that are sent through e-mail and instant messages are isolated so that they are less likely to affect other parts of the system.

  • Browsing security. Security technologies that are delivered in Microsoft ® Internet Explorer provide improved protection against malicious content on the Web. One enhancement includes locking down the Local Machine zone to help prevent the running of malicious scripts and fortifying against harmful Web downloads. Additionally, better user controls and user interfaces are provided that help prevent malicious ActiveX® controls and spyware from running on customers’ systems without their knowledge and consent.

  • Computer maintenance. A very important part of any security plan is keeping computers updated with the latest software and security updates and understanding the role they play in protecting your computer. Ensuring that you have current knowledge of security attacks and trends is also important. For example, some software updates that mitigated known viruses and worms were available days or weeks before any significant attacks began. New technologies are being added to help the end user stay up-to-date. These technologies include Security Center, which provides a central location for information about the security of your computer, and Windows Installer, which provides more security options for software installation.

Microsoft understands that security technologies are only one aspect of a sound defense-in-depth security strategy. The security technologies outlined here are the next steps being taken in the Trustworthy Computing initiative to make customers’ systems more resilient to malicious attacks.

Deploying an operating-system update such as SP2 to the thousands of computers typical of a large enterprise is a tremendous undertaking. To reduce the cost and complexity of this type of project, you must thoroughly plan the deployment, anticipate the risks, and execute the plan while addressing those risks. This guide will help you plan your SP2 deployment. The Windows XP Service Pack 2 Enterprise Implementation Guide explains how you can use Microsoft® Software Update Services (SUS), Systems Management Server (SMS), and Group Policy to execute your deployment.

Note:  Before planning and executing an SP2 deployment, all team members should read Guide for Installing and Deploying Microsoft® Windows® XP Service Pack 2. It provides background and technical details about SP2.

Note:  The Microsoft® Solutions Framework (MSF) provides a flexible and scalable framework that can be adapted to meet the needs of any project (regardless of size or complexity) to plan, build, and deploy business-driven technology solutions. The framework is well suited to deploying SP2 in large enterprises, particularly complicated SP2 deployment projects. Consider using MSF to guide your team development, process models, risk management, and so on. For more information about MSF, see Microsoft Solution Framework.

Roles and Responsibilities

An enterprise deployment of SP2 begins with team formation. At a minimum, construct the following teams to participate in SP2 deployment:

  • Planning Team. The planning team, which consists of project stakeholders, IT architects, and other technical decision makers, uses the advice contained in this guide to create an SP2 deployment plan. This team defines the scope of the project, tests application compatibility, chooses a distribution method, and plans the infrastructure. The team can use the Windows XP Service Pack 2 Enterprise Planning Template, included with this guide, as a template for creating a deployment plan.

  • Implementation Team. After creating, reviewing, and accepting the plan, the planning team hands the project off to the implementation team. The implementation team, which consists of IT implementers (including network engineers and desktop engineers), uses the guidance in the deployment plan and in the Windows XP Service Pack 2 Enterprise Implementation Guide to design, test, and implement the SP2 deployment project.

Complicated and significantly large SP2 deployment projects should consider adopting the Microsoft Solution Framework’s Team Model. The MSF Team Model describes Microsoft’s approach to structuring people and their activities to enable project success. The model defines roles, functional areas, responsibilities, and guidance that helps team members reach their unique goals in the project lifecycle.

Defining the Scope and Objectives

As the first step in deployment planning, define the scope and objectives for your SP2 deployment. This portion of the deployment plan should include at least the following information:

  • Goals. Identify the problem you are trying to solve and the goals you are trying to achieve by deploying SP2—that is, create a problem-solution statement. The problem might be the IT department’s ability to keep up with Microsoft security patches, and the goal might be to proactively protect computers against attack until IT can deploy the latest security patches.

  • Vision Statement. Describe the long-term vision for how this project will address the problems and goals described in the goals statement. For example: IT will deploy SP2 to every desktop in the organization over a three-month period by using its existing SMS infrastructure.

  • Scope Definition. Describe the time, resources, budget, and other limitations to deployment.

  • Risk Assessment. Describe the anticipated risks and the steps necessary to mitigate these risks. Risk assessment is an ongoing, iterative process that continues throughout the project’s lifetime.

Assessing the Current Environment

Before you can begin planning for SP2 deployment, you need to assess your organization’s current IT environment. For example, before you deploy SP2, you might need to upgrade the hardware-related and operating system–related software used in your organization. Therefore, it is essential that you conduct comprehensive hardware and software inventories of all computers on your network running Windows XP before you begin planning your deployment.

Choosing an Inventory Method

Use an automated method to conduct the hardware and software inventory of your Windows XP computers. (A manual method is not recommended.) Microsoft provides two automated methods for conducting an inventory:

  • Systems Management Server. You can use SMS to conduct an inventory of the hardware and software on your network.

  • Windows Scripts and Windows Management Instrumentation. You can also use Windows Management Instrumentation (WMI) to write scripts in the VBScript or JScript scripting languages that obtain hardware and software inventory from Windows XP computers. WMI is the management infrastructure in Windows that supports monitoring and controlling system resources through a common set of interfaces and provides a logically organized, consistent model of Windows operation, configuration, and status. For more information about scripting, see the MSDN Scripting Clinic.

Table 1 compares these two methods.

Table 1. Comparison of Inventory Methods

Method

Advantages

Disadvantages

Microsoft Systems Management Server

SMS requires no programming.

SMS must be deployed in your organization.

Windows Scripts and Windows Management Instrumentation

Scripts can be customized to detect extra inventory information that SMS cannot collect.

Script development and ongoing maintenance are required.

Note:  In addition to these two Microsoft solutions, there are several non-Microsoft applications that you can use to inventory the hardware and software in your organization. Some of these applications even report their inventory through SMS.

You can also use Windows Scripts and WMI with SMS to extend the inventory capabilities of SMS. Develop your scripts to collect customized inventory information, then report the collected, customized inventory information through SMS. For more information about writing scripts that can report information through SMS, see Extending Hardware Inventory.

Conducting a Hardware Inventory

Document the hardware inventory information for each computer in your organization running Windows XP. Table 2 lists the hardware inventory information you need to collect and how that information will assist in your SP2 deployment.

Table 2. Hardware Inventory and Deployment Planning

This Information

Helps You Determine

Location of the computer

The number of target computers in a geographic location on which SP2 should be deployed. This information helps you scale your deployment infrastructure (for example, the number of SMS servers required in a location) to support SP2 deployment.

Manufacturer and model number of the computer

How many of the same type of computer exists within each location. This information helps you determine the number of Remote Installation Services (RIS) images required (if you are performing a clean installation).

Number of processors each computer has and the speed of each processor

The Hardware Abstraction Layer (HAL) version in use (single processor versus multiprocessor). This information helps you determine the number of RIS images required (if you are performing a clean installation).

Amount of RAM

Whether the RAM is sufficient to support SP2.

Available disk space

Whether the available disk space will allow a backup of the existing files prior to SP2 installation.

BIOS versions

Any potential BIOS upgrades required prior to SP2 deployment.

Configurations for peripherals

Any potential configuration settings that may need to be adjusted prior to SP2 deployment.

Device drivers

Device drivers that might be incompatible with SP2. This information also helps you discover any devices (such as disk controllers) that will affect the number of RIS images required (if you are performing a clean installation).

Conducting a Software Inventory

Conduct a complete inventory of the applications that are used in your organization, including all custom (in-house) applications. Document the software inventory information for each computer in your organization running Windows XP. Table 3 lists the software inventory information you need to collect and how that information will assist in your SP2 deployment.

Table 3. Software Inventory and Deployment Planning

This Information

Helps You Determine

Applications that are installed

Applications that are incompatible will need to be reinstalled, or will need to be upgraded after SP2 deployment.

Version of dynamic-link libraries (DLLs) associated with each application

DLLs that are incompatible will need to be reinstalled or upgraded after SP2 deployment.

Operating system service packs and updates

Any configuration settings that might need to be reapplied after SP2 deployment.

Reviewing Inventory Information

When you have a complete list of the hardware and software used in your organization, compare the data you collected with the minimum hardware requirements for Windows XP. For a list of these requirements, see Assessing Your Current Configuration.

Computers running Windows XP should already meet of the minimum hardware requirements for SP2. However, based on the service pack options that you select, you might need to upgrade certain hardware resources. Table 4 lists the hardware resources and reasons why you might need to upgrade them.

Table 4. Upgrading Hardware Resources

Resource

Changes to Minimum Requirements

Memory

The minimum hardware requirement for Windows XP with no service packs installed is 64 MB, while Windows XP with SP2 requires 128 MB.

Available disk space

The minimum hardware requirement for Windows XP with no service packs installed is 650 MB, while Windows XP with SP2 requires 800 MB.

Preventing Delivery through Windows Update

While recognizing the security benefits of Windows XP SP2, some organizations have requested the ability to temporarily disable delivery of this update via Automatic Updates and Microsoft® Windows® Update. These organizations have populations of PCs, upon which they have enabled Automatic Updates to ensure that these PCs receive all critical security updates. This guidance does not apply enterprises with existing SMS or SUS infrastructures that do not update desktop computers by using Automatic Updates and Windows Update.

Since SP2 will start to be delivered to PCs running Windows XP or Windows XP with Service Pack 1 via Automatic Updates starting on August 16, 2004, these customers would like to temporarily block the delivery of SP2 in order to provide additional time for validation and testing of the update. In response to these requests, Microsoft is providing the Toolkit to Temporarily Block Delivery of Windows XP SP2 to a PC Through Automatic Updates and Windows Update. For more information about using this toolkit, see Temporarily Disabling Delivery of Windows XP Service Pack 2 Through Windows Update and Automatic Updates.

Note:  The mechanism to temporarily disable delivery of SP2 will be available for a period of 120 days (4 months) from August 16, 2004. At the end of this period, SP2 will be delivered to all Windows XP and Windows XP SP1 systems.

Testing Application Compatibility

A key factor in the success of an SP2 deployment is thorough testing in a test environment that simulates as closely as possible your production environment. A test environment consists of a lab or labs and includes plans that detail what you will test and cases describing how you will test each component.

The test lab can consist of one or many labs, each of which supports testing without risk to your production environment. In the test lab, members of the deployment team can verify their deployment design assumptions, discover deployment problems, and improve their understanding of SP2. Such activities reduce the risk of errors during deployment and minimize downtime in your production environment.

Building a Test Lab

A well-designed test lab provides a controlled environment for the full range of testing required throughout the project life cycle—from experimenting with the technology through fine-tuning the rollout process. Figure 1 shows some of the tasks that can be performed in the test lab and indicates the MSF phases during which each of these activities might occur. (The time frames are estimations and might vary from deployment to deployment.)

Figure 1. Role of the Test Lab in the Project Life Cycle

Figure 1. Role of the Test Lab in the Project Life Cycle

Note:  For more information about creating a test lab, see Planning the Test Lab, Designing the Test Lab, and Developing the Test Lab.

Writing Test Cases

When documenting test cases, organizations take a variety of approaches ranging from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.

Create detailed test cases whenever possible, because determining pass or fail criteria is usually easier with this type of case. In addition, detailed test cases are reproducible and are easier to automate than descriptive test cases—a particularly important element if you plan to compare the results of tests over time, such as when you are optimizing configurations. Detailed test cases are more time-consuming to develop and maintain, but test cases that are open to interpretation are not repeatable and can require debugging.

Test cases should be written by a team member who understands the function or technology being tested. Each test case should be submitted for peer review and revised accordingly. A test case includes:

  • The purpose of the test.

  • Special hardware requirements, such as a modem.

  • Special software requirements, such as a specific application.

  • Specific setup or configuration requirements.

  • A description of how to perform the test.

  • The expected results or success criteria for the test.

Table 5 provides an example of the first four steps of a detailed test case.

Table 5. Sample Detailed Test Case

Step

Procedure

Success Criteria

Outcome

1

Log off the client computer and return to the logon screen.

None

 

2

Click the domain list to open it.

The local server name does not appear in the list.

 

3

Click the domain list to open it.

The appropriate domain appears in the list.

 

4

Log on to the client computer by using an account designated for access to the client computer.

The account logs on to the client computer without errors.

 

When planning your tests, remember that it is not feasible to test everything. Instead of trying to test every combination, prioritize your testing so that you perform the most important tests—those that focus on areas that present the greatest risk or have the greatest probability of occurring—first. For example, you might choose to test the slowest client computer, the busiest server, or the least-reliable network link. Then, if time allows, you can perform lower-priority tests.

Develop test cases for commercial applications and custom applications. Custom applications require more extensive testing than commercial applications, because they are typically not tested as thoroughly as commercial applications prior to release.

Note:  For more information about developing test cases for commercial applications, see Testing Commercial Applications. For more information about developing test cases for custom applications, see Testing Custom Applications. For more information about writing test plans, see Creating an Application Compatibility Test Plan.

Conducting Tests

When conducting tests, you must perform each test as described in the test case. Then, you must evaluate the test results and escalate problems that arise until they are resolved. Finally, you need to document the test results. Figure 2 illustrates the process for conducting test cases and resolving any issues that arise during the testing process.

Figure 2. Process for Conducting Test Cases and Resolving Issues

Figure 2. Process for Conducting Test Cases and Resolving Issues

Note:  Before testing begins, you might need to modify the test lab setup to meet the requirements specified in the test case.

When conducting a test, you need to follow the written test cases carefully. To accurately assess results or to reproduce a test to compare results over time, team members need to know exactly which steps you took and the exact sequence in which you performed those steps.

Identifying Problems with Test Cases

When a test is complete, you must evaluate the results against the criteria in the test case to determine whether the test passed or failed. Not all tests fail because there is a problem with your system implementation; tests can fail because there is a problem with the test itself, with the test lab setup, or with the proposed design. If one of these problems causes a test to fail, take the appropriate measures to remedy it. Table 6 shows some typical test problems and their solutions.

Table 6. Test Problems and Solutions

Problem

Solution

Test case problem

Revise the test case, taking care to document all the changes made, then rerun the test.

Test lab setup problem

Following the change-control process for the lab, reconfigure the lab, and then rerun the test.

Design problem

Follow the escalation procedure to notify the appropriate individuals about the problem. Prioritize outstanding problems, and track them until they are resolved and the corresponding tests have been rerun. To prioritize problems, consider the potential impact and the probability that they will occur.

As a best practice, record all test results in a tracking system so that you can monitor test progress.

Note:  Remember that the lab will change frequently as tests are run and new tests begun. Make backups of baseline configurations so that testers can quickly restore a computer to its prior state. Similarly, be sure to test the restoration process. Document the backup files and store them in a safe, accessible place.

Resolving Application-Compatibility Issues

If application testing reveals possible compatibility issues between an application and Windows XP, a resolution must be found to enable the application to run as expected. You can resolve application-compatibility issues by taking one or more of the following steps:

  1. Attempt to resolve the compatibility issues by using the Compatibility Administrator tool.

    Windows XP includes a robust series of application-compatibility technologies. These technologies are available to users through the Windows XP shell. Deploying application-compatibility updates to many computers can be difficult or impossible if left to each user. The Compatibility Administrator tool allows you to deploy application-compatibility updates to your organization. For more information, see Resolving Application Compatibility Issues with Compatibility Administrator.

  2. Resolve compatibility issues by selecting one of the strategies from Identifying Strategies for Resolving Special Problems.

    Identifying Strategies for Resolving Special Problems lists several methods for resolving application-compatibility issues (such as reinstalling the application by using an Administrator account or verifying the Microsoft Data Access Components (MDAC) and DirectX versions). By following one or more of these strategies, your application-compatibility issues might be resolved.

  3. If you are unable to resolve the compatibility issues by using the Compatibility Administrator tool, report the issues to the developers. (For custom applications, report the issues to your developers. For commercial applications, determine whether the software company has an updated version that Windows XP SP2 supports.

Planning an SP2 Configuration

Designing a configuration for SP2 is the implementation team’s responsibility. However, the planning team must specify requirements for the configuration of SP2. These requirements will be largely based on the results of application testing and the organization’s security policies. In the deployment plan, specify these requirements. The following are specific considerations when planning an SP2 configuration:

  • Plan the configuration of Windows Firewall. For Windows Firewall to work in your environment, you will need to customize it. See Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2 to better understand the options available for customizing Windows Firewall features.

  • Determine whether to enable SP2 features during deployment or in phases. In the first scenario, you deploy SP2 with all or most of its features fully enabled. If application testing has discovered no blocking issues, then this is the best choice because it allows the organization to take advantage of advanced security features in SP2 immediately.

    An alternative approach is to enable SP2 features in phases. This scenario is beneficial when the organization wants to take advantage of SP2 immediately but testing has revealed blocking issues. IT can disable the features that are blocking the deployment, deploy SP2 immediately, and then enable the disabled features in phases as resolutions are developed. For example, if testing revealed that Windows Firewall prevented applications from working properly, you can disable the firewall during the initial deployment and then enable Windows Firewall after developing solutions to the compatibility issues. The primary mechanism for disabling SP2 features is Group Policy. See “Group Policy Settings Reference for Windows XP Professional Service Pack 2” for a list of policies that SP2 introduces. In particular, the last worksheet in the workbook contains a list of new policies for SP2.

Choosing a Deployment Method

There are two installation options for SP2. You can either perform a standalone installation of SP2 on computers already running Windows XP, which updates the computer, or you can perform an integrated installation of Windows XP with SP2 for new installations of the operating system.

This guide describes three methods for deploying standalone installations of SP2 without requiring user interaction and in which users maintain their existing configurations. For environments in which computers are largely unmanaged or have already received numerous upgrades, a standalone installation might not be the best choice. Updating existing configurations with SP2 brings forward all the existing problems, known and unknown, contained in the previous configuration. The result is a more complicated, error-prone deployment process that is more expensive to manage and support after deployment. Deploying SP2 by using an integrated installation to create clean installations of the operating system might be the perfect opportunity to gain control of the enterprise’s computers, thereby reducing costs and complexity.

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

The next step in planning your SP2 deployment is to choose the deployment method that you will use. The recommended methods of deploying the service pack include:

  • Software Update Services (SUS). SUS is a version of Windows Update designed for organizations that want to approve each software update before installing it. SUS allows administrators to quickly and easily deploy Windows-related security updates as well as critical updates to any computer running Windows Server 2003, Windows XP Professional, or Microsoft® Windows 2000.

  • Systems Management Server. SMS 2003 provides a comprehensive solution for change and configuration management for the Microsoft platform, enabling organizations to provide relevant software and updates to users quickly and cost-effectively.

  • Group Policy. Group Policy and the Microsoft® Active Directory® directory service infrastructure in Windows Server 2003 enable administrators to automate one-to-many management of users and computers, thereby simplifying administrative tasks and reducing IT costs.

Each of these methods requires that the infrastructure for that method already be in place. For example, to use SMS, SMS must already be deployed in your organization. As a result, the deployment method that you choose will be determined in large part on the infrastructure in place in your organization. However, if more than one of these infrastructures exists in your organization, you need to be aware of the advantages and disadvantages of each deployment method.

Software Update Services

Use SUS to deploy SP2 when:

  • Your organization already has an SUS infrastructure.

  • The SUS servers in your organization have the available storage to support SP2.

  • An application other than SMS performs hardware and software inventory.

Use one of the other methods to deploy SP2 when:

  • The solution needs to include hardware and software inventory capabilities.

  • The solution needs to support the deployment of application software and application software updates.

  • You want to perform the deployment by using existing Active Directory domain controllers and file servers without purchasing additional hardware and software licenses.

  • You need to support a large percentage of mobile users.

Table 7 lists the advantages and disadvantages of using SUS to deploy SP2.

Table 7. SUS Advantages and Disadvantages

Advantages

Disadvantages

SUS supports phased deployment of SP2 because deployment can be approved on each SUS server.

An SUS infrastructure must already exist.

No additional software is required on the client computers because the Automatic Update component in Windows XP can be used.

SUS requires additional software such as SMS to perform hardware or software inventory.

Software updates can be copied from an SUS server onto a CD-ROM, then to an SUS server in a protected network that has no high-speed network access.

If a download to a client fails, the process must be restarted from the beginning.

SUS can be used to deploy other types of updates that are normally obtained through Windows Update.

SUS requires additional software such as SMS to deploy applications and application updates.

Clients can be centrally configured by using Group Policy settings or administrative scripts that set the appropriate registry setting values.

SUS has limited support for mobile users.

Systems Management Server

Use SMS to deploy SP2 when:

  • Your organization already has an SMS infrastructure.

  • The SMS servers in your organization have the available storage to support SP2.

  • You need to perform hardware and software inventory.

  • A significant percentage of your users are mobile or remote users.

Use one of the other methods to deploy SP2 when:

  • You want the solution to use an application other than SMS to perform hardware and software inventory.

  • The solution needs to support only SP2 deployment.

  • You want to perform the deployment by using existing Active Directory domain controllers and file servers without purchasing additional hardware and software licenses.

Table 8 lists the advantages and disadvantages of using SMS to deploy SP2.

Table 8. SMS Advantages and Disadvantages

Advantages

Disadvantages

SMS supports phased deployment of SP2 because deployment can be performed on machine groups.

An SMS infrastructure must already exist.

SMS can perform hardware or software inventory in addition to deploying the service pack.

The SMS client must be installed on all computers running Windows XP.

SMS provides enhanced support for mobile users.

SMS infrastructure is more extensive and pervasive than other methods.

SMS can be used to deploy applications and application updates.

 

Clients can be centrally configured by using SMS management consoles.

 

Group Policy

Use Group Policy to deploy SP2 when:

  • Your organization already has an Active Directory infrastructure.

  • The file servers in your organization have the available storage to support SP2.

  • You want to use applications other than SMS to perform hardware and software inventory.

  • You want to perform the deployment by using existing Active Directory domain controllers and file servers without purchasing additional hardware and software licenses.

Use one of the other methods to deploy SP2 when:

  • You want to use SMS to perform the hardware and software inventory.

  • The solution needs to support only SP2 deployment.

  • A significant percentage of your users are mobile or remote users.

Table 9 lists the advantages and disadvantages of using Group Policy to deploy SP2.

Table 9. Group Policy Advantages and Disadvantages

Advantages

Disadvantages

Group Policy supports phased deployment of SP2 because deployment can be performed on computers within Active Directory organizational units (OUs).

An Active Directory infrastructure must already exist.

In most instances, the Active Directory infrastructure already exists in the organization.

Group Policy has no specific support for mobile users.

Group Policy can be used to deploy applications and application updates.

Group Policy requires additional software such as SMS to perform hardware or software inventory.

Clients can be centrally configured by using the Group Policy Management Console.

 

Planning the Infrastructure

The logical and physical network infrastructure in your organization must be able to support SP2 deployment. During the deployment, you must determine any resource upgrades required to your infrastructure (such as increasing available network bandwidth, upgrading routers, or increasing available disk space on servers).

In distributed environments, you must ensure that either your organization’s infrastructure can support the transfer of the service pack between locations or that you have offline methods for distributing the service pack to branch offices. As the last step in planning your infrastructure, you must ensure that day-to-day business operations are not affected.

Planning Network Requirements

SP2 deployment requires a significant amount of available network bandwidth and free disk space. In most instances, increasing the available disk space on the servers used to deploy the service pack is relatively easy and inexpensive. However, increasing the available network bandwidth can be complicated and expensive.

Typically, available network bandwidth is not an issue within the local intranet at each organization location. The wide area network (WAN) connections between locations are typically the bottle neck because they are sometimes from 1/100 to 1/10 of the data rate of a local area network (LAN) connection.

In addition to the data rate, the signal transmission latency between locations may be a deciding factor. For example, a WAN connection between North America and Australia can experience a 6-millisecond (ms) delay. If the locations are connected through a virtual private network (VPN), the latency delay can be significant. For example, a VPN that uses Point-to-Point Tunneling Protocol (PPTP) between North American and Australia can experience up to a 12 ms delay for each packet sent, because PPTP is based on the Transmission Control Protocol (TCP) and acknowledgement must be received for each packet sent. So, there is a 6 ms delay sending the packet and a 6 ms delay in receiving the acknowledgement (12 ms total). SP2 deployment can affect WAN connections in the following ways:

  • The distribution of the service pack image to the servers on which the image is stored. In most instances, you will transfer the service pack image across a WAN connection once. To avoid affecting other business functions, you can also transfer the service pack image during non-peak periods of network activity.

  • The deployment of the service pack to the client computers from the servers on which the image is stored. You must download the service pack to each client computer. As the number of simultaneous deployments increases, the load placed on the WAN connection also increases. Avoid downloading the service pack over a WAN connection unless the length of time required to deploy the service pack over a high-speed WAN connection is acceptable.

Network Bandwidth

The first step in planning your network requirements is to evaluate the ability of your existing network to support SP2 deployment. The primary concern is the WAN connections in your organization.

Table 10 lists the common WAN connection types, the corresponding data rates, and the length of time to transfer the service pack for that connection type. Even with high-speed WAN connections, the length of time to transfer the service pack can be significant.

Table 10. Common WAN Types, Data Rates, and Transfer Time

Connection Type

Data Rate

Transfer Time

T1

1.54 Mbps

24 minutes

Digital Subscriber Line (DSL), Cable modem, or Integrated Services Digital Network (ISDN)

128 Kbps

4 hours, 40 minutes

Dial-up modem

56 Kbps

11 hours, 30 minutes

The times listed in Table 10 assume that you have 100% of the available bandwidth of the WAN connection. If the WAN connection is supporting other traffic, which is very likely, the length of time required to transfer the service pack in your environment will increase accordingly.

For distributing the service pack image to servers in each remote location, high-speed WAN connections are sufficient. However, for downloading the service pack to multiple client computers simultaneously, even high-speed WAN connections are probably insufficient.

If your connection type does not appear in Table 10, you can estimate the length of time to transfer the service pack by performing the following calculation:

  1. Multiply the size of the service pack (264 MB) by 8 to determine the size in bits (2112 megabits).

  2. Divide the size of the service pack in megabits (2112 megabits) by the data rate of the WAN connection.

  3. Divide the result in step 2 by 60 to convert the time from seconds to minutes.

For example, assume you have a frame relay connection with a data transfer rate of 3.2 megabits per second (Mbps). The length of time to transfer the service pack over the frame relay connection is 11 minutes (2112 megabits ÷ 3.2 megabits ÷ 60).

WAN Connections

In some instances, your branch offices may be small enough that the local infrastructure is minimal. In such cases, there may not be local servers on which the service pack image is stored. In addition, these branch offices typically have no local IT staff, which means that the SP2 deployment must be fully automated and error free.

If the number of simultaneous client deployments is small enough, you can deploy the service pack over WAN connections. To determine the length of time to deploy the service pack on multiple computers simultaneously, multiply the times listed in Table 10 by the number of computers. For example, if you want to download the service pack to three computers simultaneously over a T1 WAN connection, the length of time is approximately 72 minutes (24 minutes × 3).

Depending on the size of the branch office, you may want to treat the users in the branch office as mobile users. For more information about how to deploy SP2 to mobile users, see the section “Deploying to Mobile Users” later in this guide.

Planning Distributed Environments

Many enterprise organizations have numerous branch offices and have unique requirements when deploying SP2. Some branch offices can be connected to the organization’s intranet by slow network connections or by network connections that experience frequent outages. In addition, the sheer number of branch offices can create logistics problems during the deployment process.

Based on the deployment method you select, three methods exist for addressing the challenges of these distributed environments: SUS, SMS, and Group Policy. Figure 3 illustrates an organization that has a central office connected to regional offices. The regional offices are in turn connected to branch offices.

Figure 3. Organization with a Distributed Environment

Figure 3. Organization with a Distributed Environment
SUS in Distributed Environments

When you use SUS to deploy SP2 in distributed environments, you must determine the placement of SUS servers in geographic locations. You must ensure that:

  • Client computers have consistent, high-speed connections to an SUS server.

  • The service pack image can be distributed to all SUS servers.

Network Connectivity

Because of the size of SP2, your must provide high-speed connectivity between the client computers and the corresponding SUS servers. In branch offices, client computers must connect either to a local SUS server or to an SUS server in another location. (Place an SUS server in the branch office when the network connection to that branch office is insufficient to support SP2 deployment. Otherwise, clients can connect to SUS servers in another location.)

To use an SUS server in another location, you need a network connection that can support many users installing the service pack simultaneously in a reasonable time. For more information about the network requirements, see “Planning Network Requirements” earlier in this guide.

Figure 4 illustrates a fictitious organization that is using SUS to deploy SP2. Table 11 lists each location and the decisions that were made in placing the SUS servers. The organization has decided that no more than 10 percent of the clients within a location will deploy SP2 simultaneously.

Figure 4. Fictitious Organization’s SUS Infrastructure

Figure 4. Fictitious Organization’s SUS Infrastructure

Table 11. Placement of SUS Servers in the Fictitious Organization

Location

Reason for Placement

Central office

SUSSRV-A is required to support the clients in this location. SUSSRV-B is required to provide scaling during peak times and redundancy in the event that SUSSRV-A fails.

Regional Office A

SUSSRV-C is required to support the local clients. There are too many clients for another location to support.

Regional Office B

SUSSRV-D is required to support the local clients. There are too many clients for another location to support.

Branch Office A

SUSSRV-E is required to support the local clients. The network connection between Branch Office A and Regional Office A is too slow to support SP2 deployment from SUSSRV-C.

Branch Office B

SUSSRV-F is required to support the local clients. The network connection between Branch Office B and Regional Office A is too slow to support SP2 deployment from SUSSRV-C.

Branch Office C

No SUS server is required, because SUSSRV-D in Regional Office B can support the clients.

Branch Office D

No SUS server is required, because SUSSRV-D in Regional Office B can support the clients.

Distributing to SUS Servers

Because of the size of SP2, your must have high-speed connectivity to each SUS server or use an offline method for distributing the service pack image to the SUS servers. The most common offline method is to copy the service pack image to a CD-ROM, DVD-ROM, or other removable medium, ship the medium to the desired location, and then upload the image onto the SUS server.

To distribute the service pack image to an SUS server in another location, you need a network connection that can support transferring the image in a reasonable time. For more information about the network requirements, see “Planning Network Requirements” earlier in this guide.

Note:  Distribute the service pack images during non-peak periods of network activity.

Our fictitious organization made the following decisions about distributing SP2 to the SUS servers:

  • Transfer the service pack over the network to SUSSRV-A, SUSSRV-B, SUSSRV-C, and SUSSRV-D, because the network infrastructure supports the image transfer.

  • Use an offline process to transfer the service pack to SUSSRV-E and SUSSRV-F, because the network infrastructure is unable to support the image transfer.

SMS in Distributed Environments

When you use SMS to deploy SP2 in distributed environments, you must determine the placement of SMS distribution points in geographic locations. You must ensure that:

  • Client computers have consistent, high-speed connections to an SMS distribution point.

  • The service pack image can be distributed to all SMS distribution points.

Network Connectivity

Because of the size of SP2, you must provide high-speed connectivity between the client computers and the corresponding SMS distribution points. In branch offices, client computers must connect to a local distribution point or to a distribution point in another location. (Place a distribution point in the branch office when the network connection to the branch office is insufficient to support deploying the service pack from a distribution point in another location. Otherwise, clients can connect to distribution points in another location.)

To use a distribution point in another location, you need a network connection that can support many users installing the service pack simultaneously in a reasonable time. For more information about the network requirements, see “Planning Network Requirements” earlier in this guide.

Figure 5 illustrates a fictitious organization that is using SMS to deploy SP2. Table 12 lists each location and the decisions that were made in placing the distribution points. The organization has decided that no more than 10 percent of the clients within a location will deploy SP2 simultaneously.

Figure 5. Fictitious Organization’s SMS Distribution Point Placement

Figure 5. Fictitious Organization’s SMS Distribution Point Placement

Table 12. Placement of SMS Distribution Points in the Fictitious Organization

Location

Reason for Placement

Central office

SMSDISTP-A is required to support the clients in this location. SMSDISTP-B is required to provide scaling during peak times and redundancy in the event that SMSDISTP-A fails.

Regional Office A

SMSDISTP-C is required to support the local clients. There are too many clients for another location to support.

Regional Office B

SMSDISTP-D is required to support the local clients. There are too many clients for another location to support.

Branch Office A

SMSDISTP-E is required to support the local clients. The network connection between Branch Office A and Regional Office A is too slow to support SP2 deployment from SMSDISTP-C.

Branch Office B

SMSDISTP-F is required to support the local clients. The network connection between Branch Office B and Regional Office A is too slow to support SP2 deployment from SMSDISTP-C.

Branch Office C

No distribution point is required, because SMSDISTP-D in Regional Office B can support the clients.

Branch Office D

No distribution point is required, because SMSDISTP-D in Regional Office B can support the clients.

Distributing the Service Pack

Because of the size of SP2, you must have high-speed connectivity to each distribution point or use an offline method for distributing the service pack image to the distribution points. The most common offline method is to copy the service pack image to a CD-ROM, DVD-ROM, or other removable medium, ship the medium to the desired location, and then upload the image onto the distribution point. Then, create a package that distributes the service pack within the location (SMS site).

To distribute the service pack image to a distribution point in another location, you need a network connection that can support transferring the image in a reasonable time. For more information about the network requirements, see “Planning Network Requirements” earlier in this guide.

Note:  Distribute the service pack images during non-peak periods of network activity.

Our fictitious organization made the following decisions about distributing SP2 to the SMS distribution points:

  • Transfer the service pack over the network to SMSDISTP-A, SMSDISTP-B, SMSDISTP-C, and SMSDISTP-D, because the network infrastructure supports the image transfer.

  • Use an offline process to transfer the service pack to SMSDISTP-E and SMSDISTP-F, because the network infrastructure is unable to support the image transfer.

Distributing the Service Pack with the SMS Fan-Out Feature

You can also reduce the workload on the initiating site by using the fan-out feature in SMS. The fan-out feature allows sites to distribute package content to lower-level sites through child sites rather than directly. Fan-out distribution occurs automatically if the initiating site does not have an SMS address for the destination site. For example, if a site needs to distribute a package to its child and grandchild sites, there are two options for the originating site:

  • If the initiating site has addresses to both sites, distribute the package to the child site and to the grandchild site.

  • If the initiating site has the address of the child site and only the child site has the address of the grandchild site, use the fan-out feature and distribute the package only to the child site. The child site then distributes the package to its child site, which is the grandchild of the originating site.

Besides reducing the workload of the initiating site, the fan-out feature reduces the load on the network link between the initiating site and the other sites, which is often a significant issue. This feature is especially efficient when distributing large software packages, such as SP2. Figure 6 illustrates the added load on the central site when the fan-out feature is not used.

Figure 6. Software Distribution with and Without the SMS Fan-Out Feature

Figure 6. Software Distribution with and Without the SMS Fan-Out Feature
Group Policy in Distributed Environments

When you use Group Policy to deploy SP2 in distributed environments, you must determine the placement of file servers in geographic locations. Group Policy uses shared folders on a file server as the storage medium for the service pack. You must ensure that:

  • Client computers have consistent, high-speed connections to a file server share.

  • The service pack image can be distributed to all file servers used in the Group Policy deployment.

Network Connectivity

Because of the size of SP2, your must provide high-speed connectivity between the client computers and the corresponding shared folders on the file server referenced in Group Policy. In branch offices, client computers must connect to a local shared folder or to a shared folder in another location. (Place a file server in the branch office when the network connection to the branch office is insufficient to support SP2 deployment from a file server in another location. Otherwise, clients can connect to the file server in another location.)

To use a shared folder on a file server in another location, you need a network connection that can support many users installing SP2 simultaneously in a reasonable time. For more information about the network requirements, see “Planning Network Requirements” earlier in this guide.

Figure 7 illustrates a fictitious organization that is using Group Policy to deploy SP2. Table 13 lists each location and the decisions that were made in placing the file servers. The organization has decided that no more than 10 percent of the clients within a location will deploy SP2 simultaneously.

Figure 7. Fictitious Organization’s File Server Placement for Group Policy Deployments

Figure 7. Fictitious Organization’s File Server Placement for Group Policy Deployments

Table 13. Placement of File Servers in the Fictitious Organization

Location

Reason for Placement

Central office

FILESRV-A is required to support the clients in this location. FILESRV-B is required to provide scaling during peak times and redundancy in the event that FILESRV-A fails.

Regional Office A

FILESRV-C is required to support the local clients. There are too many clients for another location to support.

Regional Office B

FILESRV-D is required to support the local clients. There are too many clients for another location to support.

Branch Office A

FILESRV-E is required to support the local clients. The network connection between Branch Office A and Regional Office A is too slow to support SP2 deployment from FILESRV-C.

Branch Office B

FILESRV-F is required to support the local clients. The network connection between Branch Office B and Regional Office A is too slow to support SP2 deployment from FILESRV-C.

Branch Office C

No distribution point is required, because FILESRV-D in Regional Office B can support the clients.

Branch Office D

No distribution point is required, because FILESRV-D in Regional Office B can support the clients.

Distributing to File Servers

Because of the size of SP2, you must have high-speed connectivity to each file server or use an offline method for distributing the service pack image to the file servers. The most common offline method is to copy the service pack image to a CD-ROM, DVD-ROM, or other removable medium, ship the medium to the desired location, and then upload the image onto the file server.

To distribute the service pack image to a file server in another location, you need a network connection that can support transferring the image in a reasonable time. For more information about the network requirements, see “Planning Network Requirements” earlier in this guide.

Note:  Distribute the service pack images during non-peak periods of network activity.

Our fictitious organization made the following decisions about distributing SP2 to the file servers:

  • Transfer the service pack over the network to FILESRV-A, FILESRV-B, FILESRV-C, and FILESRV-D, because the network infrastructure supports the image transfer.

  • Use an offline process to transfer the service pack to FILESRV-E and FILESRV-F, because the network infrastructure is unable to support the image transfer.

Maintaining Business Continuity

One of the primary design goals in planning a deployment is to minimize the disruption of normal business operations during the deployment process. Any outages that mission-critical computers experience can seriously affect the ability of your organization to conduct business. To ensure that business continuity is maintained, complete the following steps:

  • Perform Extensive Lab Testing. Lab testing is the first step in discovering any issues that might cause disruption to normal business operations. The more extensively you test, the more likely you are to discover potential deployment issues. For more information about lab testing, see “Testing Application Compatibility” earlier in this guide and “Testing the Service Pack Deployment” in the Windows XP Service Pack 2 Enterprise Implementation Guide.

  • Perform Thorough Pilot Deployment. Pilot deployment is the next step in discovering any issues that might cause disruption of normal business operations. Ensure that the computers included in your pilot represent a cross-section of the computers that exist in your organization. For more information about conducting your pilot deployment, see “Testing the Service Pack Deployment” in the Windows XP Service Pack 2 Enterprise Implementation Guide.

  • Perform Deployments to Mission-Critical Computers Late in the Production-Deployment Process. Even if you have performing all possible tests, new issues might arise during the production-deployment process. By deploying SP2 to mission-critical computers late in the production-deployment process, you increase the likelihood that you will have discovered all issues and reduce any outages for these mission-critical computers.

  • Provide Fast Restoration to the Previous Environment. Despite taking all possible steps to mitigate any incompatibilities, problems might still occur on some computers after SP2 is deployed. You must be able to restore the affected computers to their previous configuration so that business continuity is maintained. For more information about conducting your pilot deployment, see “Rolling Out SP2” in the Windows XP Service Pack 2 Enterprise Implementation Guide.

Deploying to Mobile Users

Mobile users can present unique challenges to your SP2 deployment. Use the following methods to deploy the service pack to mobile users:

  • Have remote users connect to the organization’s intranet through a VPN, then install the service pack by using the deployment method you have chosen.

  • Distribute CD-ROMs containing the service pack to mobile users, then have them install the service pack from CD-ROM.

  • Install the service pack through Windows Update.

    Note:  Another option is to have mobile users bring their laptops into one of your organization’s locations and install the service pack from the organization’s intranet. This option may not be practical for some mobile users because they might not be geographically close to one of your organization’s locations.

Table 14 lists the deployment criteria for mobile users and the recommended methods for each criterion. You can also use a combination of these methods to deploy the service pack to your mobile users.

Table 14. Deployment Criteria and Methods

Deployment Criteria

VPN

CD-ROM

Windows Update

Users use high-speed remote connectivity (from public Internet access points or from home) to connect to your organization’s intranet.

 

Users use dial-up modems to connect to your organization’s intranet.

  

Your organization’s remote access servers have the available bandwidth to support SP2 deployment.

  

You want to maintain tight control over SP2 deployment.

  

Whenever possible, chose the VPN method for deploying SP2. Select the CD-ROM method when mobile users have only dial-up modem access. (Remember that it takes 11 hours, 30 minutes to install SP2 over a 56 kilobits per second (Kbps) connection.) Select Windows Update when your remote access infrastructure is insufficient for deploying SP2 to mobile users over a VPN and the mobile users are capable of installing SP2 alone.

VPN

Deploying SP2 over a VPN is the recommended solution, but your organization’s remote access servers may not be able to support the deployment. When deploying the service pack over a VPN, incorporate the following recommendations:

  • Require Layer Two Tunneling Protocol (L2TP). In addition to the data rate of the mobile user’s connection, you need to be aware of any latency issues that might occur. VPNs that use PPTP are more susceptible to these latency issues than VPNs that use L2TP.

  • Require Encrypted VPN Connections. As a best practice, always encrypt traffic between mobile users and the remote access servers in your intranet.

  • Require Smart Card or Biometric Authentication. These authentication methods significantly reduce the risk of unauthorized access through your remote access servers.

  • Stagger SP2 Deployment to Mobile Users. Doing so ensures that the remote access servers are not saturated. Instruct mobile users to deploy the service pack on specific days and times, and avoid deploying the service pack during periods of peak activity for the remote access servers.

CD-ROM

Distributing SP2 by CD-ROM is recommended when the service pack cannot be deployed over a VPN. Through CD-ROM distribution, you can maintain more control over the final configuration by creating custom scripts to launch the setup and configure the workstation per your organization’s desktop standards.

Ensure that you test these custom scripts in your lab and pilot deployment. Provide sufficient instructions to mobile users so that they can successfully launch your installation script.

Note:  If your organization’s desktop standards do not require any specific service pack configuration settings, mobile users can simply install the service pack from the CD-ROM without the need for a custom script.

Ensure that you provide training to the IT support professionals and users who will need to install SP2 through CD-ROM.

Windows Update

If you are unable to deploy the service pack by using a VPN or CD-ROM, provide mobile users with instructions for deploying SP2 through Windows Update. For small branch offices or mobile users, this method may be preferred. As with the CD-ROM method, ensure that you provide training to the IT support professionals and users who will need to install SP2 through Windows Update.

Planning Communication

Effective communication among the project teams and with users ensures that all project participants are well informed and have the necessary information with which to make decisions. In your SP2 deployment plan, define how the project will establish a reliable means of ensuring visibility and cooperation by communicating status and news about the project to all appropriate stakeholders. This part of the plan identifies the processes, methods, and tools required to ensure timely and appropriate collection, distribution, and management of project information for all project participants:

  • Objectives. This section identifies the purpose of the plan in terms of what the project’s communications process will accomplish. Communications objectives may include subjects such as timeliness, security, and breadth of communications.

  • Confidential and Sensitive Information. This section provides general guidance for disclosing information. It should identify any specific project members who will provide direction in this area when questions arise. Certain project or technical information may be confidential or sensitive to the project or to certain people or companies within the project: Care should be taken not to divulge such information.

  • Internal Reporting. This section identifies the mechanisms and organizational structure for normal and as-needed project reporting. Clear articulation of communications responsibilities ensures that information is created and distributed to support efficient project activity.

  • Project News and Briefings. This section describes how as-needed communication such as news bulletins, subject-specific briefings, and updates for users will occur.

Training for IT Staff and Users

Before you deploy SP2, you must provide the relevant training for the IT professionals and users in your organization. Based on the target audience, the training should be performed at various stages in the deployment process. Provide training prior to each IT professional performing his or her part in the deployment process. Provide training for users prior to their installing the SP2.

IT Staff

Based on their role in the deployment, you must provide training to different members of your IT department at different times during the deployment process. Figure 8 illustrates using the MSF Process Model the timeline for training the various IT roles. Remember that these IT roles provide one way to categorize responsibilities, and your organization may divide tasks differently. Notice that as the deployment project progresses, more IT department members are trained. Ensure that the entire IT department is trained prior to the Deploying Phase.

Figure 8. Timeline for Training Various IT Roles

Figure 8. Timeline for Training Various IT Roles

Also, during the Envisioning Phase, you may want the project leaders from each team to attend training with the architects. In this way, the project leaders will be aware of the scope of the project, which will help them schedule training time for their respective team members. Table 15 lists high-level IT roles and the type of training they need.

Table 15. IT Roles and Type of Training Required

Job Role

Training Required

Architect

Conceptual information during the Envisioning Phase, then more prescriptive design guidance during the Planning and Developing Phases.

Developer

Architectural changes and updates for application development information during the Planning Phase, then more hands-on development guidance during the Developing and Stabilizing Phases.

Implementer

Conceptual information during the Planning Phase, then more hands-on implementation and deployment guidance during the Developing and Stabilizing Phases.

Administrator

Conceptual information during the Developing Phase, then more hands-on implementation, administration, and management guidance during the Stabilizing Phase.

Support

Conceptual information during the Developing Phase, then more hands-on implementation, administration, management, and troubleshooting guidance during the Stabilizing Phase.

Users

In most instances, users see little or no change after SP2 deployment is complete. However, if you discover any application incompatibilities or any applications require user interface (UI) changes, you must communicate these changes to the users. Table 16 lists the types of users and the training they will require.

Table 16. Types of Users and the Training They Require

Types of Users

Training Required

All users

Web seminar or self-paced training that reviews any changes in applications, including:

  • Changes to applications that affect the application UI.

  • Applications that are no longer compatible.

  • Possible workarounds for application compatibility.

Users who work in branch offices that do not have IT support

Provide training similar to that for administrators or support technicians so that users can install the service pack, including installing the service pack via Windows Update.

Mobile users

Provide training similar to that for administrators or support technicians so that users can install the service pack, including installing the service pack via Windows Update. Also, use Web seminar or self-paced training about the new networking features. (For example, many mobile users gain remote access by using wireless networks.)

As you can see in Figure 8, based on the type of user listed in Table 16, user training should start during the Developing Phase (for users who need training similar to that provided for administrators or support IT roles). The application-related training for users should occur prior to SP2 deployment to the user’s computer.

Note:  You will need to develop the training content for changes to applications within your organization. For training on installing SP2 and the new networking features, see Windows XP Service Pack 2 Resources for IT Professionals.

Designing the Deployment

After the planning team creates, reviews, and accepts the SP2 deployment plan, the project passes on to the implementation team. The Windows XP Service Pack 2 Enterprise Implementation Guide describes how to deploy SP2 by using SUS, SMS, and Group Policy and also provides step-by-step instructions for using each of these technologies to deploy the service pack. That guide contains 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 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, including checklists for recording the results.

Rolling Out SP2

This section describes the final stages of 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 this 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.

For More Information

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft