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