In-Depth

Patching the Holes

Software Update Services is Microsoft’s new server for distributing hotfixes and patches across the enterprise. It’s also a tremendous time-saver.

• By Jeremy Moskowitz
• March 01, 2003

I SEEM TO HAVE a reputation for not enjoying the all-too-frequent sojourns to users’ desktops. This reputation is well earned, but it’s not the users that bother me. In actuality, there’s good stuff to be found out there: Harold in sales has the neat three-hole putting green set up, Sally at the front desk has the world’s biggest candy dish, and Mike in accounting has those wrought-iron puzzle games. So it’s not the user interaction I dislike so much, but the time it takes to accomplish the most basic tasks once I’m out there.

Take the case of loading a simple security fix or hotfix.

As it stands today, rolling out a security fix—to even a handful of users—is a major undertaking. First, I have to know which security fixes are out there. To do this, I currently subscribe to the Microsoft Product Security Notification Service, which sends me an e-mail whenever a new security vulnerability is discovered and a patch is released. (Sign up at http://www.microsoft.com/technet/security/notify.asp.) After looking through each of those, I figure out which security or hotfixes are appropriate for my environment. For instance, I don’t need to load hotfixes for Visual FoxPro 6.0. Next, I need to test the desired hotfixes on a sample of machines to ensure they don’t blow other stuff up. Finally, I need to march over to the desktop, kick the user off the desktop and hand-load the patch.

Oh, and tomorrow, I have to do it all again when more patches or fixes are released.

In fact, I haven’t even described what the real “worst-case” scenario is. That’s when users simply take it upon themselves to go to the Microsoft Windows Update site and simply click away at the latest fixes. That’s the surest way to disaster because, without proper testing, who knows what patches will cause a conflict?

There’s got to be a better way—a more efficient way—to handle our hotfix and security fix installation problem

There is, and it’s called Software Update Services (SUS).

Note: Some people have tried some non-sanctioned automated methods of getting patches and hotfixes out to their users. For a while I heard that the prescribed way to roll out hotfixes en-masse was to “snapshot” the hotfix via WinInstall LE or a third-party repackaging tool and create an MSI. Then, using Windows 2000 Group Policy and its software deployment features, simply dictate which machines get the hotfix. However, a recent Knowledge Base article, 320539, “Support Boundaries for Repackaging Hotfixes,” talks through both sides of its mouth. On the one hand, the article specifically states, “Hotfixes repackaged in the Windows Installer (.msi) package format are not supported.” Then it goes on to prescribe some best practices for repacking! If you’re currently repacking hotfixes in this manner, my advice would be to stop, and read on—there’s now a better way for the majority of cases.

SUS Server Components
SUS is a new, free download from Microsoft that has one function: To help automate your hotfix and security patch rollouts. Microsoft has dedicated a new Web site to this endeavor, and it can be found at http://microsoft.com/windows2000/windowsupdate/sus/default.asp.

The idea is simple. Set up a server that contacts Microsoft and automatically downloads the latest patches. Then paw through the myriad available patches, flagging and approving the ones you need for your environment. After you’ve approved them, your Windows client machines simply connect up to your server (not Microsoft’s) to receive the patches you approve.

Setting up the SUS server components is relatively easy, but a bit tedious. First, you’ll need to earmark a server to do the job of housing and doling out the security and hotfixes you approve. This machine must be a member server running Service Pack 2 (and can’t be a domain controller or Small Business Server.) It also needs to be loaded with IIS 5.0 and Internet Explorer 5.5 (a long download and consequent install.)

Once you’re set up, you’ll be ready to download the SUS server components, which can be found as an MSI package off the home page listed previously. The file is named SUSSetup.msi and weighs in at a whopping 48MB. The installation is fairly routine, provided all the above requirements are met. However, the installation does run Microsoft’s new IIS Lockdown Wizard. This is important to note because, if you choose to run other applications on the same IIS server, you’ll need to be aware of what that wizard does to your other applications.

After installation is complete, you’re ready to configure your server to talk with Microsoft. To get to the heart of SUS, you can either click the newly installed “Microsoft Software Update Services” icon now located on the Administrative Tools menu of the Start menu or simply fire up IE 5.5 and type in http://{servername}/SUSAdmin.

Start by clicking the Synchronize Server line item on the left-hand side, then configuring a schedule for automatically updating your server (see Figure 1).

Figure 1. Configure your automatic update schedule through Schedule Synchronization.

Once you synch to the mothership at Microsoft, you can approve the updates that are right for your company. Note that the first synchronization can take quite a while (and the longer you wait to get started, the more updates will be waiting for you.) Simply click on the “Approve Updates” line item at the left and choose which updates you want to send on. You can sort the updates by Status, Date, Title or Platform. Simply select the updates you want, then click the Approve button (see Figure 2).

Figure 2. There are many updates to choose from, so plan on your first patch/hotfix download from Microsoft taking a while.

SUS Client Components
Now that you’ve got the server side standing by, you’re ready to prepare your clients. Note that SUS only works with Win2K, Windows XP and Windows Server 2003 as targets. Windows NT and the like are left out in the cold. This doesn’t appear to be because of any hard-and-fast technical requirement; my hunch is that SUS client-side administration is to be performed entirely with Group Policy, and only newer clients can process Group Policy.

To set up your clients, you’ll need to perform several steps. You’ll first need to download and deploy the SUS client installation file WUAU22.MSI. The file comes as an MSI package, which is handy as you’ll have to leverage Group Policy once again to deploy this to your Win2K and XP population. (Note that downloading and deploying is unnecessary for Win2K SP3 or Windows XP SP1 clients, as the package is integrated into the service pack.)

Next, you’ll need to configure your SUS clients. You’ll do this with a file you’ll swipe off the newly loaded SUS server you prepared in the last section. It’s called WUAU.ADM and is found in c:\winnt\inf. Copy that file to the Win2K DC, which houses the PDC Emulator role. Place the file in the directory c:\winnt\inf.

Now, you’re ready to use Active Directory Users and Computers to put these two pieces together. You’ll need to decide how you want to deploy updates: either to some computers, by placing them into a specific organizational unit (OU), or all computers, by deploying to all computers in the domain.

When ready, create a new Group Policy Object (GPO) at the level you choose; name it whatever you wish, SUS Updates for example; then edit the GPO. If needed, assign the WUAU22.MSI to the client computers you wish and ensure that they reboot to take the change and install the new software.

You have two steps left: Tell the client computers which SUS server to use and how to implement the updates they receive. To do this, import the WUAU.ADM template file copied from the SUS server onto the DC. Right-click the Administrative Templates entry, click Add/Remove Templates, click Add, find the WUAU.ADM file and add it in as one of the templates (see Figure 3).

Figure 3. The “wuau.adm” file tells the computers receiving updates from the SUS server how to implement them.

When you do, you’ll be able to traverse to Administrative Templates | Windows Components | Windows Update and find two new policies: Configure Automatic Updates and Specify intranet Microsoft update service location (Figure 4).

Figure 4. Applying the template from Figure 3 creates two new policies, seen in the right pane.

In the “Configure Automatic Updates” policy, you can specify how clients should react to changes. Specifically, how and when patches should be automatically downloaded or installed.

In the Specify intranet Microsoft update service location policy, you’ll need to pipe in which server these clients will point to to grab updates. Use the syntax:

Http://{yourSUSservername}

It’s that easy! You’ve just set a schedule for clients with the SUS client software to accept the updates you approve on your SUS server.

Figure 5. Schedule updates from the SUS server through this screen.

Room for Improvement
SUS is a quantum leap in hotfix and patch management. However, there is certainly room for improvement. For instance, SUS stops being useful when you have a specific patch for a specific group of machines. Recall earlier that all client computers are now pointing to a specific SUS server that has been approved with specific updates.

However, if you have a case that requires special action, chances are you’ll still have to trot out to the desktop and load that special fix. If you don’t want to, there’s a kludgy workaround: Set up another SUS server, approve all the specific updates for those clients, and point those clients to use this special, additional SUS server.

To counteract this thorny problem, Microsoft will soon be releasing a “Software Update Services Feature Pack for SMS,” which should allow for specific targeting of hotfixes to machines (though it will require a full deployment of Microsoft’s SMS in order to do so).

Note that SUS doesn’t deploy service packs—it’s only for hotfixes and security fixes. This isn’t really a shortcoming, as Win2K and Windows XP service packs have been a breeze to install all along via Group Policy.

SUS doesn’t update Office, Exchange, SQL or anything else—it’s strictly for updating the Windows OS. Other future areas of improvement for SUS I’d like to see are in the areas of load balancing; specific targeting (without the need for SMS); and a better “flow” for updating, testing, approving and targeting to the client computers.

This doesn’t mean SUS should be passed over. Indeed, SUS definitely works as advertised; if you don’t care about targeting specific fixes to specific client computers, this may be the (free) ticket you seek. It’s a terrific technology, and one I’m delighted to see Microsoft add to its arsenal to protect the systems we use.