Deploying Windows XP Service Pack 2 using Software Update Services

On This Page

Introduction
Key benefits of using SUS to deploy Windows XP SP2
Situation overview
Factors to consider when using SUS to deploy Windows XP SP2
Overall recommendations
Summary

Introduction

Windows XP Service Pack 2 (SP2) contains major security improvements designed to provide better protection against hackers, viruses, and worms. Windows XP SP2 also improves the manageability of the security features in Windows XP and provides more and better information to help users make decisions that may potentially affect their security and privacy. Microsoft strongly urges customers with Windows XP and Windows XP Service Pack 1-based systems to update to Windows XP SP2 as soon as possible.

As a best-practice approach to implementing a managed rollout of Windows XP SP2, customers are encouraged to use a corporate update management solution such as Systems Management Server (SMS) 2003 or Software Update Services (SUS).

The following section details considerations for deploying Windows XP SP2 using SUS.

Key benefits of using SUS to deploy Windows XP SP2

1. Allow administrators to control the deployment Windows XP SP2 (as well as other updates) across their Windows systems.

2. Allow customers to safely disable direct Automatic Updates (AU) or Windows Update (WU) access from individual systems, while allowing these systems to get the necessary critical security updates and other administrator-approved updates.

3. SUS will automatically and silently install Windows XP SP2, while installation of Windows XP SP2 via WU or AU requires user or administrator interaction on each system.

4. Dramatically reduces network traffic into the organization, since updates only need to be downloaded to one or a small number of servers within the organization, instead of being downloaded separately to each system requiring the update.

More information on SUS is available at www.microsoft.com/sus

Situation overview

Because Windows XP SP2 is a relatively large update (approximately 270 MB), SUS administrators need to consider the impact on internal network traffic and on the machine on which the SUS server is running.

For the vast majority of SUS implementations, server and network load will not be a concern and SUS administrators will not have to take mitigation actions described below, although it is recommended that the SUS administrator monitor the performance and load on the SUS server when the update is initially approved.

Under ideal conditions for a dedicated SUS server, assuming a 100 Mbps server network card capacity with 20% of this capacity consumed as overhead, it will take approximately 30 seconds for a SUS client to download the Windows XP SP2 update from the server. This translates to 2880 client downloads in a 24-hour period.

While this is the theoretical number of clients that can be supported in a 24-hour period if only one client is in contact with the server at any given time and there is no time gap between servicing one client and the next, a couple of factors contribute to reducing this number in reality. These include:

1. SUS clients contact the server at randomized intervals of between 17 and 22 hours. Hence, the client synchronizations are not serialized and it is likely that more than one client will contact the server at the same time, particularly in environments that have a large number of SUS clients.

2. If the SUS client machine is turned off when it is scheduled to contact the server, it will attempt to contact the SUS server approximately 10 minutes after the client machine has been turned on. Because many systems would typically be turned on around the beginning of the work day or the start of a work shift, an unusually high number of clients (relative the volume of clients contacting the server through the rest of the day) would attempt to contact the SUS server at this time.

Although clients that cannot be serviced by the SUS server because of capacity limitations will attempt to contact the server again after approximately 5 hours, this overload situation will result in slowing down the server and generating additional network overhead.

The following section provides guidance to prevent this situation from occurring.

Factors to consider when using SUS to deploy Windows XP SP2

1. Number of Windows XP systems configured to use a SUS server

2. Bandwidth capacity of the SUS server machine’s network card or network connection

3. Whether the SUS server machine is running other services (e.g., domain controller, file & print, etc.) and if so, the estimated bandwidth required by these services

4. Available network bandwidth for deploying Windows XP SP2 (if this is less than the bandwidth capacity of the SUS server machine)

The following guidance is provided for the minimum SUS server configuration – Intel P700 system with 512MB RAM and a 100 Mbps network card and network connection, which is dedicated to running the SUS server (no domain controller, etc.) and is on a network where the available bandwidth exceeds the bandwidth capacity of the server’s network card. If your SUS server machines is running additional services or the available network capacity is less than the server network card capacity, you will need to adjust this guidance to reflect your situation.

Overall recommendations

There are essentially three options, depending on the number of Windows XP systems to be updated using your SUS server (if you have one or a few SUS servers) and the topology of your SUS implementation (if you have many SUS servers):

1. No action is necessary if you have less than 2000 Windows XP machines that need to be updated with Windows XP SP2 per SUS server

2. Use the limited-time approval technique described below if you have between 2000 and 15000 Windows XP machines that need to be updated with Windows XP SP2 via the SUS server

