Problems installing Windows Server 2003 SP2 using automatic updates

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few days back, I noticed that I was unable to access websites as I had lost connectivity to my DNS server. When I checked the console, I found that my server had failed to install an update… Windows Server 2003 SP2 as it happens, which Windows Software Update Services (WSUS) had pushed out via the automatic updates mechanism. I restarted the machine and waited as it restored the prior configuration, running the software update removal wizard (at least it recovered cleanly), then waited as WSUS tried to push SP2 again. As the repeat update ran interactively, I found the problem – for some reason, towards the end of the installation, the following message was displayed:

Administrative Privileges Required

You must be an administrator of this computer to run this utility.

Log off, and then log on using an administrator account.

(even though I was logged on as the domain Administrator). After clicking OK, the installation continued before reporting:

Automatic Updates

You have successfully updated your computer.

You must restart your computer for the updates to take effect.

I’ve not seen any issues since the restart and the service pack seems to have applied successfully but checking the system event log reveals two entries describing the original problem:

Event Type: Error
Event Source: Windows Update Agent
Event Category: Installation
Event ID: 20
Date: 16/03/2007
Time: 06:00:19
User: N/A
Computer: servername
Description:
Installation Failure: Windows failed to install the following update with error 0x80242007: Windows Server 2003 Service Pack 2 (32-bit x86).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 57 69 6e 33 32 48 52 65 Win32HRe
0008: 73 75 6c 74 3d 30 78 38 sult=0x8
0010: 30 32 34 32 30 30 37 20 0242007
0018: 55 70 64 61 74 65 49 44 UpdateID
0020: 3d 7b 39 34 35 32 35 30 ={945250
0028: 33 43 2d 30 35 42 45 2d 3C-05BE-
0030: 34 41 36 34 2d 39 39 45 4A64-99E
0038: 44 2d 39 41 35 39 46 37 D-9A59F7
0040: 44 36 35 33 39 38 7d 20 D65398}
0048: 52 65 76 69 73 69 6f 6e Revision
0050: 4e 75 6d 62 65 72 3d 31 Number=1
0058: 30 34 20 00 04 .

Event Type: Error
Event Source: NtServicePack
Event Category: None
Event ID: 4374
Date: 17/03/2007
Time: 15:16:38
User: N/A
Computer: servername
Description:
Windows Server 2003 installation failed, leaving Windows Server 2003 partially updated.
The installation of the Service Pack did not complete, and a rollback to the pre-installation state has been initiated. A rollback is a two-step process. Step one is complete; to complete step two, click OK. To be reminded at next login to complete step two, click Cancel. After you complete the rollback, your system will reboot and you may retry the installation of the Service Pack.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

My other Windows servers seem to have updated without any problems; however this illustrates the risk of having WSUS automatically approve updates.

Migrating WSUS to a new server without downloading all the updates

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve spent the last day or so decommissioning my old domain controller, which also doubled up as a DNS, WINS, DHCP, print, RIS, anti-virus and WSUS server (okay… so a bit more than doubled up then!). Migrating Active Directory/DNS/WINS services was straightforward – it just involved setting up the new server, replicating the data, updating client settings (via DHCP) then removing the old services. DHCP was similarly straightforward (I’ve blogged before about migrating DHCP databases between servers) and RIS just needed to be installed on the new server, the images copied across, and the remote installation services setup wizard run. I recreated my single print queue manually but I could just as well have used the Microsoft Windows Server 2003 Print Migrator. That left just left my anti-virus management console (reinstall the console and reconfigure the clients) and WSUS.

I could just have installed WSUS, resynchronised with Microsoft Update and approved the necessary updates; however that would have involved downloading more than 10GB of updates (which could have taken my bandwidth usage for the month to a level that would result in my Internet connection being throttled under my ISP’s sustainable usage policy).

One potential WSUS migration option would have been to backup and restore the WSUS configuration but I wasn’t convinced about how that would work in a migration scenario involving a change of servername. Then I found a blog post from Nathan Winters about migrating WSUS between servers which helped me to import the content without going out to the Internet and downloading it again. Nathan suggests that the approvals database gets imported too, but that’s not the case – the wsusutil import command only imports the update metadata (not the file, approvals, or server settings). Similarly wsusutil migratesus migrates approvals from a SUS server (not WSUS) and wsusutil movecontent is for moving the content within the local file system. More details on managing WSUS from the command line can be found in the Microsoft Windows Server TechCenter.

