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

On computers running the RTM release of Windows 8 and Windows Server 2012, Windows Update no longer defined when to install updates. Instead, Automatic Maintenance is used for that purpose, minimizing activity during active computer use. Windows Update on Windows 8 and Windows Server 2012 computers also has new restart logic that defaults to forcing a restart 3 days after the installation of updates instead of 15 minutes. To avoid unintended data loss, forced restarts also no longer occur if a user is not actively using the machine, able to see the restart notice, and save their work.

While these changes have proven to be beneficial to many end users, the lack of discrete control over Windows Update installations and system restarts disrupted some management scenarios. This update returns the ability to discretely control when Windows Update installs updates, and adds the capability to force a restart soon after those installations regardless of whether there might be an active user session.

Microsoft has updated the documentation to more fully explain how you can use these new group policy settings. This documentation is available here: http://support.microsoft.com/kb/2885694

KB2885694, included in update rollup KB2883201, is available today (October 8^th, 2013) on Windows Update and the Microsoft Update Catalog, and will be available soon on WSUS. We believe that this update will result in significantly improved uptime, reliability, and manageability; we hope you’ll agree.

In order for the below changes to take effect, this update must be installed on all client computers receiving the desired configuration. It should also be installed on the computers configuring the policy to expose the new and updated group policies.

Finally, these updates are already included in the final versions of Windows 8.1 and Windows Server 2012 R2, so if you are already planning to upgrade, there aren’t any additional updates you need to install.

Thank you for sharing your feedback with Microsoft!

The Windows Update and WSUS teams

Changes introduced by this update

KB 2885694 introduces two main changes that define how Windows Update on Windows 8 and Windows Server 2012 computers can be configured using group policy. All policies mentioned are located at this path:

Computer Configuration / Administrative Templates / Windows Components / Windows Update

When enabled with a value of 4…

The Configure Automatic Updates group policy works identically to the Windows 7 / Windows Server 2008 R2 and earlier behavior.

On Windows 8 and Windows Server 2012 without KB 2885694 installed, that policy could configure the main automatic updating setting, but configuring the scheduled install day and time had no effect. After installing KB 2885694, the policy will enable you to configure machines to:

• Install updates during automatic maintenance, the default behavior, or
• Install updates at the scheduled day and time defined in the policy

A new group policy called Always automatically restart at the scheduled time enables restarts soon after updates are installed, instead of 3 days later

By default in Windows 8 and Windows Server 2012, if the installation of important updates requires a system restart, one will be forced 3 days after their installation. The restart timer begins counting down only when a user is able to see it, helping prevent unintentional data loss in the middle of the night. More details about this default behavior are discussed in this blog post.

If you would instead like to force restarts following update installation, similar to Windows 7 / Windows Server 2008 R2 and earlier, you can enable the new “Always automatically restart…” policy. When the policy is enabled, a restart timer will always begin immediately after Windows Update installs important updates, instead of multiple days later.

The restart timer cannot be postponed once started, but the policy lets you configure the countdown timer to any value between 15 and 180 minutes. When the timer runs out, the restart will proceed even if the machine has signed-in users.

Note: If the group policy No auto-restart with logged on users for scheduled automatic updates installations is enabled, then the new “Always automatically restart…” policy has no effect.

Note: In Windows 8 and Windows Server 2012, the Delay Restart for scheduled installations continues to have no effect.

Example configurations

This post was written by Jordan Cohen on behalf of the Windows Update team.

If you are managing updates for Windows Server 2012, you might have noticed that your WSUS server has been synchronizing a greater than usual number of updates these days. Windows Server 2012 is not only Microsoft’s most powerful, but also Microsoft’s most secure operating system to date. Since RTM, we’ve published dozens of updates that improve the security, reliability, and  functionality of Windows. Most notably, the Defender team has been publishing virus and malware definition updates 4 times a day, to ensure that your PC is never left unprotected from even the latest threats.

We’ve also added many new products to WSUS, including updates to Adobe Flash Player, Skype, Lync Server, and Office 2013. There are more WSUS updates than ever before.

All these updates certainly can take a toll on a WSUS server, especially on servers that have auto-approval rules. Many administrators were recently surprised to see that exporting updates from WSUS servers was failing, resulting in zero-size output files. It became clear to us rather quickly that the issue was due to a limitation in the CAB file format, which is an uncompressed file size limit of 2 GB.

I am pleased to announce that, as of today, a fix for this issue is available from Microsoft. An article describing how to get this update is available at:

• http://support.microsoft.com/kb/2819484 if you are running Windows Server 2012
• http://support.microsoft.com/kb/2828185 if you are running WSUS 3.0 SP2 (WSUS 3.2) on Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2

Many people have been asking on the forums and even through this blog for this fix for some time, and were wondering why it took more than 4 months to complete. To that end, I thought it would be interesting to share some of the engineering story as well.

