Beta Man

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.

Windows Update Services (WUS) 2.0
Version reviewed:
Beta 1

Current status:
In development—no new dates

Expected release:
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.

Good Grouping
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.

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

More Control
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.

What's Missing?
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).

All Your Betas are Belong to Us!

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

WUS Gets It Done
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.

More Information

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 security fixes.
— Don Jones

WUS Installation
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 an install.

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

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


comments powered by Disqus

Hot Resources

Subscribe on YouTube