An update to WSUS 3.0 SP2 on Windows Server 2008 R2 and Windows Server 2008 (both x64 and x86) seems to break Windows Server Update Services (WSUS) and/or Internet Information Services (IIS) making clients unable to update via WSUS showing error 0x80072EE2.

To me, the subversive update number is not clear yet. So, if you know for sure the exact update that does this, please comment.

On the surface at least, the server looks OK: It synchronizes with upstream Microsoft servers, displays newly-published updates, approves and declines as been told, and downloads approved updates flawlessly.

But deep inside the WSUS server, things are a mess: The WSUS server is the only computer that can get updates from itself, it cannot communicate with clients, and after a few days, all computers—except for the WSUS server itself—are listed as This computer has not reported status for X or more days.

Further investigations reveals clients (ranging from Windows XP to Windows 7 and Windows 8) fail to update showing

Windows could not search for new updates
An error occurred while checking for new updates for your computer.
Error(s) found:
Code 80072EE2
Windows Update encountered an unknown error.

Windows Update error 80072ee2 generally refers to a problem with your firewall exceptions or “allow” list, but if you’re using your local WSUS, then it’s not a simple case of limited access to update.microsoft.com.

Visiting Event Viewer Custom Views for Server Roles, or hitting the Roles’ list collapse sign (plus sign inside the square) on Server Manager and looking into each role’s events, you’d be surprised to see there’s no recent events or perhaps no events at all listed for Web Server (IIS). This shows that IIS and its pipings are broken and client computers cannot communicate with the server. Another symptom and a confirmation of the broken IIS hypothesis is a selection of the following warning and error events listed for Windows Server Update Services:

Level	Event ID	Description
Error	12002	The Reporting Web Service is not working.
Error	12012	The API Remoting Web Service is not working.
Error	12022	The Client Web Service is not working.
Error	12032	The Server Synchronization Web Service is not working.
Error	12042	The SimpleAuth Web Service is not working.
Error	12052	The DSS Authentication Web Service is not working.
Warning	13001	Client computers are installing updates with a higher than 10 percent failure rate. This should be monitored.
Warning	13002	Client computers are installing updates with a higher than 25 percent failure rate. This is not normal.
Error	13042	Self-update is not working.

To fix this, you need to reinstall WSUS and IIS roles preserving the data.

1. Backup and Delete SUS Database and Preserve WSUS Update Files

Use SQL Server Configuration Manager to stop the SQL Server (MSSQLSERVER) service. Backup the SUSDB database files in SQL data folder (MSSQL\DATA\SUSDB.mdf and MSSQL\DATA\SUSDB_log.ldf) in a backup folder. Use SQL Server Management Studio to connect to the SQL Server and delete the SUSDB database.

Rename the WSUS content data folder to WSUS.bak. Unlike the SQL step, there’s no need to stop the Update Services service prior to manipulation.

2. Remove WSUS and IIS Server Roles

Open Server Manager and remove Web Server (IIS) and Windows Server Update Services roles. When asked for, leave the check boxes clear for the removal of WSUS database, log files and downloaded update files. Restart the server.

During the installation of WSUS 3.0 SP2, the Server Manager on Windows Server 2008 [R2] actually looks for Windows Server Update Services 3.0 SP2 Dynamic Installer for Server Manager [x64 Edition] (KB972493), but the update server is normally configured to receive updates from itself, and there’s no itself—functioning at least—for the moment. So, when it tries Searching for updates… it’ll show the following error:

Installation failed
The update could not be found. Either the update is not applicable to this computer or the update no longer exists. Verify that the update still exists and is applicable to this computer from your WSUS server or Windows Update.

To give your server a chance at receiving updates—including Windows Server Update Services 3.0 SP2 Dynamic Installer for Server Manager [x64 Edition] (KB972493)—through Microsoft’s website, temporarily disable intranet Microsoft update service location:
Edit the Default Domain Policy in Group Policy Management, open Computer Configuration ► Policies ► Administrative Templates ► Windows Components ► Windows Update ► Specify intranet Microsoft update service location, take a note of your server’s custom URLs (e.g., http://server:8530) for the following fields

• Set the intranet update service for detecting updates
• Set the intranet statistics server

and set it as Not Configured. Now open Command Prompt and run gpupdate /force to tell Windows to forcibly re-apply GP settings.

3. Add WSUS and IIS Server Roles

Open Server Manager and add Web Server (IIS) and Windows Server Update Services roles. Configure WSUS 3.0 SP2 installation and finish Add Roles Wizard. When asked for, leave the Begin initial synchronization checkbox unchecked, since everything’s going to be replaced with the backup. Also, based on the same principle, when choosing Products and Classifications, pick a single product with fewest updates possible (e.g., Silverlight).

Windows Update now recommends the installation of Update for Windows Server Update Services 3.0 SP2 [for x64-based Systems] (KB2720211). It’s a 28 MB download from Microsoft servers if you’re curious. You can update it online, or do it later via your local update server—once it’s back online.

Use SQL Server Configuration Manager to stop the SQL Server (MSSQLSERVER) service. Replace SUSDB.mdf and SUSDB_log.ldf files from backup. Rename WSUS.bak folder to WSUS and restart the Windows Server. Edit the Default Domain Policy and set update server URLs to what they have originally been (e.g., http://server:8530) and forcibly re-apply GP settings using gpupdate /force. You’re good to go.