In-Depth

Whassup with WSUS?

Considering a WSUS upgrade? You should.

• By Greg Shields
• 09/01/2007

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.

[Click on image for larger view.]

Figure 1. WSUS 3.0's new MMC console includes easy-to-read graphs on update status.

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.

[Click on image for larger view.]

Figure 2. Strangely missing from previous versions, WSUS 3.0's Server Cleanup Wizard can now remove old data.

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.

Set fso = CreateObject("Scripting.FileSystemObject")
Set objAutomaticUpdates = CreateObject("Microsoft.Update.AutoUpdate")
objAutomaticUpdates.EnableService
objAutomaticUpdates.DetectNow

Set objSession = CreateObject("Microsoft.Update.Session")
Set objSearcher = objSession.CreateUpdateSearcher()
Set objResults = objSearcher.Search("IsInstalled=0 and Type='Software'")
Set colUpdates = objResults.Updates

Set objUpdatesToDownload = CreateObject("Microsoft.Update.UpdateColl")
intUpdateCount = 0
For i = 0 to colUpdates.Count - 1
 intUpdateCount = intUpdateCount + 1
 Set objUpdate = colUpdates.Item(i)
 objUpdatesToDownload.Add(objUpdate)
Next

If intUpdateCount = 0 Then
 WScript.Quit
Else
 Set objDownloader = objSession.CreateUpdateDownloader()
 objDownloader.Updates = objUpdatesToDownload
 objDownloader.Download()

 Set objInstaller = objSession.CreateUpdateInstaller()
 objInstaller.Updates = objUpdatesToDownload
 Set installationResult = objInstaller.Install()
		
 Set objSysInfo = CreateObject("Microsoft.Update.SystemInfo")
 If objSysInfo.RebootRequired Then
  Set objWMIService = GetObject _
  ("winmgmts:{impersonationLevel=impersonate(Shutdown)}!\\localhost\root\cimv2")
  Set colOperatingSystems = objWMIService.ExecQuery _
  ("Select * from Win32_OperatingSystem")
  For Each objOperatingSystem in colOperatingSystems
   objOperatingSystem.Reboot()
  Next
 End If
End If

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.