Unable to import exported WSUS content RRS feed

  • Question

  • Hi TechNet forum,

    At a customer, we need to deploy several WSUS offline content sets into networks that have no internet connection. 

    Sounds really easy; create an empty WSUS server, connect it to an upstream server, gather and approve the required updates, export, import aaaand fail...

    We have about 350 required updates which generates about 6 GB of content. The metadata export must be in the xml.gz format as the uncompressed size exceeds the 2GB .cab limit. 

    The problem we encounter is that during the import, the approvals, get set, the metadata gets imported (which takes forever I might add), the content get's placed in the wsus\wsuscontent folder, but WSUS can't seem to 'see' the content. 

    We've opened up the console, checked the file-status and WSUS reports that the files still needs to be downloaded, all of them. If you look at the 'link' generated, it shows http://servername/content/xx/updatename.extention. Browsing to that exact URL, the server is able to download the file, so the server generates the correct file download location, but is unaware of its existence.

    We've tried to run the (get-wsusserver).ResetAndVerifyContentState() which get's the WID service ramped up, but it doesn't get WSUS to locate, or set a flag in its database that the content is available.

    Waiting for 3 days, a service restart or even the entire server reboot didn't get the service to find the files when they are in the right place.

    As per configuration, we don't download partial files, have a narrow product list, only one language and only the most important and critical classifications selected. Our uncompressed metadata file grows to about 9GB.

    What are we missing in our config that WSUS sometimes finds the content, and sometimes waits for it to be downloaded while it's already in the correct location?

    Is there a job or command we can execute other than the ResetAndVerify we already tried?

    Thanks in advance!

    Tuesday, November 6, 2018 11:12 AM

All replies

  • Hello,
    Check if "wsusutil.exe reset" works.
    I also find some post which have similar issues as you. Check if they are helpful for you.
    Hope above links are helpful and feel free to feedback if there is any update.
    Best Regards,

    Please remember to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 7, 2018 7:33 AM
  • Hello,
    I noticed that you have not updated the post for a while. Have your issue or question been resolved now? Or is there any update? Please feel free to feedback.
    Best Regards,

    Please remember to mark the replies as answers if they help.

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 9, 2018 2:58 AM
  • Hi Ray,

    These imports and exports take a lot of time, so it took me a while to set and reset some test environments...

    as for some (early) results:
    - BITS download limit removal: didn't help us
    - IIS and NTFS rights where exactly the same on source and offline machine
    - Using Windows Server Backup Tool to export and import the files and ACL's didn't do anything for us.

    To give some more background, we use a script that automates the metadata import and export (using the default tooling) and using a self-written tool to approve updates (making it a zero-touch deployment of WSUS).

    We created a new content set using less options (only security, definition, critical, rollup and service packs) which dropped the number of available updates from 11K to 3K. This resulted in a smaller import and export set and duration. This seems to work in our environment, but i'm afraid that if this number goes up over time, it's just delaying the issue...

    Another approach we tried (with success so far) is to copy the SUSDb files with the content files to another server, stop it's services (wsusserv and WID), transfer the files to the desired location and start the services up again. 

    The results so far are that new clients see updates and are able to update! so far so good! We, however, have no idea what new problems this might introduce to the environments... 

    As for import and export times, the whole process of "export", copy and "import" takes about 15 minutes depending on transfer speeds! A lot better than 20 hours.

    If you have any more information that helps, of if you advise against the copy method, I would like to hear about it so it can keep our environment secure.

    Thanks in advance and have a nice weekend ahead.

    Friday, November 9, 2018 5:16 PM