locked
gzip stream issue RRS feed

  • Question

  • I am having an issue when attempting to export updates from my WSUS.  My environment is a little unique compared to most.  I have WSUS 3.0 SP2 installed on 64-bit Windows Server 2008.  We have a single forward facing WSUS with an outside connection.  I should also mention upfront that upgrading my server to a newer OS and version of WSUS is NOT an option at this point in time so I need to make this work somehow. We use that to export updates using powershell with the following command:

    ./wsusutil.exe export E:\WSUS\Export_Cabs\export.xml.gz E:\WSUS\Logs\export.log

    We then copy the exported metadata to a removable drive and air gap it over to our WSUS on an isolated network and import the metadata.

    For the first few months after we implemented this WSUS installation, everything worked perfectly.  Then one day a couple months ago, I ran the export as I normally do but this time the export failed with the following error:

    "The gzip stream can't contain more than 4GB data."

    After researching potential causes/solutions, I came across KB2828185.  I checked my update history and it was previously installed far prior to encountering this issue.  At the time, I had .NET 3.5 and .NET 4.5.1 installed.  I have removed them and replaced them with .NET 4.0 and still receive the same error.  I am at my wits end on this.  Every solution I have found leads me to KB 2828185 but this does not fix the problem.  Anybody who can offer some advice or other avenues to explore would be greatly appreciated.

    

    Wednesday, July 30, 2014 5:47 PM

Answers

  • At the time, I had .NET 3.5 and .NET 4.5.1 installed. I have removed them and replaced them with .NET 4.0 and still receive the same error.

    The first question is whether you've actually configured WSUS to **USE** the .NET Framework v4.0 libraries. By default, WSUS v3 is a .NET v2 application and will use (natively) the .NET Framework v3.5 libraries, which do not support file sizes >4GB.

    Also, not sure if this is relevant or helpful but we are using WinZip 10.0(7245).

    Certainly a potential issue. The blog post is pretty specific about which compression algorithms were tested: GzipStream, DeflateStream, Zip64 -- which are all .NET-based algorithms.

    • Does WinZip 10 support any of those algorithms?
    • Is WinZip 10 a 64-bit application?

    Halt! WinZip *TEN*? The current version of WinZip is 15.5. WinZip 10 was released in 2006, long before the advent of serious 64-bit computing (except for the bleeding edge peeps running WS2003 x64 systems which was only released earlier that same year).

    And.. inasmuch as the ZIP algorithms have been built into the Windows operating system since Windows XP and Windows Server 2003, and WINZIP is a licensed product for commercial use, I'm somewhat intrigued that anybody would still be using a legacy instance of a 32-bit WinZIP application on a 64-bit system.

    So, here's where I'd start:

    1. Verify that WSUS is configured to use the .NET4 libraries.
    2. Confirm that WinZIP v10 isn't your root cause. For starters, it's almost certainly a 32-bit app which is possible cause #1, and second, it may be interfering with the ability of WSUSUTIL.EXE to use the native .NET libraries to do the compression. Uninstalling it would be the easiest way to achieve this. (You may still have to manually restore the native OS ZIP functionality.)


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, July 30, 2014 10:18 PM
  • The first question is whether you've actually configured WSUS to **USE** the .NET Framework v4.0 libraries. By default, WSUS v3 is a .NET v2 application and will use (natively) the .NET Framework v3.5 libraries, which do not support file sizes >4GB.
    This is the answer. The workaround is to write a .NET 4.x program that calls the Export command using the WSUS API.
    Thursday, July 31, 2014 9:34 PM