By chance, I’d installed my new WSUS server as a replica of the original one so I could synchronise with the old server as my upstream source, leaving the new server with the content (from a a manual file copy followed by a metadata import) and the approvals information (from the synchronisation with the old server). All that remained was to finalise the server settings (synchronisation options etc.) and update group policy so that my clients went to the new server.

I hit a problem when I found that WSUS 2.0 doesn’t allow replica servers to be converted to standalone mode (that’s expected when WSUS 3.0 is released later this year), effectively preventing me from repointing WSUS to download updates from Microsoft Update. Luckily, Mohammed Athif Khaleel’s PatchAholic blog features a post on changing the mode of a WSUS server and a follow-up comment from SpJam includes a script to switch a server from replica to standalone mode (modified here to reflect subsequent comments):

rem Restore values after exec spEnableReplica stored procedure
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB UPDATE dbo.tbConfigurationA SET SyncToMU = ‘1′ UPDATE dbo.tbConfigurationB SET AutoRefreshDeployments = ‘1′ UPDATE dbo.tbConfigurationC SET ReplicaMode = ‘0′ UPDATE dbo.tbConfigurationC SET AutoDeployMandatory = ‘1′ UPDATE dbo.tbAutoDeploymentRule SET Enabled = ‘0′”

rem Add removed values in tables
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbTargetGroupInAutoDeploymentRule(AutoDeploymentRuleID, TargetGroupID) values (1, ‘A0A08746-4DBE-4a37-9ADF-9E7652C0B421′)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbTargetGroupInAutoDeploymentRule(AutoDeploymentRuleID, TargetGroupID) values (2, ‘A0A08746-4DBE-4a37-9ADF-9E7652C0B421′)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (1, 1)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (1, 5)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (2, 1)”
“%ProgramFiles%\Update Services\tools\osql\osql.exe” -S %COMPUTERNAME%\WSUS -E -b -n -Q “USE SUSDB Insert into dbo.tbUpdateClassificationInAutoDeploymentRule(AutoDeploymentRuleID, UpdateClassificationID) values (2, 5)”

It looked as if the script worked as advertised (except that automatic approval options were still not available) until I started to encounter the following error message when running reports or attempting to view update information:

Windows Server Update Services error

Error connecting to the Windows Server Update Services database
There was an error connecting to the Windows Server Update Services database. Either the database is not available or you do not have the correct privileges to access the database.

If you believe you have received this message in error, please check with your system administrator.

Click here to reload the site: Windows Server Update Services

Thinking that I had corrupted the database and that I might need to go back and start the WSUS migration from scratch, I decided to restart the server “just in case”. After the restart, everything seemed to be working (including the previously-missing automatic approval options). I’ve since approved some more updates and run various reports and (so far) there have been no problems administering WSUS.

The final step was to edit the group policy that I use to control automatic update options on my clients – a minor edit to change the server which clients should contact for updates.

So, to summarise, my WSUS migration process was:

  1. Install BITS 2.0 (a fully-patched Windows Server 2003 server should already have this).
  2. Install WSUS (in replica mode) and WMSDE.
  3. Export the update metadata on the old server using %programfiles%\Update Services\Tools\wsusutil export filename.cab logfilename.txt.
  4. Copy filename.cab (created above) and the contents of the WsusContent folder to the new server (e.g. using an external disk to network connectivity issues).
  5. Import the update metadata using %programfiles%\Update Services\Tools\wsusutil import filename.cab logfilename.txt (note that this takes a long time – it was just over three hours in my case).
  6. Synchronise WSUS with an upstream server.
  7. Save the script above as filename.cmd and execute it from the command line. The output will detail each command followed by the number of affected rows in the database.
  8. Reboot the server.
  9. Configure server settings (e.g. set Microsoft Update as the update source) and administer WSUS as normal.

I’d be interested to hear if anyone has any variations on this approach – for example, I don’t really recommend installing WSUS in replica mode and then hacking the database (and this wouldn’t be an option if there was any network segregation in place). Indeed, since I completed the exercise I found reference to a tool called WSUSMigrate which is part of the WSUS API samples and tools and can be used to migrate the approvals data – that looks like a much better approach.

Stay patched or face the hoards of giant man-eating penguins

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A couple of days back I published links to some funny Microsoft videos and now, on a related but slightly different note, I thought I’d highlight the work that Microsoft UK’s Steve Horne has been doing on machinama – it’s an interesting idea, using games 3D graphics engines to produce short films but check out Steve’s first production. You can read more about machinima on Steve’s blog.

