You’ve got to hand it to Microsoft. The company may be the biggest problem child in the patch management space, but it's trying
like heck to improve its lot. If you’re still behind in finding a centralized patch management solution for your network,
I highly recommend checking out Microsoft SUS (Software Update Services). It’s central, it works, and best of all, it’s free.
Free, that is, if you don’t measure your own time too much when it comes to configuring the little sucker. We’re installing
SUS, typically as a stand-alone box at most client sites where the owner is simply too tight to pay for managed services or
a centralized management solution of his own.
Microsoft rates the product for as many as 1,000 users, but if you’ve got a 1,000-user network and still can’t get the budget
to afford Systems Management Server (SMS) 2003 or a third-party patch management product, grab your desk plant and quit. For smaller networks, however, it’s a really handy
solution.
SUS works almost the same as Windows Update using the same Automatic Update technology. It just centralizes the update process
to a single machine and allows the administrator to decide when to push the patch and to whom. Best case, you get a chance
to test the patch before it starts eating workstations or applications. Microsoft has even started improving SUS with the
release of SUS Server 1.0 with SP (Service Pack) 1.
Installing SUS is pretty simple. Download the installer and run it on the primary SUS server. The SUS installation process
will run a baseline security check of the system on its own using the IIS (Internet Information Services) Lockdown Wizard
and URLScan security tools, but I’d recommend scanning for vulnerabilities on your own as well. Once installed, the SUS interface
allows you to point it at Microsoft’s Windows Update site for downloads (default) or at other SUS servers if you’re in a larger
organization. I haven’t tried that, but it’s nice to know it’s there.
The initial download of updates takes quite a while, but you can use that time to configure your clients, which will all need
to run the Automatic Update client to see the SUS server. Workstations running Windows XP with SP1 or Win2K with SP3 are already
set to go. I’ve watched the auto client work, and it’s a surprisingly stable process, able to chain multiple updates together
and often begin an update even when the initial connection is broken.
After some initial gaffing when configuring our first SUS server, we quickly got it down to a manageable process we can use
at any customer site. SUS is valuable in two big ways: First, we don’t need to monitor Microsoft’s Update site any longer
and issue alerts to any client running SUS. Second, we can shut down Windows Update on pesky clients who keep updating their
systems and drivers without calling their handy IT consultants first. Really saves on those “It just doesn’t work all of a
sudden" calls.
Microsoft’s happy because now you can run SUS on Windows 2003 Server and Windows 2000 DCs (domain controllers). Frankly, that
gives me the willies, so we stick to a separate server. I sleep better, and SUS works just as well. Microsoft likes the SUS-on-DC
model because it allows administrators to better use the DC’s distribution capabilities. Frankly, this is just a matter of
configuration time, especially on the smaller network, for which we use SUS, so it really doesn’t matter.
In larger networks, I’d ignore SUS and move to SMS 2003 or LANDesk, but if you’re trapped in budget hell and your network
is 100 folks or less, this is definitely a step up in the patch management department.