Fusion 13 -- Software Update Services -- SUS How-To

Visit Half Price Computer Books

Deploying Microsoft® Software Update Services Server 1.0 Service Pack 1

Software Update Services offers a way in which network administrators may provide clients with Microsoft software updates via the Windows Automatic Update Service. Software Update Services (SUS) allows clients to download update from a local server, reducing internet bandwidth consumption and affording the administrator of the network to only allow clients (or even certain, chosen clients) to download previously approved updates.

SUS 1 SP1 requires Windows 2000 SP2 (or above) or XP (or above) / 2003 to function, due to it's interdependence on the Automatic Updates service. SUS 1 SP1 will run on Domain Controllers; an important feature not present on previous versions of SUS.

This document deals with installation and configuration of Microsoft® Software Update Services 1.0 SP1. To obtain more information about what SUS is, how it works, it's features, and it's advantages, please visit the SUS home page at: Microsoft ® Software Update Services. For further detailed information on setting up Software Update Services Server, download the White Paper at: http://www.microsoft.com/windows2000/windowsupdate/sus/susdeployment.asp.

Installing Your SUS Server

Download the Server and Client installation files from: http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp
Launch SUS10SP1.exe and follow the installation instructions. If you choose a "Custom" installation, you will need to make a few extra decisions:
1. whether to install the updates on a local directory (default) or redirect to a remote Windows Update Server
2. what language versions of updates you would like to install
3. if you require new versions of already-approved updates to be approved before deployment (default), or if you would like to automatically approve updates to previously approved updates.

Installing in the above manner will set your Software Update Services Server as http://<servername> and your administration web site as http://<servername>/SUSAdmin Upon finishing installation, the admin page will open automatically, prompting you for an administrative login.

Help fund more walkthroughs... visit our sponsor!

Configuring Your SUS Server

Once inside the http://<servername>/SUSAdmin Administration page, go to Set Options on the left. Here, you will be able to configure options such as:
1. Proxy Settings (necessary if you SUS Server will connect to the Windows Update site to download updates through a proxy)
2. Name of the server for clients to use (the name of your SUS Server)
3. Which server to synchronize content from (where your SUS Server will be downloading updates from (directly from Microsoft if this is your only SUS Server, from another SUS Server if you have another SUS Server which will sync with MS)
4. Set the Synchronization Schedule for you server by going to Synchronize Server (on the left) and clicking the Synchronization Schedule button. Set to synchronize with the update server at a time when bandwidth is in low demand, and the server is not busy being backed up / backing up data, etc.) If bandwidth / resource consumption is not an issue, you may then click the Synchronize Now button to download current security patches immediately.

Cheap Books... Increase Your Knowledge Affordably

</frustration><awareness>

Up to 50% OFF on books!

Looking for the best deals in computer books? Visit Half Price Computer Books!

Configuring the Clients

Administrators of workgroups with a fewer number of computers may find it more convenient to update the registry of each computer in order to configure the Automatic Updates clients. If you do have more than a handful of PC’s, like maybe enough to require a domain, than you may want to use Group Policy to set rules for all of the clients at the same time. This will also allow you to easily change rules later down the road, need be.

The scenario outlined in this document describes how to create update rules for clients via Windows 2000 Group Policy. Note: The situation (immediately) below describes a single Software Update Services Server setup. This type of setup will not allow testing of updates previous to deployment using only Software Update Services. Included later in this document will be instructions on how to set up a test SUS Server and a test Group Policy Organizational Unit. Please do study the below situation, as the test SUS Server and test OU’s will be set up in almost identically the same manner.

If you would prefer to hand modify the registry of each PC in your workgroup, exactly which key(s) to edit is explained in detail in the Software Update Services Whitepaper. To update individual registry keys by hand, please refer to the whitepaper at: http://www.microsoft.com/windows2000/windowsupdate/sus/susdeployment.asp.

