Deploying Windows XP Service Pack 2 using Software Update Services (SUS)

Deploying Windows XP Service Pack 2 using Software Update Services (SUS)

In this document:

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

Limited-time approval technique

Bandwidth usage throttling using IIS

Bandwidth usage throttling using BITS 2.0

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

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

Note: SUS is available as a free download to customers with a Windows Server 2003 or Windows 2000 Server license and can be downloaded from https://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-972C-AE66A4E4BF6C&displaylang=en

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:

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.

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

Number of Windows XP systems configured to use a SUS server

Bandwidth capacity of the SUS server machine's network card or network connection

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

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 machine 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):

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

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

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

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

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

Note: Limiting the load on the SUS server or the network via the options described here will result in it taking longer for all the Windows XP systems to be updated, because the bottleneck is the server load. The guidance provided below for each option is based on the same server load assumption, so it should take approximately the same length of time to deploy Windows XP SP2, irrespective of the option implemented.

The following table summarizes the options for the various situations:

Note: If the bottleneck is the SUS server, one option to address the situation is to add one or more SUS servers (most easily implemented behind a load-balanced network).

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:

Note: An important consideration for using this technique is to initiate the approval about 1 hour after the work day or shift starts so the SUS server is not impacted by the spike in clients trying to download SP2 soon after they are turned on.

Note that the above formula is based on conservative assumptions to account for potential spikes in the number of clients contacting the server during the approval window. Using this technique, it is estimated that between 1000 and 2000 SUS client machines will get the Windows XP SP2 update per day.

You may monitor the SUS server using performance counters or the Task Manager and increase the length of the approval windows if you determine the load on your SUS server is not high. Increasing the length of the approval windows will allow more clients to download Windows XP SP2 on a daily basis and reduce the time required to update all your Windows XP machines, but increasing the windows beyond a certain threshold (which will vary due to unique factors in your environment) will cause server overload and unnecessary network overhead which will result in increasing rather than decreasing the time required to update all your Windows XP machines.

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 2^nd 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:

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

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

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

No testing required

Cons:

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.

Note: This configuration will allow about 2000 Windows XP systems to download and install the Windows XP SP2 update per day and will take approximately one hour for each to download, assuming there are no other connectivity bottlenecks.

Pros:

Easy to implement - set configuration settings on IIS server

No ongoing administrator intervention necessary as in the case with the 'limited-time approval' technique

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

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

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

Easy to test

Cons:

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

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

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: https://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/qos_throttlebw.asp?sd=gn&ln=en-us&gssnb=

For additional information on IIS 6 performance tuning, see: https://www.microsoft.com/resources/documentation/iis/6/all/proddocs/en-us/perf_tune.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:

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

Can be centrally configured using Group Policy

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

No ongoing administrator intervention necessary as in the case with the 'limited-time approval' technique

Cons:

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

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

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.