3. Implement one of the following bandwidth throttling mechanisms if you need to control the maximum bandwidth used to deploy Windows XP SP2 using SUS:

   • Limit the maximum number of concurrent connections and maximum bandwidth served on SUS IIS server

   • Limit the maximum bandwidth used by SUS clients to download SUS content by configuring BITS (Background Intelligent Transfer Service) 2.0 accordingly

For the first (no action necessary) option, it is recommended that the SUS administrator monitor the server load when the update is first approved and for the first hour of the work day or first work shift after the Windows XP SP2 update has been approved.

The limited-time approval technique works by limiting the number of SUS clients that see the Windows XP SP2 update on the list of approved updates when they contact the SUS server on any given day while this technique is in use, thereby controlling the number of clients that are serviced per day and limiting the server load and additional network overhead (retry attempts, etc.).

The third set of options works by limiting the bandwidth used by the SUS implementation, thereby controlling the load on the server and the network.

The following table summarizes the options for the various situations:

Limited-time approval technique

This technique relies on the SUS administrator to approve and then un-approve the Windows XP SP2 update on the SUS server on a daily basis, until the number of Windows XP systems that have not received the SP2 update is less than 2000.

Because the update is only approved for a limited time each day, only a subset of the SUS clients contacting the server on a given day will see the update marked as ‘approved’ and will attempt to download the update. SUS clients that contact the server outside this time period will not see the SP2 update in the list of approved updates on the SUS server and will therefore not attempt to download it. This also gives the SUS server time to finish servicing the clients that contacted it during the approval window before a new set of clients attempt to download SP2 when it is re-approved the next day.

This is a manual but easily implemented mechanism to control the load on the SUS server and requires no additional infrastructure configuration or testing. SUS administrators can use the following formula to calculate the amount of time for which to approve the Windows XP SP2 update on each day:

TA = 24000 / (NXP – (1000 * NDE))

Where:

TA = Amount of time (in hours) the update needs to be marked as ‘approved’ on a given day
NXP = Number of Windows XP systems to get SP2 via the SUS server
NDE = Number of days since SP2 was first marked as approved on the SUS server

For example, if there are 12000 Windows XP systems that need to get the Windows XP SP2 update via a SUS server, the calculation would work out as follows: For day 1, the update would need to be marked as approved for 2 hours, since

