none
Isolated WSUS Server Stopped Downloading

    Question

  • All,

    I am running WS 2003 R2, WSUS 3.0, and may have two separate problems.

    In late October, I had a problem where several files were not downloading though approved. It seems there were some files I had approved which did not exist in the WSUSContent directory. Once these had their downloads cancelled and were unapproved, the other updates downloaded, I was able to approve new content, these downloaded, and the Downloaded Status showed we had downloaded all the applicable files (Downloaded 52.89 MB out of 52.89 MB).

    Returning to the server this week, I migrated the data to a new volume through wsusutil movecontent.  I then added new content and imported this content through wsusutil, the Download Status showed there were ten GB of files not downloaded. I assume this meant previously approved files were missing and the process would not continue until these files were identified and unapproved for install. Using the "All Updates" view, I selected all "Approved" updates and selected "Cancel Download" but left them approved. The Download Status shows there are only 500 MB of missing files left to account for. However, new updates cannot be approved and their file status indicates they are missing even though they are there (tracked several down in the WSUSContent directory to make sure).

    There are 300+ files recently installed to the WSUSContent area, all with "file status" of "not present" but the file information shows the correct web path to the data. The permissions on all directories are consistent with allowing the NETWORK SERVICE to see the files through the DB to the filesystem. There are some differences between our test system (which works) and production system directory structure permissions, but nothing that seems to be causing the problem. We have a development system whose permissions are farther off than the test system and it operates correctly, also.

    Possible troubleshooting paths include doing a wsusutil movecontent to the original location and seeing if the problem persists. Please advise.

    Thanks,

    Jeff Copes

    Thursday, January 10, 2013 9:38 PM

Answers

  • Have you tried wsusutil reset command.

    With this command, you verify that every update metadata row in the WSUS database corresponds to update files stored in the local update file storage location on your WSUS server. If update files are missing or have been corrupted, WSUS downloads the update files again

    Friday, January 11, 2013 10:57 AM
  • From everything I'm reading here, this appears to be a classic export/import problem.

    Starting from the beginning, and assuming that the reason you're doing export/import is because this is a disconnected server... when a disconnected server queues files for download, that means that they were likely not downloaded to the connected server -- probably because they weren't approved on the connected server. Removing the approvals and deleting the BITS queue is an appropriate resolution -- but it doesn't address why the update was approved on the disconnected server in the first place.

    I see no indication that moving the content store with wsusutil would have any bearing on the current situation.

    You added new content, imported the metadata, and got the same problem -- update files for 10GB of updates (that's a LOT of content!!!). In fact, with 10GB of files missing, I would suspect that the WSUS server couldn't see anything at all in the ~\WSUSContent folder. This typically happens when the folder (WSUSContent) is copied to the new server, rather than the SUBfolder (WSUSContent\*), resulting in the ACLs of WSUSContent being corrupted. Either that, or you, once again, approved updates on the disconnected server that were never approved on the connected server (except this time a few hundred of them).

    Once again removing approvals and cancelling the download eliminates the problem -- but doesn't address the presumptive need for the updates in the first place.

    I recommend the following:

    1. Inspect the console of the connected WSUS server and verify that ALL approved updates have been successfully downloaded.
    2. While you're there, evaluate whether any of those approved updates are no longer needed. Decline the updates and run the Server Cleanup Wizard to delete the files from the content store.
    3. Repeat Step 1.
    4. Make note of the number of approved updates on the connected server.
    5. Ensure the BITS queue is completely empty on the disconnected server. On Win2003 use BITSADMIN /RESET /ALLUSERS.
    6. Copy the ~\WSUSContent\* folders to the disconnected server. Confirm that the number of files and space consumption is identical on both servers.
    7. Export/import the metadata.
    8. Approve updates. Verify that the number of approved updates on the disconnected server matches the number from the connected server.
    9. Confirm that no files are listed as needing to be downloaded. If there are, start over at Step 1. :-)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Saturday, January 12, 2013 1:16 AM

All replies

  • Have you tried wsusutil reset command.

    With this command, you verify that every update metadata row in the WSUS database corresponds to update files stored in the local update file storage location on your WSUS server. If update files are missing or have been corrupted, WSUS downloads the update files again

    Friday, January 11, 2013 10:57 AM
  • From everything I'm reading here, this appears to be a classic export/import problem.

    Starting from the beginning, and assuming that the reason you're doing export/import is because this is a disconnected server... when a disconnected server queues files for download, that means that they were likely not downloaded to the connected server -- probably because they weren't approved on the connected server. Removing the approvals and deleting the BITS queue is an appropriate resolution -- but it doesn't address why the update was approved on the disconnected server in the first place.

    I see no indication that moving the content store with wsusutil would have any bearing on the current situation.

    You added new content, imported the metadata, and got the same problem -- update files for 10GB of updates (that's a LOT of content!!!). In fact, with 10GB of files missing, I would suspect that the WSUS server couldn't see anything at all in the ~\WSUSContent folder. This typically happens when the folder (WSUSContent) is copied to the new server, rather than the SUBfolder (WSUSContent\*), resulting in the ACLs of WSUSContent being corrupted. Either that, or you, once again, approved updates on the disconnected server that were never approved on the connected server (except this time a few hundred of them).

    Once again removing approvals and cancelling the download eliminates the problem -- but doesn't address the presumptive need for the updates in the first place.

    I recommend the following:

    1. Inspect the console of the connected WSUS server and verify that ALL approved updates have been successfully downloaded.
    2. While you're there, evaluate whether any of those approved updates are no longer needed. Decline the updates and run the Server Cleanup Wizard to delete the files from the content store.
    3. Repeat Step 1.
    4. Make note of the number of approved updates on the connected server.
    5. Ensure the BITS queue is completely empty on the disconnected server. On Win2003 use BITSADMIN /RESET /ALLUSERS.
    6. Copy the ~\WSUSContent\* folders to the disconnected server. Confirm that the number of files and space consumption is identical on both servers.
    7. Export/import the metadata.
    8. Approve updates. Verify that the number of approved updates on the disconnected server matches the number from the connected server.
    9. Confirm that no files are listed as needing to be downloaded. If there are, start over at Step 1. :-)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Saturday, January 12, 2013 1:16 AM
  • Hi Lawrence,

    Thanks for your quick reply.

    Our procedure for providing WSUS updates to the isolated system changed from receiving the updates from an outside source on a hard drive to downloading our own on a WSUS Server. When I took over, the size of the update repository on the disconnected test and operational servers was 50 GB. I am not sure why it is so large, but regardless because it is the baseline I cannot reduce it size. With the updates requested, our new WSUS server is downloading 30 GB of data. In any case, the export and import locations will not be identical in size. I did, however, verify the increase in size to the isolated repository after the copy and import. Also, the updates for the connected server were approved and downloaded before the export and subsequent content copy. Once the approval was given, I was careful to make sure the content requested was downloaded to the server before doing an export and copy. But, you are right, the copy to the isolated server prior to import was done to W:\WSUS\WSUSContent rather than to W:\WSUS\WSUSContent\* 

    My troubleshooting today will be to mirror permissions of the source volume to the destination volume. We may also switch back to the source volume using wsusutil movecontent -skipcopy and start the move process over.

    In any case, I will check back here later to see if you think the way we are interpreting you comments is correct and to see if you think we are overlooking anything based on my feedback.

    Thanks,

    Jeff

    Monday, January 14, 2013 1:28 PM
  • Hi Adil,

    No, not yet. I was going to focus on file permissions first since there may be a mismatch there. I will try wsusutil reset, also.

    Thanks,

    Jeff

    Monday, January 14, 2013 1:31 PM