Updating Windows Defender Beta 2 using WSUS

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last year I blogged that Microsoft were pushing updates to their Windows AntiSpyware Beta, to extend the expiry date past the end of July 2005. Since then, there have been a number of updates (including renaming the product to Windows Defender) and even though Windows Defender is included in recent Windows Vista builds, my XP clients have still been running Windows AntiSpyware Beta v1.0.701 (which expires at the end of July 2006).

That started to change tonight, when one of my XP machines updated itself to Windows Defender Beta 2, and although the product is now at v1.1.1347 (engine v1.1.1303.0), the definitions went backwards from update 5841 (5 May 2006) to a new definition numbering scheme (v1.0.0.0), dated 25 January 2006. Strangely, checking for updates reported that there were no updates available for download.

Microsoft knowledge base article 915105 describes an issue with Defender does not download updates but the resolution didn’t work for me; however, I did discover that Windows server update services (WSUS) now supports Windows Defender (Microsoft knowledge base article 915597 has more details of the update delivery mechanism).

After enabling Windows Defender updates in WSUS and synchronising, I found that there were three definition updates waiting for me to approve – v1.14.1408.8 (25 April 2006), v1.14.1410.10 (27 April 2006) and v1.14.1436.4 (3 May 2006). A few minutes later, checking for updates resulted in a successful download from WSUS.

Windows Defender seems to be in an extraordinarily long beta program (considering the original Giant Company product that Microsoft bought was so well regarded), but it seems pretty solid to me. Let’s hope that the US DOJ and the EU don’t force Microsoft to unbundle important security features like this from Windows.

Patching systems shouldn’t be this difficult

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

With tools like the automatic updates client and Microsoft Update, keeping a modern Windows system up-to-date is pretty straightforward.

For those who have a network of computers to manage there are additional tools, like the Microsoft baseline security analyzer (which helps to identify if any patches are missing) and Windows software update services (which keeps a local copy of Microsoft update on one or more servers on a network).

It’s just taken me over two hours to patch a single computer running Sun Solaris 10 x86. Like Microsoft, Sun provides tools that assist enormously in the process, but honestly – two hours! First I had to install the Sun update connection software, then once I’d launched Update Manager, there were 53 updates to download and install (and that was just security patches and driver updates – Sun restricts access to certain patches to organisations with a service plan). After a very long reboot (whilst some of these patches were applied), there were still 15 more updates (probably a subset of the original 53). Then a further reboot (shorter this time), and I was up and running again.

In fairness, Windows updates often require restarts and it can take several visits to Microsoft Update before a system is fully patched but this was ridiculous.

Next time someone tells me that patching Windows is too difficult, my response is unlikely to be empathetic.

Windows management technologies

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

At the Best of the Microsoft Management Summit 2005 event a few weeks back, Vlad Joanavic gave an overview of some of the “free” Windows Management technologies that are available (in addition to the “paid” products under the System Center brand).

These basically break down into:

  • Windows Software Update Services (WSUS).
  • Windows Management Instrumentation (WMI) and WS-Management.
  • Group Policy Management Console (GPMC).
  • Microsoft Management Console (MMC) v3.0.
  • Windows Installer v3.1
  • Microsoft Scripting Host (codenamed Monad).

The rest of this post discusses each of these in turn.

WSUS

WSUS is Microsoft’s update management offering for corporate customers, effectively allowing customers to host a local copy of Microsoft Update and to manage update approval accordingly. Free to licensed users of Windows 2000 Server and Windows Server 2003 (with appropriate Windows Server/core client access licenses) it is a core component of Microsoft’s patch and update management roadmap.

Unlike its predecessor, Software Update Services (SUS), WSUS supports more than just Windows updates, and allows selective targeting of computers based on group membership and automatic approval of updates (if required). It also uses a database rather than flat file storage for its configuration data (storage of the actual updates is still file-based) and offers a much richer user experience. At the time of writing, WSUS supports 8 types of update for a number of products (with more to be added over time). WSUS is also localised to provide for international support and has multi-language user interface (MUI) support.

WSUS does not require a new client component to be installed as the automatic updates client within Windows XP is self-updating. Most client functionality is implemented via a Win32 service with an extensible architecture for MSI, update.exe and driver handling and automatic updates can also be controlled via group policy.

WSUS servers uses the background intelligent transfer service (BITS) to ensure that the network is utilised effectively during the transfer of updates. Microsoft recognises a number of WSUS deployment options:

  • Single server – for small organisations or simple networks.
  • Multiple servers – for a large organisations or a complex network, allowing a hierarchy of WSUS servers to be created.
  • Disconnected network (e.g. on a ship), whereby updates are downloaded to one WSUS server and then exported for transfer via removable media (e.g. DVD) to a disconnected WSUS server which validates the Microsoft certificates on the content and services clients on the remote network.