24000 / (12000 – (1000 * 0) = 2

For day 2, the update would need to be marked as approved for 2.2 hours, since

24000 / (12000 – (1000 * 1) = 2.2; and so on

The full schedule would be as follows:

It is also recommended that you plan your Windows XP SP2 deployment so it doesn’t overlap with the deployment of the monthly security updates from Microsoft (released on the 2nd Tuesday of each month) to eliminate the need to factor in the impact of the deployment of these updates on server load and therefore on the lengths of the approval windows for the Windows XP SP2 deployment.

The following are the pros and cons of using this technique:

Pros:

1. Easy to implement – requires approving the SP2 update, un-approving it after the calculated time period, and repeating the process the next day, until the number of machines left to be updated is less than 2000

2. Server-side mechanism eliminates the need to make configuration changes on SUS client machines

3. Works even where Active Directory-based Group Policy or another scalable administration mechanism (scripting, etc.) is not in place to control registry settings on Windows XP machines

4. No testing required

Cons:

1. Requires daily SUS administrator intervention, until the number of Windows XP systems left to be updated is less than 2000

Bandwidth usage throttling using IIS

This option allows limiting the maximum bandwidth that may be used for SUS by setting the appropriate values for the maximum number of concurrent connections and the maximum bandwidth the IIS server allocates to servicing SUS requests. These configuration options are available with IIS 5 as well as IIS 6.

The IIS server will allocate the maximum bandwidth usage specified equally across the concurrent connections specified.

For the standard SUS machine (P700, 512 MB RAM, 100 Mbps network card), set the maximum concurrent connections to 100 and the maximum bandwidth for the SUS Web site to 80 Mbps. In this example, the value of 100 for maximum concurrent connections is an estimate for what the server machine can handle under heavy data transfer load conditions, given its CPU and memory capacity.

Pros:

1. Easy to implement – set configuration settings on IIS server

2. No ongoing administrator intervention necessary as in the case with the ‘limited-time approval’ technique

3. Can selectively control maximum bandwidth served for SUS client requests without need to restrict bandwidth server for other sites (if any) on the IIS server

4. Server-side mechanism eliminates the need to make configuration changes on SUS client machines

5. Works even where Active Directory-based Group Policy or another scalable administration mechanism (scripting, etc.) is not in place to control registry settings on Windows XP machines

6. Easy to test

Cons:

1. Limiting concurrent connection and maximum bandwidth for the SUS site on IIS impacts all SUS clients, not just the SUS clients that are Windows XP machines – this would be an issue if you need to deploy other updates at the same time as you are deploying Windows XP SP2

2. Administrator needs to reset the IIS configurations back to the normal settings once 2000 or fewer Windows XP machines remain to be update

3. If the maximum number of concurrent connections is specified for all IIS server connections and not limited specifically to the SUS server Web site, this will impact any other Web sites served by the IIS server

Resources:

• IIS 6

  • For information limiting concurrent connections on IIS 6, see: https://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/qos_limitconn.asp?sd=gn&ln=en-us&gssnb=1

  • For information on throttling bandwidth on IIS 6, see: http://technet2.microsoft.com/windowsserver/en/library/e3d396dd-c141-432b-9e69-50f597061e471033.mspx

  • For additional information on IIS 6 performance tuning, see: https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/71490aae-f444-443c-8b2a-520c2961408e.mspx

• IIS 5

  • For information limiting concurrent connections on IIS 5, see: https://windows.microsoft.com/windows2000/en/server/iis/htm/core/iilimcn.htm?id=128

  • For information on throttling bandwidth on IIS 5, see: https://windows.microsoft.com/windows2000/en/server/iis/htm/core/iithrot.htm

  • For additional information on IIS 5 performance tuning, see: https://windows.microsoft.com/windows2000/en/server/iis/htm/core/iiabtpm.htm

Bandwidth usage throttling using BITS 2.0

This option uses the BITS 2.0 maximum bandwidth usage parameter to control the amount of bandwidth used by SUS clients when interacting with the SUS server. For example, if the maximum bandwidth you want used on the SUS server (or the network overall) to deploy Windows XP SP2 using SUS is 100 Mbps and there are 5000 Windows XP systems on the network, setting the maximum bandwidth usage to 20 Kbps on each client system will limit overall network bandwidth to 100 Mbps.

Pros:

1. Allows granular control over maximum bandwidth that can be used on the network for deploying Windows XP SP2 using SUS

2. Can be centrally configured using Group Policy

3. Provides ability to control maximum bandwidth used only for the SUS clients that are Windows XP machines

4. No ongoing administrator intervention necessary as in the case with the ‘limited-time approval’ technique

Cons:

1. Only works for environments where BITS 2.0 is implemented – if not implemented, administrator needs to install BITS 2.0 to all client systems

2. Only works for ‘managed’ Windows XP systems, i.e., systems that the SUS administrator knows about and on which the administrator has the ability to control BITS 2.0 settings

3. BITS maximum bandwidth limitations will apply to all services (e.g., SMS) running on the client machines that use BITS, so these services may exhibit poor performance or may not work correctly as a result.

Resources:

• For information on configuring BITS on client machines using Group Policy, see: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/bits/group_policies.asp

• For more information on BITS, see: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/bits/bits_start_page.asp

• For information on deploying BITS 2.0, see: https://support.microsoft.com/default.aspx?kbid=842773

Summary

Windows XP Service Pack 2 (SP2) contains major security improvements designed to provide better protection against hackers, viruses, and worms, and Microsoft strongly recommends that customers update their Windows XP machines with SP2 as soon as possible.

Once the Windows XP SP2 update has been tested and certified for deployment to your machines, SUS provides an easy mechanism for deploying the update to these machines. Because of the size of the Windows XP SP2 update, SUS administrators should consider the impact of its deployment on SUS server and network load. For the vast majority of SUS implementations, this will not be a concern and SUS administrators will not have to take mitigation actions, although it is recommended that the SUS administrator monitor the performance and load on the SUS server when the update is initially approved.

For environments with more than 2000 Windows XP machines being updated by a single SUS server, use one of the mitigation options detailed above. These are temporary steps that only need to be in place until the number of Windows XP machines remaining to be updated drops to less than 2000.

More Information

Please review the FAQ, at https://www.microsoft.com/technet/prodtechnol/winxppro/deploy/xpsusfaq.mspx

Update on Delivery of Windows XP SP2 Through SUS: https://www.microsoft.com/technet/prodtechnol/winxppro/deploy/xpsusfix.mspx

Download

Deploying Windows XP Service Pack 2 using Software Update Services
139K
Microsoft Word file