Whassup with WSUS?

Considering a WSUS upgrade? You should.

By Greg Shields

09/01/2007

After what seemed like an eternity in beta, the long-awaited WSUS 3.0 upgrade
finally made it to market in early May. The good news is this full-point upgrade
to Microsoft's patch-management system adds a host of new and desirable features
that were missing from previous versions. Adding stability and scalability to
an already fully functional, no-cost tool further solidifies its place as an
enterprise patch-management solution.

Major UI Facelift
So what should you expect in this upgrade? First, Microsoft has completely eliminated
the much-maligned Web interface for configuring WSUS and replaced it with a
new interface based on Microsoft Management Console (MMC) 3.0. This means that
if you haven't upgraded your MMC, you'll soon be upgrading it on your management
workstation. You'll also need to download and install Microsoft Report Viewer
2005, because WSUS uses this tool for report generation.

The biggest benefit of moving to a client-server interface is the improvement
in speed. The long delays between clicks waiting for an interface refresh are
gone. Including the Report Viewer with the product increases its ability to
not only publish reports to the screen, but to also publish Excel and Acrobat
PDFs without requiring the full version of Acrobat. If manually creating reports
isn't your thing, you can now enable e-mail notification to send a regular status
report or a notification when new updates are available on a daily or weekly
basis.

Active Directory is still the primary mechanism for deploying client configuration
to workstations around the network. The administrative template file hasn't
changed at all. It still includes the same 12 configuration options that it
was released with back in Windows XP Service Pack 2.

The way systems are managed within the interface, however, is improved with
the new ability to add machines into multiple machine groups. Although the limitations
involved with using Group Policy as the group boundary still exist, you can
create multiple groups simply by listing them in the "Target group name
for this computer" setting of the "Enable client-side targeting"
policy. You can separate multiple machine names with a semicolon.

You can use this functionality to isolate special test groups for pre-deployment
patch testing. If your servers share multiple roles -- like a server that's
both a SQL Server and a Web server -- you can use a multiple grouping to deploy
role-specific patches to role-based target groups.

Adding machines to groups is great, but previous versions didn't flush out
old data. That functionality is now available through the Server Cleanup Wizard.
Built into this wizard is the ability to trim down a database by removing unused
updates and update files, as well as computers that no longer contact the server.
Another real benefit here is the ability to automatically decline any superseded
updates that meet a set of criteria. By automatically getting rid of these unnecessary
updates, the sheer amount of data under management becomes significantly reduced.

Some very useful new architectural designs are now available for large environments.
These environments may include lots of WSUS servers in lots of networks, or
where high availability is critical. The first option for large centralized
environments involves creating a WSUS Network Load Balancing (NLB) cluster for
the front-end WSUS servers and a SQL 2005 cluster for the back-end database.
In this configuration, any number of supported WSUS instances can share the
load of incoming client traffic while sending database requests to the back-end
SQL cluster. Even better is the movement of patch content files off each individual
WSUS server and onto a DFS share commonly available to all front-end WSUS servers.
Wrapping all this together with DFS replicas has the potential of creating a
complete system with no single points of failure.

Got roaming clients? Roaming clients like laptops have always been a pain because
patching them meant connecting to their home WSUS server over latent WAN links.
With version 3.0, you can configure DNS to work in a round-robin fashion, with
netmask driving clients to a local WSUS server regardless of their location.
This is done by configuring a single, fully qualified domain name that points
to multiple WSUS server IP addresses. Normal DNS round-robining would cycle
through the IP addresses in order. With netmask ordering enabled, though, the
DNS server will first return the IP address of the WSUS server in the same subnet.
If no WSUS server is available in the subnet of the client, the DNS server simply
returns another address. Though not a bomb-proof solution, it can help reduce
WAN traffic for updates for highly distributed networks with a WSUS server in
each subnet.

Smart Install, Easy Upgrade
When Microsoft began reviewing the wish list from the previous upgrade, one
wish that bubbled to the top was the need for a clean upgrade path. For each
of the previous upgrades, the upgrade process was complicated to the point of
being practically impossible. According to Joseph Dadzie, group program manager
from Microsoft, "Upgrade capability was one of our biggest goals with this
version. In 2.0, the migration was hard. You effectively had to do a new install.
But in 3.0, it's a straight upgrade. The administrator runs setup on the server
and the upgrade completes in-place with few hassles."

Previous upgrades for large deployments with dozens of WSUS servers were challenging
because of the lack of backward compatibility. Essentially this meant an enterprise
WSUS upgrade needed to occur all at once so downstream servers could continue
to talk with upstream servers. According to Dadzie, WSUS 3.0 servers have the
ability to interoperate with WSUS 2.0 servers. This means a large-scale upgrade
can occur more methodically, with upstream servers completing the upgrade first,
followed by those downstream.

