As the administrator of my network, I have acquired a new job title in the past year: Hotfix Guy. Every few days, I check Microsoft's Web site to see whether the company has added a patch or hotfix for some frightening new security hole. Whenever I find a new hotfix, I scramble to install the patch on all my systems before someone writes a worm that exploits the security hole du jour and hacks those systems.
Another fun administrative task is setting up new Windows XP systems, connecting them to the Internet, and waiting while each system downloads the necessary 582MB of post-XP-release fixes. Yes, I love doing that; it gives me time to catch up on my reading.
Seriously, I suppose I could roll out Microsoft Systems Management Server (SMS) or something similar to apply patches and hotfixes, or I could create a Windows Installer (.msi) package for every new critical update and use Group Policies to roll out each one. But I don't want to purchase and learn SMS just so I can perform system updates; nor do I want to create an .msi file for each update. So I was happy to see last week that Microsoft released Software Update Services (SUS).
The concept behind SUS is simple: You install the server component on a Windows 2000 server (or a Windows .NET server after Microsoft finishes it) and install a client component on every XP and Win2K client system—even XP Home machines. (Unfortunately, SUS doesn't support Windows NT 4.0 clients.) The clients then pull their system updates from your SUS server, rather than from Microsoft's Web servers, and I don't have to play Hotfix Guy any more.
I haven't had much time to work with SUS yet, but thus far, the program has been fairly easy to set up and use in an Active Directory (AD)-enabled shop. The SUS server console lets you download updates from Microsoft's Windows Update servers to your SUS server—or servers, you can create a hierarchy. The updates use a Microsoft certificate for authentication, so if someone fools your DNS into sending your SUS server to a server containing harmful updates, your SUS server would reject the updates. Microsoft doesn't test updates as thoroughly as it tests service packs, so you'll want to install only the updates you really need. The SUS server lets you choose which updates to offer to clients and which ones to skip. The SUS server communicates with the clients through HTTP, so every SUS server must run Microsoft Internet Information Services (IIS). The SUS server also must be a member server and be running Win2K Server Service Pack 2 (SP2) and Internet Explorer (IE) 5.5 or later.
Because the SUS server must be a member server and not a domain controller (DC), many small shops that have only one or two servers—usually DCs—won't be able to take advantage of this important new tool. I teach seminars about server planning and administration, but because most classroom setups have only a server or two and all those servers are usually DCs, I won't get to demonstrate SUS. Even in larger firms, the trend towards server consolidation means that systems have a higher percentage of DCs, so disallowing DCs as SUS servers doesn't make much sense.
Requiring IE 5.5 or later is also annoying. Most people don't do much Web-surfing from their servers, so many servers still run IE 5.0 and will require an IE upgrade. And IE installations require a reboot—even the IE 6.0 installation. Hasn't Microsoft learned that making us reboot our mission-critical servers just to install applications such as Web browsers is amateurish? I don't recall Red Hat requiring me to reboot when I install a new doodad on my Linux Sendmail server.
After you install SUS, it runs the IIS Lockdown Wizard in an unattended mode—a wise touch on Microsoft's part, although I'd prefer that the wizard ask before adjusting the system's Web server. You control SUS through the SUS administrative Web pages. Your first task is to let SUS go out to the Windows Update Web site and download a few tons of patches just to get caught up. You only have to do that task once; you can set up SUS servers to either get their updates directly from Microsoft or from another SUS server. You can let any subsequent servers grab the initial 100+MB of patches from a local SUS server. After the first synchronization, you can configure how often you want your SUS server to check for updates and whether it automatically distributes any new patches or waits for your approval before distributing them.
Next, you need to install the SUS client component on your XP and Win2K systems. The client program is a modification of XP's Automatic Updates feature. The client is packaged as an .msi file, so you can deploy the program with a Group Policy in an AD shop, using msiexec from a command line, or by whatever method you typically use to distribute software.
The client periodically asks the SUS server for any new updates and, depending on how you configure the client, the client can automatically download and install the updates and reboot if necessary, with no user interaction. If the client computer is performing an automatic update while someone's logged on to that computer, the user will get a warning 5 minutes before the installation and another warning 5 minutes before the reboot.
Although the SUS client component installation places an Automatic Updates applet in the Control Panel, the applet has no GUI to set up functions such as automatic operation or to tell the client what SUS server to draw its updates from. Instead, you need to use the registry or Group Policies to configure the SUS client. (As always, you can use a custom NT 4.0-style system policy to remotely control those registry settings if you don't have AD to hang a Group Policy on.) The fact that you need to configure the client either by spelunking in the registry or playing with a Group Policy or system policy isn't a showstopper—who'd want to hand-configure 1000 workstations—but it makes the initial experimentation a bit more complex.
After you get past the initial install, SUS seems to be a useful tool, and the price is right. But remember, before you install SUS, you need to find a Win2K SP2 server that's a member server and has IIS and IE 5.5 or later installed. Also, be prepared for a bit of policy work or registry scripting to make the client work. SUS is free on the Microsoft downloads page ( http://www.microsoft.com/windows2000/windowsupdate/sus/default.asp ). Give it a try!
