WSUS failing to downloading updates, but, still showing the Downloading Status as complete

Question

Before I start, I'd say that I've done enough research for the problem, and I had also raised a case in the past with Microsoft Support to come to a conclusion for this problem. This time, the problem is with an unexpected twist.

Problem Statement: WSUS is failing to download updates; refer the event viewer logs and the screenshots below:

-> Error 17-07-2018 12:29:39 Windows Server Update Services 10032 7 The server is failing to download some updates.

-> Error 17-07-2018 00:14:26 Windows Server Update Services 364 2 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. // taken Microsoft Support in the past to identify the problem was some setting of the proxy appliance.

Source File: /c/msdownload/update/software/secu/2018/07/pciclearstalecache_7b1e71fc5a81cd30e0a46338caa6fb1d2880f2c2.exe

Destination File: E:\WSUS\WsusContent\C2\7B1E71FC5A81CD30E0A46338CAA6FB1D2880F2C2.exe

The strange part for me is I'm not able to understand why the download status is shown as complete, given that the update themselves are individually failing. I've repeatedly tried, but the effort has been in vain.

My Observations: In the past we had the problem that WSUS was entirely failing to download update, and even the downloaded status was zero.

At that time, we took Microsoft Support and came to the conclusion that there is a setting in our proxy which has scanning feature of antivirus and anti-malware engine, because of which the downloading of patches takes significant time or the session is getting terminated. OEM of proxy confirmed that "a file that is large and dense, such as a 200MB ZIP file containing software developer tools, etc. can take 30+ minutes to be fully scanned by the anti-virus/anti-malware engine." The case was closed after we excluded the Windows update URL from the scanning feature of proxy, and the updates were downloaded successfully in the WSUS.

Unfortunately, this time the case is same, except that the patches are shown as downloaded in the WSUS dashboard, but individually shows as failed in the update view. We've confirmed from the proxy that this scanning of the package setting has been enabled permanently, and are not ready to change without a proper justification. They have asked us to check as to why this peculiar behaviour is depicted in WSUS.

Queries:

1. Can someone explain why WSUS is showing dual behaviour of patch download status? I've checked that the WSUSContent (E:\WSUS\WsusContent) is not showing any recently downloaded updates.

2. If I try the same from browser on the WSUS Server, the file takes too long to download. But, it does complete the dialog from the browser for the same URl. Unfortunately, it seems that there is some timeout value for WSUS which doesn't take care to wait till the proxy appliance scans the entire package. Is there anyway I can force it to wait to download patches?

3. Why the session is maintained in the browser to download the entire package, but not in WSUS to download the same update?

Thank you for going through the entire question. If any further detail is required, please let me know. If you can contribute / suggest anything towards the problem, I am all ears.

Solution

For your proxy download issue you could try to running BITS in foreground mode.

in powershell

$wsusServer = Get-WsusServer -name YourServerName -PortNumber 8530
$wsusConfig =  $wsusServer.GetConfiguration()
$wsusConfig.BitsDownloadPriorityForeground = $true
$wsusConfig.save()

To resolve the downloaded files status inconsistency

At the command line, browse to

%drive%\Program Files\Update Services\Tools>

type:

wsusutil reset

This will re-scan for files that require downloading.

Comments

[Am_I_Helpful]

Thanks for sharing the point. Actually, I feared to try step 1 about running BITS in foreground mode, as if what to do if it breaks WSUS? I'll try this when in office and let you know the result.

[Eric]

I don't think there is any risk in breaking WSUS in a permanent way, it just changes how BITS downloads the files. In background mode (the default), files are copied in multiple small parts. This can cause issues with proxies depending on the settings. Plus its an easy thing to change back.

[Am_I_Helpful]

Hi @Eric. This solution has worked, and helped download 80% of the files. Rest are still failing, and I need to look why/how? I want to upvote this answer, but, unfortunately I'd have to wait till Monday to see if it fully resolves the problem, after successive retries/reboots. Thanks for your answer though.

[Eric]

Cool any progress is good news, make sure you aren't running out of space on the volume with the wsus directory, now that your getting most of the files. Hopefully it works itself out and you don't have to rebuild wsus.

[Am_I_Helpful]

I feel very sorry to state but this answer also didn't work for me. I've tried resetting wsusutil several times (performed several reboots); still, the patches don't get downloaded. This command always leads WSUS to download 292.5 GB of data from the beginning, despite WSUS downloading it completely before the reboot! Sorry, but this doesn't work.

[Eric]

did the The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header. errors go away?

[Eric]

I have no idea what kind of environment you are in, but If I were stumped on this I would spin up a new WSUS server, get all my rules and downloads working. Then migrate all the clients over.

[KBanks]

THIS IS DANGEROUS!! """ wsusutil reset This will re-scan for files that require downloading. """ My WSUS was stuck after downloading 330GB of 372GB of files. I issued the above command and downloads started over completely with 0 of 372GB!!! It took over two days to download the 330GB of files!!! Now WSUS is downloading them again!