WMI and WS-Management

WMI is the Microsoft implementation of web based enterprise management (WBEM)/common interface model (CIM), allowing access to over 600 WMI classes and 3000 properties. Provided as a standard Windows component since Windows 2000 (and downloadable for Windows NT 4.0), the number of WMI providers has grown from 15 in Windows NT to 29 in Windows 2000 and 80 in Windows Server 2003. WMI supports a variety of clients including the Windows Script Host (WSH), native C++ and managed code using any language supported by the Microsoft.NET Framework. It also supports command line operations (WMIC) and DCOM-based remoting.

The goal of WMI is to provide a single API for access to large volumes of system data. WMI providers expose data from content sources; this information is placed into a repository, and WMI consumers (e.g. applications and scripts) consume this data.

I previously blogged about web services (WS-*) and WS-Management is a joint effort to provide a WS-* protocol for interoperable management. Implemented as a web service, WS-Management is XML/SOAP-based and runs over HTTPS to access most existing WMI objects. WS-Management also allows for out of band access (i.e. when there is no operating system installed, or the operating system has crashed) to service processors (e.g. remote management hardware). In-band access provides a richer set of capabilities, specifically for software management.

The first version of WS-Management will ship as part of Windows Server 2003 R2, with access to hardware instrumentation, HTTPS access to Windows instrumentation and a command line functionality (WSMAN).

GPMC

I’ve blogged previously about the GPMC but even though it has been available for a couple of years now, it seems that many administrators still do not use it. I’m not sure why (I guess it’s because it is a separate download), but GPMC represents a huge step forward in the management of group policies and I find the ability to create XML/HTML-based group policy object (GPO) reports a significant advantage in documenting group policy (much better than trying to capture it in a set of Excel spreadsheets).

Many of the GPMC tasks are scriptable, including:

  • Creating/deleting/renaming GPOs.
  • Linking GPOs and WMI filters.
  • Delegation of:
    • Security on WMI filters.
    • GPO-related security on sites, domains and organizational units (OUs).
    • Creation rights for GPOs and WMI filters.
  • Generating reports of GPO settings and resultant set of policy (RSOP) data.
  • GPO backup/restoration/import/export/copy/paste/search.

MMC v3.0

MMC v3.0 (previously known as MMC v2.1) is intended to offer a number of benefits:

  • More reliable (recognising the issues related to loading third party code such as MMC snap-ins into a core process) through improved detection and reporting of snap-in problems and an ability to isolate hung snap-ins from the console (new snap-ins only).
  • Improved usability with an asynchronous UI model, simpler console customisation and discoverability of actions (including sub-panes providing actions for a selected tree node and item, along with a helpful description).
  • Richer snap-ins with simplified customisation, template-base snap-in design, and functionally rich views.

Windows Installer v3.1

Windows Installer (.MSI) v3.0 shipped with Windows XP service pack 2 (and v3.1 is the latest version, as described in Microsoft knowledge base article 893803). Whilst it does not support Windows 95, 98, ME or NT, Windows Installer offers:

  • Improved logging.
  • Scripting objects.
  • Sourcelist API enhancements.
  • Enhanced inventory API.
  • Command line switches.
  • Enhanced patching.
  • New software development kit (SDK) tools and documentation updates.

Microsoft Scripting Host/Monad

Monad is a new command shell for Windows, designed to address some of the problems associated with the existing Windows shell, i.e. a weak “language” and sporadic command line coverage, combined with a GUI that is difficult to automate. Monad provides command-oriented scripting capabilities for administrators and systems integrators, including an integrated shell, “commandlets”, new utilities and a scripting language. Wikipedia has a good description the MSH shell including links to additional resources.

Up and running with WSUS

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been meaning to upgrade my Software Update Services (SUS) installation to Windows Software Update Services (WSUS) for some time now, but the recent rebuild of my SUS server forced the issue.

I’m pleased to report that the WSUS installation was reasonably straightforward. Because I had already installed Windows Server 2003 SP1, there was no need to install BITS 2.0 or Microsoft.NET Framework v1.1 SP1 and I just needed to make the (Windows Server 2003) an application server (i.e. install IIS, enable COM+ for remote transactions, enable Microsoft DTC for remote access and enable ASP.NET) – all done through the Configure My Server Wizard (because I was feeling lazy). Installing WSUS was simply a case of following the setup routine (which included setting up the MSDE database).

