In this two-part series, Serdar Yegulalp explains the benefits of Windows Update Services, the next version of Software Update Services (SUS), which is currently available for open evaluation until the final product is released later in 2005. In part one, Serdar outlined how to set up WUS on a server. In part two below, he'll explain how to use it to roll out XP SP2 updates to desktops and when not to use WUS.
Rolling out XP SP2 with WUS
The most common and important update you'll currently want to roll out with WUS -- currently available for open beta -- is Windows XP Service Pack 2.
The full SP2 install is 270 MB. To handle the sheer download size, you'll probably want to use WUS' custom computer groups setup, mentioned in part one to deploy SP2 to different sets of computers at once. Doing so will prevent all computers on the network from attempting to retrieve SP2 at the same time, creating massive local bottlenecks.
It is also possible to use Group Policy to control the bandwidth used by Background Intelligent Transfer Service (BITS) 2.0, a technology designed to minimize the download size and network bandwidth consumption caused by most update deployments. Group Policy will then be used for the client computers to retrieve updates. For more information on how to do this, see BITS tutorial.
Note that bandwidth throttling for BITS should only be used during the time needed to roll out SP2 or other large-scale updates, since BITS is used by other services such as SMS and shouldn't be throttled continuously.
When not to use WUS
Be wary of using WUS to push updates to servers. If a server is set to silently install updates and then reboot automatically, this could unexpectedly disrupt service. Servers should be patched and rebooted manually. This goes double for remotely-managed servers in a headless/lights-out configuration where an unexpected reboot can really throw people off ("Did the system just crash?").
Furthermore, when using WUS to deploy updates the hosts contact the update server every 17 to 22 hours with the exact interval determined randomly. The randomization prevents all clients from trying to contact the server at the same time, but it also prevents the newest updates from being retrieved absolutely immediately. If you value immediacy more than convenience in your organization, you may want to use a different approach, but if you don't need to have updates rolled out within the hour, WUS should more than do the job.
More Information from SearchWindowsSecurity.com
Tip: Return to part one to learn how to deploy the beta version of WUS on a server
Tip: Learn how to simplify your XP SP2 install
Patch Management Tips: Get more dos, don'ts and best practices for patch management here
