If you stay as busy as I do, you probably feel that there
just aren’t enough hours in the day to get everything done, especially when it
comes to downloading and deploying the latest Windows patches that Microsoft
constantly seems to be releasing these days. Fortunately, Microsoft
acknowledges that patch management is a royal pain and has come up with a
couple of solutions.

These solutions are SMS Server and the System Update Service
(SUS). SMS Server is a fairly expensive server application designed for deploying
patches and other types of programs across large networks. The System Update
Service, on the other hand, is a free, patch deployment utility, but it’s not
nearly as flexible as SMS Server. If you’re currently using SMS Server, you
should continue to use it because it’s superior to the System Update Service.
If an SMS Server just isn’t in the budget, though, this article will tell you
how you can download, install, and configure the System Update Service.

Acquiring SUS

You can download SUS slipstreamed with Service Pack 1
directly from Microsoft’s
Web site
. The download consists of a 32.2-MB self-extracting executable.
You’ll want to download this file to an empty folder on the server that will
act as your SUS distribution server. The server must be running Windows 2000
Server with Service Pack 2 or higher, or Windows Server 2003. SUS requires that
the server be running in Application Server mode, which means that IIS must be

Installing SUS

Begin the installation process by double-clicking the
sus10sp1.exe file that you downloaded. When you do, Windows will extract the
necessary files and launch the Setup Wizard. Click Next to bypass the wizard’s
welcome screen, and you’ll be presented with the software’s end-user license
agreement. Accept the license agreement, click Next, and you’ll be asked
whether you prefer a typical or custom installation. For demonstration purposes,
choose the Custom Installation option.

The next screen you’ll encounter is easy to accidentally
bypass because the top portion simply asks for the path where you want to
install SUS. However, you really need to pay attention to the bottom portion of
this screen. It asks where you’d like to store the software updates.

Your choices are to either store the updates locally or to
keep the updates on a Windows Update Server at Microsoft. I recommend storing
the updates locally. Doing so will consume a considerable amount of disk space,
but it offers much better performance than the alternative option.
Unfortunately, I can’t really tell you how much disk space this option will
consume because it depends entirely on the updates that Microsoft sends out.

After making your choice, click Next and the wizard will ask
you which languages you want to store updates for. The default choice is All
Available Languages, but I suggest choosing either the English Only option or
the Specific Languages option. The reason is because of disk space and
efficiency. For example, imagine that a new service pack came out tomorrow and
was 200 MB.

If you have SUS configured to store updates in all available
languages, there might be a dozen different localizations of the service pack.
This means that SUS would have to download the same 200-MB service pack a dozen
times and would require 2.4 GB of hard drive space. That’s fine if you need all
of those languages, but if you don’t, save yourself the download time and the
disk space by choosing a more appropriate option.

Click Next, and you’ll see another rather tricky
configuration screen. This screen asks if you want to automatically approve new
versions of previously approved updates, or if you’d prefer to approve those
updates manually. There are a couple of reasons this question is a bit tricky.
The most obvious is that a lot of network administrators like to maintain total
control of which patches are installed. In such a case, it’s best to manually
approve updates. At the same time, though, automatic approvals save time and
ensure that updates are applied to clients more quickly.

Another reason this question tends to be a bit tricky is
because a patch will sometimes supersede a preexisting patch. This means that a
patch you’ve previously approved must be removed and replaced with a corrected
patch. Allowing SUS to automatically approve new versions of previously
approved updates allows buggy patches to be removed so that they may be
replaced with a corrected version. For this reason, I recommend allowing
automatic approval of new versions of previously applied patches.

Click Next, and the wizard will display the URL that SUS
clients should be pointed to—usually http://server_name. Make note of this URL
and click Install to begin the file copy process. When the wizard finishes
copying the necessary files, it will display one last screen. Before you click
Finish, be sure to read the screen because it contains the URL used for SUS
administration. SUS uses a Web-based interface rather than an MMC console, so
it’s important to know this URL, which is usually http://server_name/SUSAdmin.

The SUS Administration console


After you click Finish, the wizard will automatically open
Internet Explorer and take you to the SUS Administration console. After signing
in to the console, click Set Options, which lets you specify the SUS
configuration options. I won’t bore you with the details because most of the
options available on this screen are the same ones you already worked through
during the initial setup. This screen just lets you change any settings that
you might not be happy with. It also gives you the chance to specify whether a
proxy server should be used to connect to the Internet, as shown in Figure A.

Figure A

The Set Options link allows you to correct options chosen during Setup and
lets you specify whether a proxy server should be used to access the Internet.

Creating a synchronization schedule

Once the initial installation is complete, you need to create a synchronization schedule. This schedule determines how often the SUS
server downloads updates from Microsoft. Click on the Synchronize Server link
followed by the Synchronization Schedule button. You’ll then see the Schedule
Synchronization dialog box, shown in Figure

Figure B

The Schedule Synchronization dialog box allows you to determine how often
software patches should be downloaded.

As you can see in the figure, your SUS server is, by
default, set to never synchronize according to a schedule. To create the
schedule, select the Synchronize Using This Schedule radio button. Next, select
the time of day you want to have the synchronization occur. Synchronization
can be bandwidth-intensive, so you should pick a time for synchronization that
will not be disruptive to your users or to your nightly backup operations.