Once installed, I set up the synchronisation schedule and performed a manual synchronisation (just to get things going). I also elected to automatically approve critical and security updates. The WSUS installation had automatically updated the Group Policy template file and because Active Directory already had the GPO settings for the previous SUS installation, it was pretty much configured, although I did need to amend the intranet Microsoft update server locations to include the custom port number (http://servername:8530) and enable client-side targeting for the All Computers group. The final steps were to select the products for which to receive updates and to approve updates for detection/installation.

That was it. WSUS up and running and clients receiving updates. My first impressions are that WSUS is slightly more complex than SUS was, but also more capable. I’m just waiting to get some real world experience with a hierarchy of update servers on a live network now!

Service packs, feature packs and releases – how they should work

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

The various Microsoft product groups issue service packs, feature packs and releases. This is all very well, but they mean different things to different people and are confusing. Then, last Friday, Paul Thurrott reported in the Windows IT Pro magazine network WinInfo Daily Update that Virtual Server 2005 SP1 will now become Virtual Server 2005 release 2 (R2). This might sound like a trivial name change but what it means for legal users of Virtual Server 2005 (a basically good product, but with a few fairly significant bugs), they will need to purchase R2, rather than install a free service pack.

If Microsoft follows this path they are going the way of Apple, who issue point version upgrades to their OS X operating system and have the audacity to charge existing users for a full product (there is no upgrade available).

In my opinion:

  • Service packs should fix bugs (security or otherwise) and that critical patches should be released in advance of a rolled-up, regression tested, service pack. Ideally service packs should also have a predictable timescale (e.g. 6 months after product release then every 12 months from then on until the product reaches end of life).
  • Feature packs should offer new features for an established product. I don’t believe that there should have been any additional features included with Windows XP SP2 (e.g. the Windows Firewall) – instead SP2 should have been a set of bug fixes (alleviating some of the deployment issues associated with new technology) and additionally Microsoft should have offered a free feature pack for Windows XP which provided the extra security features. In this way, users can stay at the latest supported product release (service pack level) but choose which feature packs to add. Security features and other important updates should be free of charge. Others which enhance a product might carry a small charge.
  • Mid-life releases (e.g. Windows Server 2003 R2) are all very well as a marketing mechanism for rolling the latest service packs into a product for new users, but should not preclude existing users from gaining from the latest service pack/feature pack updates. If a product really warrants a new licence, then it should carry a new (major) version number!

Following this model, Virtual Server 2005 R2 should really be a service pack and there should be an additional feature pack for the new features which Microsoft plans to ship (of which there are precious few details at present). As for supporting Linux as a guest operating system – it either works or it doesn’t – Microsoft needs to make up it’s mind as to whether it is a supported guest or not (if they are smart they will say “yes” – that way users can have a virtual Linux guest running on a Windows host if they need the best of both worlds, with Microsoft still gaining licence revenues for the host operating system and the virtualisation software).

One last patch for Windows 2000

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Windows 2000 mainstream support is due to end today and a couple of days back, as expected, Microsoft released update rollup 1 for Windows 2000 service pack 4. Full details of this update (including why it is not called Windows 2000 service pack 5) are included in Microsoft knowledge base article 891861 and the problems which it resolves are listed in Microsoft knowledge base article 900345.

I’ve been working with Windows 2000 since the late 90s, when it was NT 5.0 beta 2, and I guess I’ll still be using it for a while yet (as will many of my clients) but for a view on why 48% of corporates are still using Windows 2000, see my decision time for Windows 2000 users post from a few days back.

First SUS, then WUS, now WSUS (or is it MUS?)

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

The SUS/WUS name debate continues…

Today I received notification from Microsoft that the Windows Server Update Services (WSUS) release candidate (RC) is now available. Microsoft’s e-mail to participants of the WSUS open evaluation program (OEP) reads:

“We are pleased to announce that the Windows Server Update Services (WSUS) Release Candidate (RC) released today, Tuesday March 22! The Release Candidate of Windows Server Update Services (WSUS), formerly Windows Update Services (WUS), includes new features such as:

  • Replica mode for WSUS server hierarchies, making them easier to manage.
  • SSL connections between WSUS servers and clients, providing an even more secure end-to-end environment.
  • Automatic Update policy to allow non-administrators to receive update notifications, offering greater flexibility in organizations where logged on users are commonly not administrators.”

Thomas Lee notes that “the name is still a curiosity and WSUS appears to fall a bit short of earlier promises in that no SQL or Exchange updates seem to be supported, it’s an important step on the road on the path to a better patch experience for users”.

Further details of the WSUS RC can be found on the Microsoft Update Services (MUS?) website.