We recently announced on the Microsoft Update Product Team Blog a set of changes made to the Windows Update Agent. In an effort to provide additional protection for our WSUS customers, we are releasing an update that enhances the security of Windows Update, the Microsoft Update (WU/MU) Client, and Windows Server Update Services. The update applies to WSUS 3.0 SP2, as well as the WSUS role running on Windows Server 2012 and Windows Server 2012 R2.

Improvements include further hardening of the infrastructure used by WU/MU client and the communication channel between WU/MU Client and Service. Additionally, the communication channel between WSUS and WU/MU service has been hardened. This update to WSUS also rolls up all prior updates.

Details on the changes to the WU/MU client can be found at KB 2887535.

Details and additional considerations for the update to WSUS can be found at KB 2938066.

Downloads

The following files are available for download from the Microsoft Download Center:

Marta Barillas also wrote a significant portion of this blog posting.

Some customers have indicated that some update files are not being downloaded by WSUS after approval, which results in those updates being unavailable to clients.

For an update to be offered to clients, the following needs to happen:

1. Update must be approved to a target group in WSUS.

2. Update files must be available; so if WSUS is configured to store content locally, the update files must be successfully downloaded by WSUS.

Check if WSUS is configured to store content locally

The setting is controlled by a checkbox in the WSUS console.

When this is selected, if the update files fail to download to WSUS, the update will not be offered to Clients even though it has been approved.

Troubleshooting when WSUS is configured to store content locally

First, check if WSUS is syncing from another (upstream) WSUS server. (We’ll refer to the upstream WSUS server as USS and the downstream WSUS server as DSS henceforth).

If WSUS is syncing from another WSUS server, verify that the USS has the update files available by looking in the content directory on the USS. If the update files do exist on the USS, make sure that the DSS has access to:

1. the WsusContent folder on the USS
2. the root folder of the DSS WsusContent folder

If files are missing because they were never downloaded; ensure that files are downloaded by the Upstream WSUS (USS) and retry the download of the files on the Downstream WSUS (DSS).

If files are missing because the update has been declined and Cleanup Wizard has deleted the files from USS; proceed to decline the update from the DSS as well.

Note that in a WSUS hierarchy the Cleanup Wizard is recommended to be run from the bottom to the top in order to avoid DSS requesting updates that are no longer available on the USS.

Instructions for using the Server Cleanup Wizard are available on TechNet.

If files are missing because somehow they got deleted (not through WSUS Clean Up wizard); run Reset on USS and after files are available, retry the download of the files from the DSS. Please note that resetting a WSUS server can be a time consuming operation, as the reset happens for all the updates.

In order to run Reset, run the following command as an administrator:
%SystemDrive%\Program Files\Update Services\Tools\WsusUtil.exe reset

For help information run:
%SystemDrive%\Program Files\Update Services\Tools\WsusUtil.exe help reset

If WSUS is syncing from MU (there is no USS), verify that the update has not been Expired; otherwise it means that the update is no longer available. To verify that the update exists, search for it in the Microsoft Update Catalog.

•  If the update is no longer available from MU, Decline the update from the WSUS.

•  If the update exists, verify that WSUS has access to the root folder of the WsusContent folder.

The WSUS Team

A fix is now available from Microsoft that resolves the issue where some computers that have the KB 2919355 update for Windows 8.1 and Windows Server 2012 R2 installed stop scanning against Windows Server Update Services 3.0 Service Pack 2 (WSUS 3.0 SP2 or WSUS 3.2)-based servers that are configured to use HTTPS and do not have TLS 1.2 enabled. Direct download links, installation instructions, and more information you can use to check if you’re impacted by this issue, are provided on the KB 2959977 page.

• If you manually imported KB 2919355 prior to the issue of KB 2959977, you should decline the old revision on your WSUS server. Once you decline the revision in WSUS, it will no longer be distributed to clients.

• For all users (even if your environment was not impacted), we recommend that administrators approve the latest revision of KB 2919355 for distribution to enable deployment of Windows 8.1 Update in your environment.

Update Monday 4/14/2014 - Please see http://support.microsoft.com/kb/2959977 for additional information.

