none
WSUS - The server is failing to download some updates RRS feed

  • Question

  • Hi All,
     
    My SBS2008 box has started giving me the following errors:
     
    Event ID 364:
     
    Content file download failed. Reason: CRC verification failure. Source File: /msdownload/update/software/secu/2011/05/sqlserver2008r2-kb2494088-x86_fa374a8423a87502e4a038a0024b1c95a998612e.exe Destination File: C:\WSUS\WsusContent\2E\FA374A8423A87502E4A038A0024B1C95A998612E.exe.
     
    This is followed by another evend, ID 10032, which says 'The server is failing to download some updates'.
     
    This second event occurs about 20 minutes after the first one.  The whole cycle happens approximately every 6 hours, and has started in the last few days.
     
    Any ideas?
     

    Thursday, July 7, 2011 8:06 AM

All replies

  • hey BT, there's an issue with large downloads and the crc/cab check. (and any SQL download is probably large)

    I'll look around for the KB, but maybe somone else can chime in.

    Friday, July 8, 2011 4:14 AM
  • Hi SG,

    Thanks for your reply.  My WSUS  has been working perfectly for almost 2 years, and this is the first problem of this kind I've had.  So I don't want to 'cludge' around, not really knowing what I'm doing. 

    Also, I did quite a lot of looking around before I posted this question (I hate it when people don't bother to do any research themselves), but I can't find any clues as to how to go about troubleshooting / fixing this problem.

    Maybe I should cross-post it to the WSUS forum?

    Friday, July 8, 2011 5:49 AM
  • There is one article I can find that shows some troubleshooting steps.  But the SBS box needed a reboot after some updates anyway, so I will wait and see if perhaps that clears it up.

    Here is the article:

    http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=.NET+Framework&ProdVer=2.0.50727&EvtID=364&EvtSrc=Windows+Server+Update+Services&LCID=1033

    This essentially involves restarting the BITS and WSUS services, and forcing a re-sync.  Re-booting will do that anyway. (not sure about the re-sync, but time will tell...)



    Friday, July 8, 2011 7:06 AM
  • Restarting the server did not solve the problem.  Interestingly, in the WSUS Synchronization history, there are no failures.  The only side-effect is that my SBS Console is showing up missing updates (and I'm getting errors in my reports).  In the WSUS console, they show up as "Approved", but show that there was an error downloading them.

    I have narrowed the problem down to 4 updates that won't download, so I noted the KB number of each, and declined them in the WSUS console.  After that, they do not show up as missing in the SBS Console, and I should stop getting the error messages.

    Now I need to download those KB's manually, and apply them.

    I forced the issue because WSUS has repeatedly tried to download these same 4 files, and failed, every approx. 5 hours since the 3rd, that's 5 days.  If the error were transient, I would leave it alone, and this is the first time I've had to meddle with WSUS.  I hope it's the last!

     

    Friday, July 8, 2011 1:04 PM
  • This thread has become like my private blog!  Having done the above, Windows Update Services logged the event "All updates are downloading successfully", so I went to bed with a warm feeling.  However, I had in the meantime approved some more updates, and this morning, different updates were failing to download.

    So, my problem is ongoing.  I have been advised by someone in the WSUS forum to clear my ISA cache, and this I have done.  Am hoping this will fix it.

    Saturday, July 9, 2011 7:17 AM
  • low on space on _any_ drive?
    Saturday, July 9, 2011 7:39 AM
  • Nope.  The server has 5 x 146GB SAS drives in RAID5, giving me about 500GB. This is divided into C: and E: (300/200), and each drive has at least 40% free space. (The sixth drive slot is taken up with another 146GB SAS drive, configured as a hot spare in the RAID array).

    Even my 2 USB drives that I use for backup aren't full, if that's of any importance. 


    Saturday, July 9, 2011 8:26 AM
  • On close inspection of the actual files that are failing to download, there is no pattern wrt size.  Some are small, some are big.  When actually downloading these updates manually from the MS site, there is no problem doing so.

     

    Saturday, July 9, 2011 8:41 AM
  • has the WSUS folder been excluded from AV scanning? Not normally necessary but one wonders if AV may be interfering.
    Saturday, July 9, 2011 8:55 AM
  • No, but I'm willing to try anything.  Will try that an post back.  Cheers, SG.
    Saturday, July 9, 2011 9:24 AM
  • I've tried downloading directly in the WSUS console, bypassing the proxy server, and with AV disabled on the c:\wsus folder and sub-dirs.  Some updates download fine, others repeatedly fail, no matter what.

    My only work-around at this time is to note the KB's of the failing updates, decline them, and manually install them on the respective servers.  I'm not going to install the workstations' updates manually!  That's a problem.



    Saturday, July 9, 2011 9:50 AM
  • Hi Ted:

    Below are some possible fixes from CSS in response to that same event ID, but with a different message, having to do with user rights.  I cannot say that the suggestions are very generic to any such failure, or if they are very specific to the user rights.   Another possibility is that the firewall is causing a time delay while it scans the incoming data stream, although i would have expected some time out warning in the event.

    Note that the suggestions are in response to SBS 2003 question, but WSUS 3 is WSUS 3, regardless of the version of Windows. 

    As always, have a known good backup before attempting any of the below.

    Suggestion 1
    -----------------
    Add Network service with full control to the following location:

    1. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
    2. C:\Documents and Settings\Default User\Application Data\Microsoft
    3. C:\Program Files\Update Services\WebServices
    4. C:\Windows\Temp

    Suggestion 2
    ----------------
    Run WSUS clean up wizard.

    Suggestion 3
    ----------------
    1. Run the commands below

    bitsadmin.exe /reset /allusers

    %programfiles%\Update Services\Setup\ExecuteSQL.exe -S %Computername%\MICROSOFT##SSEE -d "SUSDB" -Q "update tbConfigurationC setBitsDownloadPriorityForeground=1"

    Net stop wuauserv

    net stop bits

    2. Stop cryptographic & update services from services console

    run "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr0.dat" qmgr0.dat.old
    run "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr1.dat" qmgr1.dat.old

    net start bits

    Net start wuauserv

    Suggestion 4
    ----------------

    If the issue persists, perform the per steps described in the article below:

    “Error message when you try to download a file by using the Background Intelligent Transfer Service: "Content file download failed"”
    http://support.microsoft.com/kb/922330


    Larry Struckmeyer

    Please post the resolution to your issue so that everyone can benefit

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Saturday, July 9, 2011 3:14 PM
    Moderator
  • just comment

    The one thing I don't like about these instructions is the 'BitsDownloadPriorityForeground=1', however I know it is a thing commonly advised. Personally, I'd try the rest to see if it resolves the issue and only implement the foreground change as a last resort.

    Saturday, July 9, 2011 4:15 PM
  • Hi Larry, thanks for the tip about running the WSUS Cleanup Tool. 

    I have no more updates to approve.  The last 2 I approved went through no problem, i.e. they were approved, downloaded, and made available to the clients, all correctly.  The message in my event log is: All updates are downloading correctly.

    So, this is an intermittent problem, and seems to only get stuck on certain updates, but only a few compared to how many actually do work.

    Patch Tuesday is coming up, so I'll be able to check it out then.


    Re suggestion 1, these instructions apply to 2003, and I don't even get the option to add users to the ACL of CONFIG.

    I will wait until the error recurs and then try your options 3 and 4.


    • Edited by Bigteddy Sunday, July 10, 2011 3:14 AM
    Saturday, July 9, 2011 5:25 PM
  • Are you getting good backups? Have you run checkdisk on your partitions? Grabbing at straws. Of course you have reviewed your array manager and it shows no issues?
    Saturday, July 9, 2011 5:59 PM
  • it sure sounds HDD related.
    Saturday, July 9, 2011 11:31 PM
  • This is what I have done so far to try to fix the problem:
    1. Disabled A/V scanning on the WSUS folder and sub-folders – no success
    2. Cleared the proxy server cache and re-download – no success
    3. Bypassed the proxy server and re-download – no success
    4. Compacted the WSUS database using this script (successfully):

    http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61

    5. Run the Server Cleanup Wizard in WSUS unsuccessfully – it keeps hanging.  I’m trying again.
    6. Run a full chkdsk scan with the /f /r parameters on drive C:.  Here are the results:

    Checking file system on C:
    The type of the file system is NTFS.

    A disk check has been scheduled.
    Windows will now check the disk.                        
      209472 file records processed.                                     1133 large file records processed.                               0 bad file records processed.                                 0 EA records processed.                                       62 reparse records processed.                                  273516 index entries processed.                                    0 unindexed files processed.                                  209472 security descriptors processed.                           Cleaning up 3180 unused index entries from index $SII of file 0x9.
    Cleaning up 3180 unused index entries from index $SDH of file 0x9.
    Cleaning up 3180 unused security descriptors.
      32023 data files processed.                                     CHKDSK is verifying Usn Journal...
      536937000 USN bytes processed.                                      Usn Journal verification completed.
    CHKDSK is verifying file data (stage 4 of 5)...
      209456 files processed.                                          File data verification completed.
    CHKDSK is verifying free space (stage 5 of 5)...
      40021404 free clusters processed.                                  Free space verification is complete.
    CHKDSK discovered free space marked as allocated in the
    master file table (MFT) bitmap.
    CHKDSK discovered free space marked as allocated in the volume bitmap.
    Windows has made corrections to the file system.

     358399999 KB total disk space.
     197412224 KB in 170425 files.
         84184 KB in 32024 indexes.
             0 KB in bad sectors.
        817971 KB in use by the system.
         65536 KB occupied by the log file.
     160085620 KB available on disk.

          4096 bytes in each allocation unit.
      89599999 total allocation units on disk.
      40021405 allocation units available on disk.


    I am unable to test whether steps 4 and 6 have helped, because I have no updates to download right now.

    PS: All backups (Backup Exec and Windows Server Backup) are working fine.

    Sunday, July 10, 2011 4:48 PM
  • What about cecking your other partitions if you have any?
    Sunday, July 10, 2011 6:31 PM
  • Hi Jim,

    Yes I have another partition, E:, and I did also check it with the /r /f options.  It came out clean.  I didn't post the results, because my WSUS folder is on C:, and the results weren't interesting anyway.  No errors found on E:.

    Sunday, July 10, 2011 7:18 PM
  • the internal WSUS cleanup timing out is a common issue. One method of getting around it is to select the components of the cleanup individually, do 1 cleanup item at a time and run through each.

    I'm wondering about the performance of the database. Have you limited the RAM available to SQL and if so to what value?

    Sunday, July 10, 2011 10:38 PM
  • Hi SG. Yes, I read about the WSUS wizard problem.  So, last night I set it on the problematic option, and it immediately stops the Update Services service.  The previous time this happened, I left it, thinking it was by design that the service stopped.  About 8 hours later, it completely bombed.

    Last night, however, I manually started the service after it had been stopped by the Wizard, and let the Wizard run overnight.  This morning, the Wizard had completed successfully!  I am very pleased!  It deleted lots of files.  Now the Wizard will run through all the options quite quickly, without stopping the service, and without hanging.

    So, I've done all I know how, and shall wait for tomorrow (Patch Tuesday) to see if my problem persists.

    PS:  I haven't done anything with the SQL memory allocation on this box.  Everything is default as it came oob.




    Monday, July 11, 2011 6:09 AM
  • The wiz normally _does_ stop the service, but then starts it again.

    So I'm curious about any previous cleanups. You say the server has been in service for ~2yrs, had you previously run the cleanup tool occasionally/ever?

    I certainly hope, and can see distinct possibility, that whatever was causing the cleanup tool to fail was also causing the original problem. If the download completion wasn't being fed back into the database the next synchronisation would cause the download to be re-attempted, I guess.

    I think it's warranted, when convenient, to do a full system restart and just ensure that the cleanup wiz again completes without error. Also, I'm not sure that the problem with the database may not have caused the 'database compact' to not fully be able to do its job, you might do well to run it again also.

    Monday, July 11, 2011 7:21 AM
  • Hi SG, no, I hang my head in shame, I didn't even know about the WSUS cleanup wizard until a few days ago, so no, it's never been run in the 18 months this beautiful server has been in service.

    Will take your advice and restart the server again tonight, and re-run the cleanup wizard.  I'm fairly sure that it will be fine.  I read of someone who had exactly the same problem with the cleanup wiz, and got through it the same way.  That's what made me persevere.

    "I certainly hope, and can see distinct possibility, that whatever was causing the cleanup tool to fail was also causing the original problem" - ME TOO!

    BTW, how to you guys do that 'selective quote' thing, with bits of previous posts on a grey background?  Whenever I click quote, it quotes the whole damn post!

     


    Monday, July 11, 2011 7:39 AM
  • Hi SG, no, I hang my head in shame, I didn't even know about the WSUS cleanup wizard until a few days ago, so no, it's never been run in the 18 months this beautiful server has been in service.

    ...

    BTW, how to you guys do that 'selective quote' thing, with bits of previous posts on a grey background?  Whenever I click quote, it quotes the whole damn post!

     


    I think we do the 'quote' thing and then go into the grey area and delete what we don't need :-)
    Monday, July 11, 2011 7:59 AM
  • Hi,

    Did you ever got chance to go through the KB922330 as Larry suggested?


    Ketan Thakkar | Microsoft Online Community Support
    Tuesday, July 12, 2011 11:07 AM
    Answerer
  • Hi Ketan,

    I've had a look at it, and although the error id is the same (364), the message is different.  Having said that, someone very knowledgeable in the WSUS forum has suggested that "most likely is related to your router not properly supporting the use of Range Protocol Headers", and Larry's KB also refers to "HTTP 1.1 range requests".  I don't know if these are the same thing.

    However, my router seemed to be playing up, so I reset it anyway.  I think maybe my router got in a tangle.  But I will see tomorrow, and will post back to this thread.


    Tuesday, July 12, 2011 11:38 AM
  • Hi,

    This could very well be the case.

    Event 364 mostly indicates the update files download failure due to network performance between WSUS and exgternal Firewall.

    Let us know how it goes.


    Ketan Thakkar | Microsoft Online Community Support
    Wednesday, July 13, 2011 8:28 AM
    Answerer
  • I am very unhappy to report that my problem persists.  I'm not going to re-state it here, please see the first post of this thread.

    My next resort is to replace the router with a new one.  The existing router is about 7 years old, and perhaps there are new protocol extensions being used now that it doesn't understand.

    Any ideas/comments?

    Wednesday, July 13, 2011 8:53 AM
  • Hi,

    a. Open a command window.
    b. Type sc config bits start= auto
    c. Type net stop bits && net start bits
    d. Type net stop wsusservice && net start wsusservice
    e. Start WSUS 3.0: Click Start, click Administrative Tools, then click Microsoft Windows Server Update Services v3.0.
    f. Click Synchronization Results.
    g. In the Action pane, click Synchronize Now.
    Verify
    Look for the corresponding error event.
    a. Open a command window.
    b. Type cd <WSUSInstallDir>\Tools
    c. Type wsusutil checkhealth
    d. Type eventvwr
    e. Review the Application log for the most recent events from source Windows Server Update Services and events right after that in the vent log.

    Share those events and softwaredistribution logs at blrforum-at-microsoft-com

    You can ask for upload info if data is too large.

     


    Ketan Thakkar | Microsoft Online Community Support
    Thursday, July 14, 2011 9:05 AM
    Answerer
  • Hi Ketan,

    Thank you for those instructions.  I followed them, but I noticed that even before I did this, the updates were downloading successfully.  I have not yet changed the router/modem.

    I ran the WSUSUTIL tool as you said, and checked the event log.  The message is "Windows Updates Services is working correctly".  I checked in the WSUS console for the updates that were previously failing, and they have now been downloaded and offered to the clients.

    So, everything is working again, for now, and I have learned a lot about WSUS in the process!

    Thanks to all who helped me on this problem.

    • Proposed as answer by ketanbhutEditor Friday, July 15, 2011 10:00 AM
    • Marked as answer by Bigteddy Saturday, July 16, 2011 10:46 PM
    • Unmarked as answer by Bigteddy Wednesday, August 10, 2011 3:16 AM
    • Unproposed as answer by Bigteddy Wednesday, August 10, 2011 3:16 AM
    Thursday, July 14, 2011 6:00 PM
  • and get in the habit of running the cleanup task every few months, monthly is probably overkill but you wouldn't hurt anything. the scripted compact is needed even less frequently but is also a good practice.
    Thursday, July 14, 2011 9:53 PM
  • Hi SG, yes, I will do that from now on.  As I say, I've learned a lot about WSUS that I didn't know.  Also, credit to Lawrence Garvin in the WSUS forum for helping me out. 
    Friday, July 15, 2011 5:24 AM
  • Hello everyone in SBS-Land.

    I am very unhappy to see that this problem has not been resolved.  I'ts Patch Tuesday again, and I'm getting the same error again this month.

    What I have done in the meantime:

    1. Ran the WSUS Cleanup Wizard (multiple times)

    2. Ran the WSUS SQL defgrag script.

    3. Check my RAID array for consistency using the RAID s/w.

    4. Ran chkdsk on all volumes - no errors found.

     

    The pattern:  I will continue to recieve these errors for about a week, and then they will go away, and the updates will download successfully.

    ANY ideas would be most welcome!


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".
    Wednesday, August 10, 2011 3:21 AM
  • this ain't normal BT, so I'm gonna suggest something that ain't normal either.

    Go into your WSUSContent folder and delete ALL subfolders. DO NOT delete the content folder itself, just the 00,01,,,FF folders.

    HOWEVER, BEFORE doing so... consider that this is going to force a full redownload of all files. The folders will be recreated and content repopulated but consider the impact to your internet connection (particularly if you've done that thing about putting BITS into foreground mode).

    BTW: is the WSUSContent folder being scanned by AV? Might be worth excluding it, if you yet haven't.


    BTW2: (and edit) BACKUP 1st.
    Wednesday, August 10, 2011 9:13 AM
  • Hi SG, I'm sorry I haven't replied for some time.  Quite rude.  My only excuse is that I've been quite busy.

    Your suggestion about the WSUS content being excluded from the AV is a good one, but I'd already done that.

    My latest thing is (upon advice of Lawrence Garwin in the WSUS forum) I have upgraded my AV to the latest version (McAfee VSE 8.8), and updated it completely.  Now the updates seem to be coming down ok.

    I will keep this thread posted of developments.

    Re your suggestion about deleting the subfolders, I have left that for now, because, as I say the updates seem to be downloading now.


    If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer".
    Thursday, August 11, 2011 1:21 PM
  • Hello,

    The even says it all:

    Content file download failed.

    Reason: The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

    This seems related to re-directing the WSUS traffic WAN Access to a PROXY or WEB-Filter which does not support "HTTP 1.1 range Requests". Google seems to have certain PATENTS on that maybe that's the reason it dropped out of some FW/PROXY where it was once included?.

    Tell your NETWORK Admin to check if the filter solution does support that. If not a) Let the WSUS Direct to WAN b) Change BitsDownloadPriorityForeground=1 c) OR worst TIP they reinstall/Install Framework 3.5.1 Feature component WHICH (I guess) sets the BitsDownloadPriorityForeground also. (Just by luck a lucky strike ;-)

    https://tools.ietf.org/html/rfc7233 (HTTP 1.1 range Requests)

    Main Problem and source seems the PROXY or WEBFILTER. This is known in SOPHOS and SONICWALL Forums. Never seen in esp. related or with KB on Fortinet.

    https://community.sophos.com/products/unified-threat-management/f/network-protection-firewall-nat-qos-ips/78776/problem-with-downloading-wsus-updates

     

    https://support.microsoft.com/en-us/help/922330/error-message-when-you-try-to-download-a-file-by-using-the-background

    https://social.technet.microsoft.com/Forums/en-US/ac5f7668-6460-4082-8d0b-0690bcc8229a/6703-failed-to-sync-some-of-the-updates?forum=configmgrgeneral

    Greetings from Switzerland

    Mike

    Monday, September 16, 2019 11:54 AM