Whassup with WSUS?

Considering a WSUS upgrade? You should.

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.

Figure 1
[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.

Figure 2
[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 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.

Oh, and you're welcome.

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

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)

If intUpdateCount = 0 Then
 Set objDownloader = objSession.CreateUpdateDownloader()
 objDownloader.Updates = objUpdatesToDownload

 Set objInstaller = objSession.CreateUpdateInstaller()
 objInstaller.Updates = objUpdatesToDownload
 Set installationResult = objInstaller.Install()
 Set objSysInfo = CreateObject("Microsoft.Update.SystemInfo")
 If objSysInfo.RebootRequired Then
  Set objWMIService = GetObject _
  Set colOperatingSystems = objWMIService.ExecQuery _
  ("Select * from Win32_OperatingSystem")
  For Each objOperatingSystem in colOperatingSystems
 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.

comments powered by Disqus

Reader Comments:

Tue, Mar 22, 2011 Deepak

missing a comma between impersonate and (Shutdown) ...impersonate,(Shutdown)...

Fri, Jul 23, 2010

Run via cscript.exe filename.vbs Some reason when runnning it as cscript filename.vbs, it doesn't work.

Fri, Aug 7, 2009 dstonier

<3 Works beautifully.

Sat, Sep 15, 2007 Greg Shields Contributing Editor, Redmond Magazine

Hi all -- There's always some concern with posting code as part of an article! I know the code is correct now, as I've gotten emails from people who have thanked me for it. So, for those who are still having problems, please drop me a line at Send me a .TXT file of your script and I'll see if I can figure out what has gone wrong with it. Make sure of two things before you send: First, that you're not inappropriately doing a line wrap anywhere. Second, that you haven't changed "straight double quotes" with "curly double quotes". This second one is a code killer! If you're still having problems, drop me a line. Thanks!

Fri, Sep 14, 2007 Patrick Anonymous

I keep getting the following error:
Line: 8
Char: 1
Error: 0x80244021
Code: 80244021
Source: (null)

Fri, Sep 14, 2007 Brad Anonymous

Sorry, doesn't seem to be working quite yet. I'm getting error on line 5, char1, code 8024a000 using the script posted above. Anyone know what needs to be changed?

Fri, Sep 14, 2007 Brad Anonymous

And by line 5 i meant line 4

Sun, Sep 9, 2007 Jorge Lisbon

Brilliant! 5 star job!

I don't know how much you pay this gentleman (Greg Shields), but it´s not enough.

I wish all the articles I read would be so up-to-date,
clear, concise, and complete as this one.

Keep up the (extraordinary) good work.

Best Regards

Jorge Fernandes
MCSE 2003:Messaging

Thu, Sep 6, 2007 Becky Nagel Editor,

Hi Guys -- Just reposted, should be fixed now. Please let me know if you have further problems by posting here or e-mailing me at Thanks.

Wed, Sep 5, 2007 Becky Nagel Editor,

Hi guys -- sorry for the formatting errors you're encountered! We'll try to get them fixed ASAP.

Wed, Sep 5, 2007 Rick Chicago

The script is 37 lines long including empty lines. Number of lines in each paragraph between empty lines- 4, 4, 7, 6, 3, 8. Formating the script this way should make it work for you if you refomat it correctly.

Tue, Sep 4, 2007 Chris Anonymous

D'oh. I got it working. You just need to bump line 3 up to line 2 and fix the format of everything. You'll get 4 or 5 more errors of the same type. Just do the same thing for those lines. It looks like the way it's posted here is shortening the lines a bit. Notepad doesn't know how to act.

Tue, Sep 4, 2007 Anonymous Anonymous

I'm having the same problem. Did you ever find a solution?


Fri, Aug 31, 2007 Jon Anonymous

I am having problem with your Big Red Button script. I copied it into notepad and saved it as BigRedButton.vbs. When I run it, I get this error:
Line: 2
Char: 27
Error: Syntax Error
Code: 800A03EA
Source: Microsoft VBScript compilation error

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.