In addition to selecting a time for the synchronization to run,
you must choose the days. You can synchronize either daily or weekly. The last
option that must be set is the number of retry attempts. By default, if a
scheduled synchronization fails, SUS will retry three times, waiting half an
hour between each attempt. You can use the Failure drop-down list to choose
the number of retries that you feel is right for your network.

Once you’ve set all the options, click OK to create the
schedule. At this point, I recommend clicking the Synchronize Now button. Doing
so will perform a manual synchronization so you don’t have to wait until the
next scheduled synchronization to receive the latest patches. The initial
synchronization can take awhile to complete, but subsequent synchronizations
shouldn’t take quite so long.

Configuring the domain policy

So far, I’ve shown you how to install and configure SUS on a
server. If you stop now, SUS will compile a catalog of updates, but those
updates will never be distributed or installed on the workstations. To allow
the updates to be distributed, you’ll have to modify the group policy for the

Go to a domain controller and open the Active Directory
Users And Computers console. When the console opens, right-click on your domain
and select the Properties command from the resulting shortcut menu to see the
domain’s properties sheet. Select the properties sheet’s Group Policy tab,
verify that the appropriate group policy is selected, and click the Edit
button. Windows will now load the Group Policy console.

Navigate through the console tree to Computer Configuration
| Administrative Templates | Windows Components | Windows Update. Select the
Windows Update container, and you’ll see four options appear in the pane to the
right. Right-click on the Configure Automatic Updates option and select the
Properties command from the resulting shortcut menu. This will open the
Configure Automatic Updates Properties sheet.

On the properties sheet, click the Enabled button to enable
automatic updates. Then check out the Configure Automatic Updating drop-down
list. There are three available options: The Notify For Download And Notify For
Install option is a completely manual approach that requires clients to click
an icon to download and install updates; the Auto Download And Notify For
Install option automatically downloads the updates, but prompts clients to
install them; I recommend using the Auto Download And Schedule The Install
option because it’s fully automatic.

After selecting your installation option, you must set a
schedule for the day and time you want the installations to occur, as shown in Figure C.

Figure C

The Configure Automatic Updates Properties sheet allows you to control how
updates are applied to clients.

After clicking OK, you’ll be returned to the Group Policy
console. Right-click the Microsoft Update Service Location container and select
the Properties command from the shortcut menu. You’ll then see the Specify
Internet Microsoft Update Service Location properties sheet. This sheet is very
simple to complete. Click the Enable button and then enter the URL for your SUS
Server into the Set The Intranet Update Service For Detecting Updates field and
the Set The Intranet Statistics Server field. Click OK to continue.

Next, right-click the Reschedule Automatic Updates Scheduled
Installations option and select the Properties command from the resulting
shortcut menu. You may have noticed earlier that I scheduled my updates to
occur at 3:00 A.M. If the system isn’t powered on at that time, though, it will
miss the updates.

The Reschedule Automatic Updates Scheduled Installations
properties sheet allows you to force missed updates to occur the next time the
machine is booted. Just select the Enabled option and enter the number of
minutes that the system should wait after boot-up to process a missed update.

The last option you must configure is No Auto-Restart For
Scheduled Automatic Updates. Some updates will inevitably require a reboot. If
you enable this option, the system will notify users of an impending reboot and
will force the reboot. The exception is that if the user has Administrator
rights, he or she can veto the reboot.

Looking to the future with WUS

It doesn’t seem fair to write this article without telling
you about the Windows Update Service (WUS). WUS is going to be the replacement
for SUS in the near future. According to Microsoft, WUS will be available
sometime during the second half of 2004. However, there’s a lot of industry
speculation that WUS will debut in Microsoft’s next server release, which is
scheduled to ship in the first half of 2005 and is currently code-named R2.

Although the release date is a bit shaky at the moment, some
solid information exists regarding WUS. It will be available for free download
as a feature pack for Windows Server 2003 and Windows Server R2. Microsoft’s
philosophy behind creating WUS is that it wants to combine the power of SMS
Server with the simplicity of Windows Update.

Another nice benefit to WUS is that it will update more
Microsoft products than SUS did. It’s a little strange if you think about it:
SUS updates only Windows, but WUS updates a variety of software on your system.
So what exactly does WUS update?

The release is too far off for me to be able to give you a
comprehensive list. What I do know is that WUS will be able to update Microsoft
Office, SQL Server, and Exchange Server 2003. According to Microsoft, SUS might
be able to update other products when it ships, and over time, SUS will be able
to update all current Microsoft products.

There are also rumors that WUS will be more scalable than
SUS. Microsoft is allegedly creating WUS with parent / child server
capabilities. An administrator will supposedly be able to set
bandwidth-throttling rules and time schedules so that updates don’t completely
drain a network of bandwidth or occur at a time when they will interfere with
other processes.

One other feature that WUS will have is a fairly nice
reporting capability. Although the WUS-generated reports won’t be anywhere near
as comprehensive as those offered by SMS Server, administrators should be able
to tell at a glance which machines have and haven’t been patched.