One of the unique challenges of working on the WSUS team, compared to other server role teams in Windows Server, is that our role actually ships, “out-of box,” all the way back to Windows Server 2003 R2. We had to be very careful to design a solution that would work on all versions of Windows Server since then. To keep everything as simple as possible, we constrained ourselves on using compression algorithms that are already publicly available in the .NET framework or public Win32 API. Here is what we considered:

We decided it wouldn't be a great customer experience to require people to install .NET 4.5 on their servers. Plus, we wanted to preserve compatibility with Windows Server 2003 R2 if at all possible. .NET 4.5 is not available on Windows Server 2003 R2. We could have also adapted the CAB format to produce multiple output files, but we preferred to produce only a single output file, especially since the resulting files are comparatively small.  On systems running the latest version of .NET 4.0, the maximum file size is limited only by NTFS file size. While Gzip does store the length of the compressed content using 32 bits, the structure stores only the lowest 32-bits thereby allowing for larger file sizes, limited only by NTFS file size (prior to .NET 4.0, the length of the compressed content couldn’t exceed 32 bits, or about 4 GB). This does mean that there’s a limit of 4 GB on systems using .NET 3.5 (i.e., WSUS 3.0 SP2 (3.2) ). Windows Server 2012 is on .NET 4.5 and therefore not affected by the limit. Similar to CAB, GzipStream also includes built-in CRC error detection, which makes the export and import processes highly reliable. Best of all, the compressed output is generated on-the-fly, without the need for temporary uncompressed output files. This greatly decreases disk I/O and we found it reduces the time needed for import and export significantly.

Using our current export algorithm, the export process results in 2 files, a metadata.txt file and an update.cab file, which must be kept together. The CAB format archives these two files together. However, since Gzip is not an archive format, the end user would have needed to keep these files together manually. We would have preferred to produce only a single export file to ease distribution. Therefore, we changed the WSUS exported data XML schema to allow for both metadata and update data in a single compressed file.

In parallel, we also worked with our test engineers to formulate a test plan for the hotfix. Our test matrix is large, as we need to ensure that every supported version of Windows Server will be able to install this update. For Windows Server 2003 R2, that matrix is made even bigger by our support for both x86 and x64 architectures. We also worked with Customer Support Services (CSS) to gather validation data with regard to cases that were currently opened about this issue. And of course, nothing works perfectly the first time, and we’ve gone through several revisions to make sure that the latest WSUS update is more robust than ever!

At this point, we have a hotfix that we feel really good about releasing: well-informed by customer needs, developed by our esteemed software engineers, and thoroughly tested and validated. I hope that it will improve the experience of the many WSUS admins around the world, and I look forward to hearing your feedback about this update.

Thanks for being a valued Windows Server and WSUS customer!

The WSUS Team

Some customers have reported that update package for KB917013 was being deployed to WSUS clients without having approved the update for installation on their WSUS servers.   The original update release, released February 2007 as an optional update, was only applicable on systems which had a version of Windows Desktop Search installed. The recent update Revision 105, had the applicability logic expanded to be applicable to all systems regardless if a prior version of Windows Desktop Search was installed,  IF of course, approved in the WSUS Administrative UI or via Administrator-set auto-approval rules.

The initial update would have only been installed  if the update had been either auto, or manually approved, and if the applicability criteria was met on the client (that WDS was installed).  For some customers,  because the original update was approved for install,  but because of the previous applicability rules to apply only to clients which had WDS installed, the update was not actually installed. 

So what happened with this revision and why did it seemingly deploy itself to all systems in my environment?  WSUS by default is set to auto-approve update revisions to minimize administrative overhead and make sure distribution “just works”.  Keeping  in mind,  revisions are only titled as such, when metadata or applicability rules of an update package change, never the binaries.  Revisions are also of course only auto-approved via this setting, if the original update is approved.

With the expanded applicability rules, and the WSUS default setting to auto-approve new revisions, it may have appeared as if this update was deployed without approval.   The initial version of the update would have had to have been approved, and the “auto-approve revisions” option on (by default) in order for this revision to have also been approved and deployed.

To Recap:

• The initial February 2007 release had to be purposely checked/approved by WSUS admin s sfor distribution, because it was an Optional update. 
•  All subsequent metadata-only revisions to that WSUS admin approved February 2007 release would then also be automatically approved for distribution. 
• The initial February approval is retained throughout the life of the update, regardless of revision.

That said,  We will be tightening the criterea for Revisions so that auto-approval  of revision behaivors are more predictable and of similar scope as the originial approved update, as we appreciate the confusion this behaivor caused. 

Thanks as always for your feedback to make our product s and processes work for our customers.

Bobbie Harder

PM, WSUS

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.