All replies

  • Also, not sure if this is relevant or helpful but we are using WinZip 10.0(7245).
    Wednesday, July 30, 2014 9:41 PM
  • At the time, I had .NET 3.5 and .NET 4.5.1 installed. I have removed them and replaced them with .NET 4.0 and still receive the same error.

    The first question is whether you've actually configured WSUS to **USE** the .NET Framework v4.0 libraries. By default, WSUS v3 is a .NET v2 application and will use (natively) the .NET Framework v3.5 libraries, which do not support file sizes >4GB.

    Also, not sure if this is relevant or helpful but we are using WinZip 10.0(7245).

    Certainly a potential issue. The blog post is pretty specific about which compression algorithms were tested: GzipStream, DeflateStream, Zip64 -- which are all .NET-based algorithms.

    • Does WinZip 10 support any of those algorithms?
    • Is WinZip 10 a 64-bit application?

    Halt! WinZip *TEN*? The current version of WinZip is 15.5. WinZip 10 was released in 2006, long before the advent of serious 64-bit computing (except for the bleeding edge peeps running WS2003 x64 systems which was only released earlier that same year).

    And.. inasmuch as the ZIP algorithms have been built into the Windows operating system since Windows XP and Windows Server 2003, and WINZIP is a licensed product for commercial use, I'm somewhat intrigued that anybody would still be using a legacy instance of a 32-bit WinZIP application on a 64-bit system.

    So, here's where I'd start:

    1. Verify that WSUS is configured to use the .NET4 libraries.
    2. Confirm that WinZIP v10 isn't your root cause. For starters, it's almost certainly a 32-bit app which is possible cause #1, and second, it may be interfering with the ability of WSUSUTIL.EXE to use the native .NET libraries to do the compression. Uninstalling it would be the easiest way to achieve this. (You may still have to manually restore the native OS ZIP functionality.)


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, July 30, 2014 10:18 PM
  • The first question is whether you've actually configured WSUS to **USE** the .NET Framework v4.0 libraries. By default, WSUS v3 is a .NET v2 application and will use (natively) the .NET Framework v3.5 libraries, which do not support file sizes >4GB.
    This is the answer. The workaround is to write a .NET 4.x program that calls the Export command using the WSUS API.
    Thursday, July 31, 2014 9:34 PM
  • Thank you both the the reply.  I have to say that I am in over my head here.  This is far beyond my experience level.  Is there a procedure out there for doing this or maybe some sample code to get me started?
    • Proposed as answer by BarberC Tuesday, June 14, 2016 11:00 AM
    Thursday, July 31, 2014 11:53 PM
  • Is there a procedure out there for doing this

    The two BEST approaches to this situation, before writing code IMHO, are:

    • Perform maintenance on the export server and try to get the export metadata <4GB. (REBUILDING the export server might even be a worthwhile adventure.)
    • Upgrade to WSUS v6 if you must support exports >4GB.

    But beyond that, I'm not aware of any procedures or sample code, but CodePlex would be your best friend at this point.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, August 1, 2014 3:19 AM
  • As previously mentioned, there is absolutely no chance of me getting approval to perform an upgrade of any kind at this point in time.  WSUS v6 would require upgrading to Windows Server 2012 which I am am definitely not going to be able to do anytime soon. 

    I think my only option is to run Server Cleanup Wizard to reduce the size of the export.  The problem with that is that there are 60 days worth of updates that I need to deploy on my isolated network.  The problem here is that if I run the cleanup wizard, anything older than 30 days will be deleted. and the two databases will not contain the same data.  It doesn't look like I have any other options here other than to scrap the WSUS and update manually unless I am missing something.

    Friday, August 1, 2014 10:25 PM
  • This is the answer. The workaround is to write a .NET 4.x program that calls the Export command using the WSUS API.


    We are not authorized to employ any locally generated code in our environment.  We have very stringent security measures in place that simply do not allow that so this option is off the table as well.
    Friday, August 1, 2014 10:40 PM
  • The only option I see right now is to run the server cleanup wizard.  Of course by doing so, I will lose 60 days worth of needed updates as everything older than 30 days will be deleted.  


    • Edited by selliott97 Friday, August 1, 2014 11:32 PM
    Friday, August 1, 2014 10:45 PM
  • As previously mentioned, there is absolutely no chance of me getting approval to perform an upgrade of any kind at this point in time.

    Then it would seem your limits are your limits. :-)

    I think my only option is to run Server Cleanup Wizard to reduce the size of the export.

    To be true, this would be the recommended activity even if you were going to upgrade! Because, while you surely don't want to export/import that content, neither do you want to replicate it to a new installation.

    The problem with that is that there are 60 days worth of updates that I need to deploy on my isolated network.

    You may find it more expedient to simply install a *NEW* instance of the connected server, and approve ONLY those updates you need to deploy.

    The problem here is that if I run the cleanup wizard, anything older than 30 days will be deleted. and the two databases will not contain the same data.

    This is absolutely not true, and it's this very misunderstanding that directly contributes to the overabundance of metadata being exported to begin with. The Server Cleanup Wizard only deletes TWO types of updates:

    • Updates that have been expired (and are NOT approved).
    • OLD revisions of any update (provided that the old revision is not approved).

    More to the point, the SCW will NOT delete anything that has been approved.

    Furthermore, running the Server Cleanup Wizard WILL NOT (CANNOT!) delete any update that *might* be installable on any system anywhere, because such updates would be NOT expired and NOT an old revision.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Monday, August 4, 2014 12:18 AM
  • This is absolutely not true, and it's this very misunderstanding that directly contributes to the overabundance of metadata being exported to begin with. The Server Cleanup Wizard only deletes TWO types of updates:

    It seems that I need to get a lot smarter on WSUS as I am relatively new to this.  The information on SCW is very misleading.  When you have the SCW window open to select which options you want to use, it specifically states that updates older than 30 days will be deleted.  Not in those exact words of course, but that is the gist of it.  I will run the wizard and see where I stand from there.  One thing is for sure, the management and maintenance of the server needs to be improved upon.  Our resident expert who installed the WSUS has since left and it has been passed on to me so it looks like I have some learning to do.  I will post an update if I continue to have problems after running the wizard.  Thank you for all of your help.

    Monday, August 4, 2014 7:25 PM
  • When you have the SCW window open to select which options you want to use, it specifically states that updates older than 30 days will be deleted.

    Well... no, actually it doesn't. :-)

    What it says is that it will delete updates that are

    • EXPIRED and have not been APPROVED for 30 days or more

    or are

    • OLDER update REVISIONS that have not been APPROVED for 30 days or more


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, August 5, 2014 11:33 PM
  • Did you find a resolution.  I am experiencing the same issue.  Thank you.
    Thursday, November 13, 2014 6:46 PM
  • Did you find a resolution.  I am experiencing the same issue.  Thank you.

    Resolution to what?

    My take on this conversation is that the O.P.'s limitations are a function of their marriage to Windows Server 2008 SP2 X64, ergo, there's nothing to resolve. They're stuck. By choice.

    But then, we discussed many issues in this thread. Perhaps it would be better to start a new thread and actually describe your issue, because if it is the *same* issue, then the same responses in this thread apply to you without change.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Sunday, November 16, 2014 6:30 PM
  • The two BEST approaches to this situation, before writing code IMHO, are:

    • Perform maintenance on the export server and try to get the export metadata <4GB. (REBUILDING the export server might even be a worthwhile adventure.)
    • Upgrade to WSUS v6 if you must support exports >4GB.

    But beyond that, I'm not aware of any procedures or sample code, but CodePlex would be your best friend at this point.


    Tried these first two options, without rebuilding the export server. I'm not opposed to doing a rebuild, but I am interested in trying to write the code for the WSUS API.

    CodePlex had nothing for me, any other ideas from anyone? Thanks.


    Monday, November 17, 2014 6:02 PM
  • Hey Lawrence,

    how do you configure wsus to use .net framework v4.0 libraries?

    Tuesday, December 30, 2014 9:30 PM
  • how do you configure wsus to use .net framework v4.0 libraries?

    Install WSUS v6 on Windows Server 2012 or Windows Server 2012 R2. :-)

    You don't actually configure WSUS to use .NET4, it happens as an aberration (resulting in a broken WSUS installation) when WSUS v3 is installed on a Windows Server 2008/2008R2 server that has .NET4 already installed, or when .NET4 is added to an existing WSUS v3 server and breaks the existing references to the .NET2/.NET30/.NET35 libraries.

    But with respect to the question of using the WSUSUTIL EXPORT compression algorithms that require the .NET4 libraries, the answer is found in Ben Herila's post on July 31st:

    The first question is whether you've actually configured WSUS to **USE** the .NET Framework v4.0 libraries. By default, WSUS v3 is a .NET v2 application and will use (natively) the .NET Framework v3.5 libraries, which do not support file sizes >4GB.

    This is the answer. The workaround is to write a .NET 4.x program that calls the Export command using the WSUS API.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, December 31, 2014 6:00 PM
  • Lawrence,

    can you give instructions on how to use WSUSUTIL EXPORT compression algorithms that require the .NET4 libraries, the answer is found in Ben Herila's post on July 31st.

    I've read that post several times and still can't do an export.

    It very clear that no one's know how to do it.

    v/r,

    newbieps

    Sunday, January 4, 2015 7:42 PM
  • can you give instructions on how to use WSUSUTIL EXPORT compression algorithms that require the .NET4 libraries

    On Windows Server 2012, install KB2819484 and use the syntax as described in the KB article.

    Ben's original WSUS Product Team blog post is at http://blogs.technet.com/b/wsus/archive/2013/04/09/problem-solved-the-wsus-export-bug.aspx


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Monday, January 5, 2015 6:12 PM
  • Lawrence,

    I have a w2008 r2 server running wsus 3.0 sp2.

    I read Ben's blog and I still don't understand on how to get the export.

    I'm still having the same issue "The gzip stream can't contain more than 4GB data".

    I do have the .net 4.5 installed as well as the hotfix for 2008 r2.

    There seems to be a lot of people with the same issue with no answer.

    Can you give a clear instructions for people who have 2008 r2 server on how to do the export. I'm sure a lot of people would benefit from it.

    v/r,

    newbieps

    Wednesday, January 7, 2015 6:37 PM
  • I have a w2008 r2 server running wsus 3.0 sp2.

    I read Ben's blog and I still don't understand on how to get the export.

    You have to write a PROGRAM to do it, and that program needs to be configured to use the .NET4 libraries.

    Otherwise, if this is a critical operational issue, I would say that the *best* solution is to upgrade to WSUS v6.3 on Windows Server 2012 R2 and retire your WSUS v3 server.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, January 7, 2015 10:00 PM
  • Quick solution (thanks Yuvaraj Tamil Mani):

    ==> Install .Net 4 on the WSUS server from http://www.microsoft.com/en-us/download/details.aspx?id=17851

    ==> Create a file named wsusutil.exe.config under "C:\Program Files\Update Services\Tools" folder.

    ==> Copy the following code in to the file

    ********

    <configuration>
       <startup>
          <supportedRuntime version="v4.0.30319"/>
       </startup>
    </configuration>

    ********

    ==> Run the export and it will complete even if the size is bigger than 4GB.

    ==> Once the export is done, remove the wsusutil.exe.config file.

    • Proposed as answer by chrisakasoup Friday, September 4, 2015 4:46 PM
    Wednesday, January 14, 2015 1:31 PM
  • ********

    <configuration>
       <startup>
          <supportedRuntime version="v4.0.30319"/>
       </startup>
    </configuration>

    ********

    Hmmm... or apparently you can force the existing WSUSUTIL.EXE to use the .NET4 libraries.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, January 14, 2015 8:56 PM
  • Thanks, this worked great on my w2k8r2 server.

    Chris

    Friday, March 13, 2015 5:22 PM
  • Quick solution (thanks Yuvaraj Tamil Mani):

    ==> Install .Net 4 on the WSUS server from http://www.microsoft.com/en-us/download/details.aspx?id=17851

    ==> Create a file named wsusutil.exe.config under "C:\Program Files\Update Services\Tools" folder.

    ==> Copy the following code in to the file

    ********

    <configuration>
       <startup>
          <supportedRuntime version="v4.0.30319"/>
       </startup>
    </configuration>

    ********

    ==> Run the export and it will complete even if the size is bigger than 4GB.

    ==> Once the export is done, remove the wsusutil.exe.config file.

    This actually worked for me, migrating from Server 2003 R2 32-bit.  What a pain this has been thus far...

    Anyway, here is what I did:

    Original blog article I found after .cab export wouldn't work: http://blogs.technet.com/b/wsus/archive/2013/04/09/problem-solved-the-wsus-export-bug.aspx#pi47623=2

    Follow-up blog article http://blogs.technet.com/b/wsus/archive/2013/04/16/update-solution-for-wsus-export-bug-is-now-available-for-wsus-3-x-sp2.aspx

    Conveniently (sarcasm), neither article mentions the syntax of the command is different from when you were trying to export as .cab.  Here is the command I ran:

    wsusutil.exe export export.xml.gz export.xml

    Still getting error: "Export failed to export updates. Please look at the log file for error details.
    Fatal Error: The gzip stream can't contain more than 4GB data."

    So, did exactly what Pavel posted, and it worked.  Note, you will need .net 4 or whatever installed on the server.  In my case, the difference in file size from the failure to the successful file is 199KB.  Really, that's all I was missing?

    Simply migrating WSUS yesterday has really turned into a big job.

    EDIT2 - If you get this error message when importing:

    ExpandCabinetToDirectory( location of .tmp file ): Not a cabinet (13) Import failed to import updates.  Please look at the log file for error details.  Fatal Error: Unable to uncompress package.

    Then you haven't installed the hotfix on the destination server on which you're trying to import the metadata.  Install the hotfix and run the import command again.  Here is what I ran:

    "%ProgramFiles%\Update Services\Tools\wsusutil.exe" import c:\export.xml.gz import.log
    I hope I'm finally done with this.
    • Edited by chrisakasoup Sunday, September 6, 2015 6:48 PM added information on import
    Friday, September 4, 2015 4:57 PM
  • Seems folks have beaten the wsusutil methods to death here so I'll propose two alternate solutions to mucking about with gzip:

    • Export the WSUS database via the native database utilities. For WIND, that's the MSSQL 2005 toolkit. If you're using an alternate DB, use the respective toolkit. Then import in the opposite way to the import server. It's worthwhile noting that this will override all computer groups and data,  synchronizations, update approvals, etc.
    • Copy the entirety of the export server to the import server network and do an online sync between the two systems. If the system is VM, export the VM as OVA and bring it over. If it's physical, make a Ghost or a P2V OVA.
    Friday, May 12, 2017 8:16 PM