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


  • This was first published in February 2005

    There are Comments. Add yours.

     
    TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

    REGISTER or login:

    Forgot Password?
    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
    Sort by: OldestNewest

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.