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.

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).

Schedule Synchronization
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).

Your first patch/hotfix download is working...
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).

wuau.adm file
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).

Two new policies
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.

Scheduling Updates to SUS
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.

comments powered by Disqus

Reader Comments:

Fri, Sep 19, 2008 Anonymous Anonymous

really good

Mon, Apr 28, 2008 Anonymous Anonymous

This is indeed a nice service, but since when is this news? I even learned about
this in school.

Tue, Oct 16, 2007 Anonymous Anonymous

good

Mon, Oct 31, 2005 Andy London

WSUS is now the top choice and SUS support is ending next year. The WSUS product has all the new bells and whistles you are after with regards to more control and filtering :)

Thu, Oct 20, 2005 RaviKiran Hegde India(Bangalore)

Helpfull Article to implement SUS.The Article was reall cool and understandable to even non-admin people.

Mon, Feb 7, 2005 Anonymous Anonymous

This is a fine primer, it was very helpful... Thanks

Mon, Dec 29, 2003 Anonymous Anonymous

better then my 200 books i got to help me

Wed, Jul 16, 2003 Anonymous Manchester

In terms of Microsoft having a set IP/subnet range for me to set up a rule on the firewall to allow my clients access to patches on within a time window, does anyone know what I would put? PS This article is useful.

Thu, May 22, 2003 James A. Smith Atlanta, GA

Great Article. Thanks to the insight.

Thu, May 22, 2003 scottrell Mpls MN

The article is informative, but the subject...

Another "the whole world is Microsoft" solution. This does nothing for those of us who commit to Windows on the desktop, but not as the NOS.

If Microsoft were truly committed to securing and patching their software, this would be open to everyone with an IIS server--even a workstation version.

Wed, Mar 19, 2003 Dave I. Wild, Wonderful West Virginia

We have been using SUS for several weeks now and the rollout was a very simple registry dump! Great Product, but would like to see it expanded to include Service Packs, IE, Office, etc.

Tue, Mar 18, 2003 Anonymous Anonymous

It does a good enough job to deploy patches. I would like to see better logging of PC's hitting the WUS (windows update services) rather then looking through the IIS logs which arn't very friendly.

Mon, Mar 10, 2003 DDavis Alabama

Nope, this isn't new. It's been available for at least 6 months if not more. I have used it in a production environment and overall it seems to work. There are some querky server-side hiccups that occur periodically (twice in 3 months) that I never could seem to get an answer to from Microsoft or other resources. Twice I've had the whole server just stop responding to patch requests for no reason that I could see. Trying everything, I was finally resigned to reloading the server from scratch (doesn't actually take that long). However, we've now moved on to using the SMS controlled version of SUS from the feature pack. I'm holding my breath and crossing my fingers to see how reliable it is since SMS is riding on top of it. I expect this is just a natural progression and the "real" version that we'll want to use will be in the next release of SMS (ok ok... after 2 service packs). Overall, I'd say it's a good solution for smaller business, but probably not the best solution for enterprise patch deployment.

Fri, Mar 7, 2003 JeremyMoskowitz Anonymous

Nope.. no updates yet. Also, I had many people write in with problems with SUS, so I'm writing a followup piece to troubleshoot SUS. Stay tuned.. should be ready very soon.

Fri, Mar 7, 2003 Ed Maximovich Anonymous

The article was great. The actual SUS product seems to have a mind of its own. If it really worked well, it would be a super Free Product.

Fri, Mar 7, 2003 David Ferentheil Oakland, Ca

Great information. You mentioned the Software Update Services feature Pack for SMS. That has been out for some time now. Do you know of any updates to that?

Tue, Mar 4, 2003 JeremyMoskowitz DE

Hey guys.. Jeremy here. Thanks for the feedback on the article. Yes, it's a bit out of date... there wasn't SP1 when I wrote the piece... I'll ask the editor to print a fix in the letters to the editor column or something similar. Again -- thanks for the feedback!!

Mon, Mar 3, 2003 Anonymous Troy, MI

Good article, but out of date. DC's and SBS can support SUS. A sinngle SUS server can support up to 15,000 clients. So, in a very large enterprise environment, multiple SUSservers are required, and managing which clients point to which servers can be tricky. Also there is a way to target specific computers - but I am sure it is not supported. Thanks for the info. NOTE: SUS should not be required to support a targeted SUS. Instead, proper use of AD should be plenty, and should be fully integrated with SUS, instead of forcing a complete solution that is dependent on another solution (SMS).

Mon, Mar 3, 2003 Anonymous San Diego, CA

Yes, SUS is limited, but Jeremy states this in the article. To be most effective, you'll need the SUS Feature Pack for SMS. I know, not a lot of SMS out there, but that seems to be the best option. For now.

Tue, Feb 25, 2003 Scott Lawry Australia

We have been using SUS for 5 Months now and can certainly see the benifits. Unfortuantely there are still some serious short commings which Microsoft should address. Mainly the inability to reverse a hot fix installation is still manual. Microsoft also still assume that every company can afford to have a pure development environment to test the fixes (i.e. 2 -3 SUS servers) so you are unable to unauthorise a fix once it has been authorised.

Tue, Feb 25, 2003 Anonymous Anonymous

SUS is too limited. Besides that it is only good for security patches and not service packs, you can't pick and choose which workstations get what. It's all or none unless you configure certain workstations to not get the updates... then you are back to the visitation of workstations. It alos doesn't work with Office security updates! MS needs to wake up and make it act more like Windows\Office update with ALL available updates available and the ability to pick and choose who gets what. Not all patches are good for all machines... sometimes you can kill an application. We have seen this on two occasions...

Tue, Feb 25, 2003 Anonymous Anonymous

As system admin this is kind of problem I must deal with everyday. Thanks for the article

Tue, Feb 25, 2003 paul tulsa

While this article has the basic features of SUS detailed, it is out of date. SUS SP1 is already out and it does support running from DC's and SBS. It also has a rescheduled wait time feature that says if your target is off at the time of update to wait x minutes after next boot and install patches.

Tue, Feb 25, 2003 hern new york city

I think SUS is great; I use it for our desktops only. Once a week, they get the latest patches rolled out at 3am. For servers, we patch only if we know the patch fixes or addresses a specific problem. One thing I would really like to see in SUS 1.1 or 2.0 is the ability to filter updates. I don't need updates for XP or IE5.x; I'd rather not have to download those if I don't have to. Great article...

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.