Not-so-quick-and-dirty patch management

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.