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:
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:
Unlimited, 4 GB prior to .NET4
Built in CRC
Results in 2 files
No support for signtool
Unlimited, not available until .NET4
Supports larger file sizes than CAB
Results in 2 files, harder to work with raw DEFLATE format vs. Gzip, no support for signtool
2 GB uncompressed file limit
Same file format
Supported by signtool
Temp files needed (extra disk I/O), 2 GB limit per uncompressed file
No CLR support for Windows Server 2003 R2; no support for signtool
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
Explanations into why decisions were made the way they were are always appreciated.
What cought my eyes was a part of the second chapter:
"We’ve also added many new products to WSUS, including updates to Adobe Flash Player"
I looked in the products and cannot find anything added from Adobe, did I miss it?
@Ase, Updates to Adobe Flash are available under the Windows 8 and Windows Server 2012 categories. They apply only to Windows 8 and Windows Server 2012 machines.
>Any update to the WSUS 3.0 SP2 Patch?
@SCC, @Jay, Check back later today or tomorrow!
Thanks for your fast reply Ben,
I am still staying with Win7 on the workstations, but servers are 2012 but I do not think that have any flash installed, trying to keep them as clean as possible. Should updates for flash just appear under "All Updates" If I have the checkmark on Windows Server 2012 Product and all Classifications selected?
Servers will not have Flash installed unless you install the Desktop Experience feature, which is not installed by default. If Flash is installed via Desktop Experience, it will automatically be kept up-to-date via Windows Update.
Why not Windows 7 as well?
>Why not Windows 7 as well?
The answer to that, unfortunately, would need to come from Adobe and/or the IE or Windows Client teams. But I would encourage you to ask them if they have a blog.
I am presently managing WSUS 3.0 SP2 (Windows Server 2003) on a disconnected network, which involves exporting updates and metadata from a WSUS server on a connected network and then importing all that information into the WSUS server on the disconnected network.
Presently, I have successfully installed the hotfix on the export WSUS Server and have exported the GZIP file. But may I ask whether there is a need to install this Hotfix to the import server as I am receiving the following error message: "There is a problem with this Installer package. A problem runs as part of the setup did not finish as expected. Contact your support or package vendor", after installing it...
Yes, the hotfix needs to be installed on the import server as well, or else the code that reads the new file format will not be available.
I apologize. Just read an article elsewhere that states to run: wsusutil.exe export export.xml.gz export.log
I am trying this now. Hope this works. Thanks for the information. Much appreciated.
Hello, I greatly appreciated your explanation, but unfortunately, have run into several problems applying this patch.
I have two questions….
We have a WSUS server connected to the internet, that then patches are provided to 7 disconnected networks we manage.
We had a CAB file that was zero, so I applied patch KB2828185 to the connected server with no problems, and the export.xml.gz was created successfully.
When I installed KB2828185 on two of the disconnected WSUS servers (Windows 2008 SP2, 64-bit and Windows 2008 SP2, 32-bit), we got the same error
"An error occurred during the installation of assembly. Microsoft.UpdateServices.Utils,fileVersion ="3.1.7600.262" ,version="3.1.6001.001" ,culture="neutral" ,publicKeyToken="31BF3856AD364E35" ,processorArchitecture="MSIL". Please refer to Help and support for more information.
What can be done? I believe that installing KB2828185 on the two disconnected networks (one 64 bit, one 32 bit) under the cover installed KB2720211. KB2720211 was the nightmare of all nightmare costing my company at least 100 hours trying to recover.....requiring reinstalling WSUS on each network and making sure KB2720211 did not touch our network.
Question 2) once installing KB2828185….is it possible to export a CAB file?
1) All WSUS 3.x patches are cumulative, so installing KB2828185 would have included all updates prior to that KB. This is clearly stated on the KB page. I'm not sure what the solution to that fileVersion problem is right now, but I would encourage you to post on the forums for help from our MVPs or open a case with Support who can look into this in your specific situation.
2) Yes, even after installing the KB you can still export a cab file by specifying a filename ending in .cab. That code path remains unchanged and the 2 GB limit still applies.
Can someone point me to where I can ask for help troubleshooting my WSUS 6 Windows Server 2012 Standard installation that suddenly went belly up?
@Chauncey, the WSUS forum is the best place. social.technet.microsoft.com/.../threads
This problem is not solved for me. After applying the update, I receive the following error.
I find the error peculiar, because the error occurs after the file reaches 495 MBs, far shy of 4 GBs.
Do you have any ideas?