Updates Made Easy
Make way for WUS! Don Jones takes an early look at this SUS upgrade, with its expanded grouping, security and control features.
Microsoft Windows Update Services (WUS), the much-anticipated (and renamed)
version 2.0 of Software Update Services (SUS), is due out late this year at
the earliest. But I, Beta Man, got a demo on an early version of WUS and from Microsoft can
report that, while it won't replace a high-end management tool like Systems
Management Server (SMS), for a free tool it is impressive indeed.
SUS 1.0 provides basic, centralized administration of Microsoft's Windows Update
service. Essentially, SUS downloads all of Microsoft's updates and leaves it
up to you to approve them for use; once you do, they're fair game for all of
your clients. To get the updates, you program your client computers (Windows
2000 and later) to look at your SUS server rather than the Windows Update site.
You can even cut off direct access to Windows Update if you like. SUS also supports
a hierarchical infrastructure, meaning one SUS server can pull updates from
another, allowing you to tier your network to minimize WAN utilization.
WUS operates in much the same fashion, although it will offer two distinct
server roles: Autonomous and Replica. In Replica mode, you manage a single WUS
server, and it synchronizes to multiple subordinate replica servers, perhaps
located at remote offices. You perform all administration, including approving
updates, on the central server; the replicas follow its lead. In Autonomous
mode (the only mode available in the beta), each WUS server can receive updates
from an upstream WUS server (or from Microsoft), but you must approve updates
on each server individually.
Update Services (WUS) 2.0
development—no new dates
Late 2004 to early 2005
Like SUS, WUS installs and uses the Background Intelligent Transfer Service
(BITS) 2.0, which allows it to download updates using the server's "spare" bandwidth.
The difference is that SUS uses BITS only for server-to-client transfers, whereas
WUS uses it for all file transfers, including server-to-Microsoft synchronizations.
BITS throttles the bandwidth used by its host server's NIC to ensure that a
download doesn't overwhelm your LAN. (It does not, however, detect when WAN
bandwidth is in high demand.) If the server wants to use the network for something
else, WUS will throttle down and release bandwidth; when nothing else is going
on, WUS will ramp up and use everything it can get.
Another key new feature in WUS—one requested by many SUS administrators—is
the ability to create groups for your computers, and to approve updates only
for specific groups. This allows you to group two or three test computers into
a pilot group, then deploy updates to them first for testing, for example. You
can also prioritize updates, specifying that certain high-priority updates must
be applied, and whether they'll require a restart of the target computer.
You also get granular control over what updates a WUS server will handle,
with the ability to choose specific products and update classifications—Security
Updates, Critical Updates, Service Packs, Feature Packs and so on. Here's how
it works: You create one or more subscriptions. Each subscription has an associated
schedule (or can be run manually), and synchronizes updates for the products
and categories you specify. Perhaps you want to get security updates every night,
but download feature packs only monthly.
Reporting and Security
WUS also includes extensive reporting capabilities, something completely lacking
in SUS. The coolest is the pre-deployment check, where WUS sends a request to
all clients to see how many would install an update if it were made available.
Responses shoot up to the WUS server, enabling you to get an impact report prior
to actually deploying the update. This information can be used to limit the
daily deployment of updates that prove risky during testing, and to alert your
help desk to the potential increase in call volume.
You can also get status reports for individual updates, providing much-needed
feedback. Unlike SUS, which pretty much just threw the update out there, WUS
keeps track of who has yet to install it so you can watch the rollout progress.
In the beta, this feature rolls deployment data up only from one WUS server
to a parent server; anything deeper than that (say, three or four tiers of WUS
servers) won't report correctly. It's not clear whether Microsoft plans to address
that issue before the final release.
Man's Routine Disclaimer:
The software described here is incomplete
and still under development; expect it to change before its
final release—and hope it changes for the better.
The company did beef up security in WUS: The client only trusts content signed
by Microsoft, so spoofed updates can't easily sneak into the database. The WUS
client and server mutually authenticate one another as well, so your clients
know they're talking to the intended WUS server, not a server trying to impersonate
the official one. Any data exchange between client and server is encrypted.
You can look forward to some new control features in WUS, too:
- Updates that don't require a restart can be installed in the background,
without users' knowledge.
- The new WUS client hides the Microsoft license agreements you normally
associate with the Windows Update Web site, providing a transparent experience.
- You can schedule when updates occur, how frequently clients check for updates,
and even schedule update downloading to occur during a specified block of
time. Because BITS can resume a download where it left off, large updates
can even download over several days, in the block of time you desire, finally
installing when the download is complete.
While WUS is a step in the right direction, it doesn't include everything you
might like to see. My nits include:
- Microsoft built Microsoft Baseline Security Analyzer (MBSA) 1.2 to look
to your SUS server, if you have one, and to ignore any updates which aren't
approved on the SUS server. The theory is, if you didn't approve it, you don't
want it, so there's no point in MBSA complaining that the update isn't installed.
This feature of MBSA 1.2 doesn't work with WUS, although that'll doubtless
go away by the time WUS releases, either in additional WUS support or in a
new version of MBSA.
- The SMS Feature Pack providing SUS integration also doesn't work with WUS.
Again, that support will doubtless come in the final release of WUS or in
a new Feature Pack.
- The WUS administrative console, like SUS, inexplicably uses an HTML interface
instead of an MMC console. This interface also requires that IE be set up
to allow Active Scripting, which in practice means you'll need to uninstall
the Enhanced IE Security Configuration on Windows 2003 (and likely something
similar on XP SP2).
WUS Gets It Done
Your Betas are Belong to Us!
Man is always on the
lookout for quality products to review. If you know of a software
product that is currently or soon to be in beta, contact Beta
Man at [email protected].
Vendors are welcome, but please act early–the meticulous
Beta Man needs plenty of lead time.
If your usual answer to, "How do you handle patch management?" is "Oh, look,
it's coffee break time," you should get on the stick with SUS and WUS post-haste.
Both are free, easy to install and effective. Getting some practice in with
SUS now will help prepare you for WUS, which is similar and extends SUS capabilities
in several important directions.
If you've got SUS already, upgrading to WUS will be a no-brainer. You'll get
all the features you've probably been wishing SUS had, plus an easy migration
path that, even in beta, has given me no problems. If you have a better patch
management solution—SMS, ConfigureSoft's Enterprise Configuration Manager
(ECM), or something else—stick with it. While WUS will offer some neat
integration tricks for SMS (a la the SUS Feature Pack already released for SMS),
SMS is a better overall tool by far, as are tools like ECM (see our online sidebar
for more information).
But for a free patch management solution, WUS is an impressive offering. Kudos
to Microsoft for (finally) offering a robust, scalable patch management solution
that doesn't require expensive per-client licenses (or indeed, any licenses
beyond Windows itself) and doesn't need a month of planning and deployment.
Look for WUS in late 2004, or early 2005 if things slip. WUS does depend on
the public release of Windows Update v5, so a delay in that product's development
will also postpone WUS.
Meets SQL Server
One big difference between Microsoft Software Update Services (SUS) and
the new Windows Update Services (WUS) is that SUS uses a proprietary data store
whereas WUS uses SQL Server 2000.
WUS ships with the SQL Microsoft Data Engine (MSDE) for a simple, single-server
configuration; larger environments may want to opt for a full SQL license to
improve performance and scalability. Although the details aren't quite hammered
out and the beta has some installation restrictions and security caveats, WUS
will be able to access a remote SQL server for its data. There will also be
a migration path from SUS to WUS, where your data is picked up and moved into
the new database.
Keep in mind that SQL Server is a complex product known to have vulnerabilities
(like the famous Slammer worm); don't forget that a "stand-alone"
WUS installation is installing the MSDE behind the scenes. Keep that copy of
SQL Server patched (something WUS can actually do for you, if you point the
WUS server's Automatic Updates client to the WUS server itself for updates)
to avoid having a vulnerable service on your network.
And before you tear your hair out wondering why Microsoft loaded yet another
service on top of SQL Server, understand that there's a good reason: SQL Server
allows for much more complex dependency information between updates. This helps
ensure that, for example, a Windows XP update is never downloaded to a Windows
2000 computer, and that updates are deployed along with all the updates they
depend on. Updates can be grouped into "needs restart" and "doesn't
need restart," smoothing the end user experience and ensuring that an update
batch will only require one restart.
Many new WUS features, including pre-deployment reports and computer group
targeting, spring from the flexibility SQL Server has in storing and working
with update metadata. Note that WUS only works with SQL Server SP3 and later;
if you haven't installed SP3 on all SQL Server computers by this point you need
to hop on it, because that service pack contains a number of extremely important
— Don Jones
If you think Windows Update Services (WUS) is for you, you'll find installing
it is a straightforward proposition.
You'll be asked for a destination folder, and where you want to store updates.
The actual updates don't go into SQL Server, which acts as the WUS data store
(see "WUS Meets SQL Server"). You can either elect
to store them locally on the WUS server (plan to provide many gigabytes of free
disk space), or to not download them at all.
In the latter case, WUS will control which updates your clients install, but
the clients will physically download and install them from the Windows Update
site. This is a great option when your clients are connecting to you across
your WAN, such as through a VPN: They'll use the WAN bandwidth to find out which
updates to install, and their own bandwidth to acquire the updates. Unlike with
SUS, this is currently a one-time only decision: You can't change this selection
after WUS is installed, so choose carefully.
You can install WUS on Small Business Server (SBS), although you need to set
up a separate Web site for it. Installing WUS under SBS' Default Web Site or
Company Web site will result in an impossible-to-administer WUS server, because
SBS locks down so many settings on those sites. In the beta, WUS has a host
of other caveats regarding SBS that you should read up on before attempting
I did experience some grief during installation of Microsoft Data Engine (MSDE);
my server hard-locked and had to be restarted. The second time was the charm,
and I was rewarded with the main administration Web page.
WUS also needs IIS up and running, and allows you to select which Web site
it will install under. That's like a miracle; far too often, Microsoft products
just leap into the Default Web Site and it's practically impossible to move
them once they settle in. WUS allows you to set up a completely independent
virtual server; just be sure to do so before running Setup.
WUS servers must be running Win2K SP4 or Windows Server 2003. IIS 5.0 or higher
is required, as is IE 6 or later. Client computers also have some requirements:
Win2K is supported as of SP3 and later (although some of the documentation specifies
SP4 as the minimum); XP Pro and Windows 2003 are supported from RTM releases
If you're already running SUS or have deployed the latest Windows service packs,
you can point your clients (via Group Policy or Registry hacks) to your WUS
server, which will distribute the newest Automatic Updates client to them. Note
that the beta version of WUS requires you to specifically enable this self-updating
feature for clients. WUS also comes with an administrative template (ADM file)
that you can import into a Group Policy object to add the WUS policies; this
supersedes the ADM supplied both with SUS and Windows 2003.
— Don Jones