There is a known issue which causes some PCs updated with the Windows 8.1 Update (KB 2919355) to stop scanning against Windows Server Update Services 3.0 Service Pack 2 (WSUS 3.0 SP2 or WSUS 3.2) servers which are configured to use SSL and have not enabled TLS 1.2.

Issue Description

The problem is specific to the following scenario when all of the following are true

1. Client PC has installed Windows 8.1 Update KB 2919355
2. Windows 8.1 with Windows 8.1 Update KB 2919355 attempts to scan against WSUS 3.2 running on any affected platform:
   • Windows Server 2003 SP2, or
   • Windows Server 2003 R2 SP2, or
   • Windows Server 2008 SP2, or
   • Windows Server 2008 R2 SP1
3. HTTPS and Secure Sockets Layer (SSL) are enabled on the WSUS server
4. TLS 1.2 is not enabled on the server

Only users who have enabled HTTPS and have not enabled TLS 1.2 on their WSUS 3.2 servers and who are also using these WSUS 3.2 servers to manage PCs running the Windows 8.1 Update KB 2919355 are affected by this issue. Please note, while we do recommend the use of HTTPS on WSUS servers, HTTPS and TLS 1.2 are not enabled by default.

Workarounds

If you are using WSUS 3.2 on Windows Server 2008 R2, you may perform either of the following steps to restore the scan functionality if you have deployed the Windows 8.1 Update KB2919355.

• Enable TLS 1.2 (follow the instructions under More Information > SCHANNEL\Protocols subkey), or
• Disable HTTPS on WSUS

If you are using WSUS 3.2 on an operating system other than Windows Server 2008 R2, you may perform the following step to restore the scan functionality.

• Disable HTTPS on WSUS

When Microsoft releases an update that resolves the issue, you may re-enable HTTPS on WSUS.

Microsoft plans to issue an update as soon as possible that will correct the issue and restore the proper behavior for Windows 8.1 Update KB 2919355 scanning against all supported WSUS configurations. Until that time, we are delaying the distribution of the Windows 8.1 Update KB 2919355 to WSUS servers.

You may still obtain the Windows 8.1 Update (KB 2919355) from the Windows Update Catalog or MSDN. However, we recommend that you suspend deployment of this update in your organization until we release the update that resolves this issue. You may also find the workarounds discussed in this article to be useful for testing this Windows 8.1 Update for your organization. Thank you for your patience during this time.

The WSUS and Windows Update Teams

Symptoms

• When installing WSUS through the Add Roles and Features Wizard (ARW), the Post-Installation task fails and the generated log folder (*.tmp) is empty, AND
• The Tools folder is missing after WSUS was installed. Note: By default, the Tools folder is installed to the following location: %SystemDrive%\Program Files\Update Services\Tools

This behavior has been seen when:

• Uninstalling WSUS
• Manually deleting WSUS folder: %SystemDrive%\Program Files\Update Services
• Manually deleting WSUS registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services
• Re-installing WSUS

Root Cause

When uninstalling WSUS Role via ARW the “API and PowerShell cmdlets” feature is not uninstalled by default (unless explicitly selected by the user). Deleting the remaining WSUS folders and registry keys leaves the server in a bad state and the re-installation fails because it is expecting this feature to be already installed.

Workaround

Uninstall all the WSUS roles and features and re-install WSUS.

Workaround 1: To uninstall WSUS roles and features using Windows PowerShell

1. In PowerShell, review features installed by calling: Get-WindowsFeature UpdateServices*
2. To remove features, call: Uninstall-WindowsFeature <featureName>

Workaround 2: To uninstall WSUS roles and features using the Server Manager Console

In Server Manager, launch Remove Roles and Features Wizard (RRW), unselect items to be uninstalled, and complete the Wizard:

1. In Server Roles tab unselect ‘Windows Server Update Services’ option
2. In Features tab unselect ‘Remote Server Administration Tools -> Role Administration Tools -> Windows Server Update Services Tools’ option

We recommend restarting the server to ensure that all WSUS components are removed. After uninstalling WSUS roles and features, you may reinstall the WSUS roles and features.

To reinstall WSUS, launch the Add Roles and Features Wizard and then select the “Windows Server Update Services” option. You may optionally reinstall the Windows Server Update Services Tools. After the ARW completes successfully, you may run the WSUS post-installation tasks.