Create an Organizational Unit in which the Automatic Update Clients will reside.
1. Open the Active Directory Users and Computers MMC Snap-in (can be accessed quickly be typing “dsa.msc” at the run line).
2. Right click on the site and, and click New > Organizational Unit. Type a name for you new unit such as “Automatic Update Clients” (or for a more broad-spectrum name, use “Group Policy Clients”).
Prepare the %systemroot%\inf\WUAU.adm (C:\winnt\inf\wuau.adu) administrative template file
1. The WUAU.adm template has two policies included by default: Basic configuration of the client (how to update and install, what time to install) and Where to install the updates from (where you will specify to update from your SUS server). Another option that can be placed in this file is Automatic Rebooting. If you wish to not allow the PC to automatically reboot after installing the updates (I’m thinking angry users who didn’t save their data, and now the data is lost because the PC rebooted), you will need to add this to your WUAU.adm file. Click here to see what the WUAU.adm file will look like after modification.
Apply a Group Policy to the OU.
1. Right click on the new OU > Properties then click the Group Policy tab.
2. Click New, and type a name for your Automatic Updates policy. Click Edit
3. Add a New Template by Right Clicking “Administrative Templates” and clicking Add/Remove Templates. Click Add, and browse to your previously prepared WUAU.adm file. Click Open to Add the file, click Close on the next screen to exit the Add Templates screen.
Configure the Automatic Updates Group Policy
1. Expand Administrative Templates > Windows Components, and highlight Windows Update. You will now see the three configurable components mentioned above:
  1. Choose to enable Updates, choose if you will like for the updates to be installed automatically, and choose the install day and time (maybe every day, and 3:00am so work is not interrupted by an updating machine). Click Next Policy.
  2. Enable the Update Service Location. Type in the name of your SUS Server (ex. http://Your_Update_Server’s_Name). Click Next Policy.
  3. Enable Prevent Automatic Rebooting to prevent Automatic Rebooting.
  4. Click OK, close the Group Policy snap-in, click OK
2. Add Clients to your Organizational Unit.
  1. Highlight and existing Organizational Unit (such as Computers) and highlight a computer name in the right pane. Right click the pc name, and click Move. Click on the name of the OU you created, and click OK.
3. Apply the Group Policy to the machines. Group policy can be applied to the machines in the OU in one of three ways:
  1. Reboot the machine. A machine will gather group policy information while booting.
  2. Run the one of the following commands to Update your Group Policy:
    1. Windows 2000: “secedit /refreshpolicy machine_policy /enforce”
    2. Windows XP: “gpupdate /force”

Testing your updates before you deploy them company-wide.

It’s a fact of life, software will have bugs! Not everyone is perfect, strangely enough, not even Microsoft ® (sic).
That being said, you may be very interested in testing your updates on a few machines before you apply the update to a few hundred machines and end up with some serious issues. The Software Update Services Deployment Guide describes two basic ways to test updates before you apply them:

Set up a few clients to go directly to Microsoft’s Update Server to download updates. When the updated machines don’t explode, you know you may approve the updates on your Software Updates Server.
Set up a second Software Updates Server for testing. Other than setting up the server on a second machine, you will need to change the above plan in only a few ways:
1. Set your Real Server to obtain updates from your Test Server instead of from Microsoft. In the “Set Options” area of the SUSAdmin web page, you may wish to set the “Select which server to synchronize content from:” to “Synchronize from a local Software Update Services server:”, and enter the name of your first Software Update Services Server. Doing so will save bandwidth, however, your second server will not receive update files until they are approved on your first server. You may allow both servers to download from the internet (avoiding the mentioned “approval” issue) if you are not concerned about the internet connection bandwidth costs.
2. Configure two sets of clients (your main group, and a smaller group for testing updates). You will want to do (most of) the “Configuring the Clients” step twice. You will create two Organizational Units (“Group Policy Clients” and “Test Group Policy Clients” maybe?) and apply Group Policies to them separately. You will be required to configure the WUAU.adm file only once, then use it twice (once for each policy). Ensure that you point one OU (Group Policy Clients) to the real server and the other (Test Group Policy Clients) to the test server while configuring your Group Policies.

Checking clients, parsing IIS logfiles, searching for more help...

At this point, we would all like to think our clients are downloading wonderfully, and security in our MS driven world will be a snap. Unfortunately not all clients take as well to Software Update Services as others. While checking clients, keep this in mind:

Clients will download at (seemingly) random times throughout the day. Clients will install the downloaded updates at the time you specified in your Automatic Updates Client configuration.

What this means is that network traffic will be created by the Automatic Updates clients throughout the day and night. Approved updates will then be stored on the clients until the specified install time.
To view any traffic on the server-side created by the Automatic Updates clients, you may view your IIS LogFile (usually located in the %WinDir%\System32\LogFiles\W3SVC1 directory... this file will be named by the day traffic was logged). While reading the IIS log files, do keep in mind all times listed are in GMT.

To easily make sense of your logfiles (regarding Software Update Services), pass your logfile through the IIS LogFile parser located at http://www.pdxconsulting.com/SUS. This provides a near effortless way of deciphering who is downloading, and what was downloaded from your SUS Server.

When your clients have downloaded the updates, and are simply waiting for the specified time to install, you will notice the Automatic Updates icon will be active in your task tray (close to the clock). When moused over, the icon will provide information on its state (illustrated in the picture below).

For more information on Software Update Services, visit Microsoft's SUS Home at Microsoft Software Update Services or check out SUSServer.com for scarcely documented information and a great SUS user's forum.