Microsoft has also improved the initial install process, with a post-installation
wizard asking most of the necessary configuration questions like proxy, upstream
server, supported languages and update categories right at install time. This
includes a change to the initial processing of the update catalog. In previous
versions, the update catalog that includes patch categorization was static at
install. Until the WSUS server completed its first synchronization, that catalog
didn't include all the potential categories. As the category list aged, this
became a point of confusion for many administrators, some failing to realize
they needed to check the list from time to time to approve new update categories.
In WSUS 3.0, part of the installation includes a step where Microsoft Update
is contacted during the installation to bring down the update categories. This
lets you select the correct categories at install time.

Two new features exposed at install time help improve the speed and accuracy
of downloaded and installed patches. The first, a new feature called the Microsoft
Update Improvement Program, is similar to Microsoft Office's Customer Experience
Improvement Program. Where this optional feature can really help you is in notifying
Microsoft of which updates succeeded and which failed. This helps Microsoft
improve the patch creation process. Although many have shied away from providing
Office experience info to Microsoft, many will likely opt to send info on patch
failure.

The second new feature is a powerful change to automated synchronization timing.
With WSUS 2.0, you could choose the time of day when the daily sync would occur.
In 3.0, you can now also choose the number of synchronizations per day. With
this new option, a downstream server can synchronize with an upstream one-or
update.microsoft.com-as often as once per hour.

The
WSUS 'Big Red Button'

Interestingly,
Microsoft has added an option in System Center Essentials
called "Detect Software & Updates Now," which
has at least some of the capability you've always wanted in
your "big red button." But that capability still
hasn't made its way into WSUS.

For the rest of us, try double-clicking this script from
the console of a computer that's configured to obtain updates
from a WSUS server. It will contact the WSUS server, download
and install any approved updates, and then reboot.

Locking It Down
As with previous versions, some hardening of the WSUS server is recommended.
Three items in particular allow for a much better secured patch-management infrastructure
that protects against external attacks.

WSUS 3.0 can reconfigure the default TCP port 80 through which the clients
connect to the server. This is necessary in situations when the WSUS server
also functions as a Web server for other purposes. It's also a good idea in
general to help protect the infrastructure against TCP port 80 attacks. Consider
the situation where an exploit is currently active on your network that spreads
via HTTP. If your patching infrastructure relies on that common port to push
updates, you may not be able to successfully patch your infrastructure because
of the exploit. Changing the port number will preserve that capability in that
situation.

Adding to that is the ability to use SSL to encrypt patch metadata as it passes
between servers, as well as from server to client. This prevents an attacker
from sniffing metadata traffic as it passes through your network. Though actual
patch content isn't encrypted using this method, the important data about the
patches and your machines will be. However, there are some limitations of using
SSL in a WSUS deployment, so be careful before implementing.

Lastly, if your organization is concerned about rogue WSUS servers infiltrating
your environment, you can now configure server-to-server authentication. This
lockdown requires that all servers be a part of the same AD forest, or that
trusts exist between connected forests, but it can ensure your WSUS hierarchy
isn't hijacked by an unapproved WSUS instance.

A Few Omissions
Though this update includes a lot of great improvements that came specifically
from requests from you and your colleagues, there are a couple that didn't make
the list. Interestingly enough, although most of you live and die by what Microsoft
refers to as the MSRC number (e.g. MS07-001), Microsoft still lists most patches
in WSUS by title or Knowledge Base number (the six-digit number). You can right-click
the column header in the interface to add a column for the MSRC number, but
it appears to be impossible to include this information within the canned reports.

Also, to the chagrin of many, there's still no built-in "big red button"
functionality inside the UI. This "big red button" is a valued resource
to those who want the ability to instruct a specific machine to patch immediately
without waiting for its next scheduled time. According to Dadzie, that capability
is available through scripting exposure, but its continued omission from the
UI is a glaring oversight for a highly desired capability.

Fear not. Scroll up to the sidebar "The WSUS 'Big Red Button'" for
a script that you can run directly on a machine to instruct it to immediately
download and install any patches approved for it within the WSUS interface.

Notwithstanding the few missing items, most of you will likely be downloading
and installing the update pretty quickly. The install is trivial. Any upgrades
are easy. And the price is right for a home-run patch management system.

Microsoft updated an August security advisory this week to urge organizations using the Lightweight Directory Access Protocol in supported Windows systems to implement some configuration changes manually.