I had this on a MS Windows Server 2003. Reason: "The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header." - The errors started after ESET File Security 4.5 had been installed with HTTP protocol filtering enabled. The resolve the issue I had to exclude "C:\Program Files\Update Services\service\bin\wsusservice.exe" from protocol filtering.
I was getting events id 364 and 10032. We have a SonicWALL NSA 4500 firewall. I excluded the WSUS server from Anti-Spyware scans and IPS and the errors are gone.
We experienced this issue in combination with a BlueCoat Appliance. The appliance was acting as a proxy. Due to security reasons all the traffic was scanned by several AV engines. Because the AV engines open the downloaded packages an check it for viruses, the packages may get corrupted (The appliance fills the download with "0" until it is done with scanning). The WSUS detects this modification and because the CRC checksum is invalid the package is deemed as unsecure and it will be dumped. Disabling the scanning of the Microsoft updates solved our problem.
I found my Barracuda Web Filter 610 was the cause, adding the WSUS server IP as an exemption resolved my issue.
I received this event along with 10032 and 10022 errors. I reset the database using the suggestions outlined in "Purge / Delete corrupted or Un-needed patches on WSUS Server" my WSUS server began downloading the updates.
In may case all the web traffic was scanned on the firewall box, a model from the Fortinet Fortigate product range. I disabled the scan for the Microsoft servers that are hosting the updates, and everything works fine now.
In my case, I am using Firebox 10.0.2 and Watchguard. I had to allow on HTTP-outgoing proxy properties for HTTP requests to "Allow range requests through unmodified". As soon as I enabled this option, the updates began to download with no problem.
I got this event along with event 10032 and 10012. As suggested by another poster I changed the "Update Services" service to use the Local Service account and everything starting working again. If this does not fix the problem then also check permissions to the WSUSInstallDirectory.
Check the firewall logs. In my case, the firewall was detecting and blocking malformed ART files. I allowed these to pass and WSUS began synchronizing again.
- Reason: "Access is denied" - See ME920658
- Reason: "The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header" - See ME922330
and the link to "WSUS Firewall Problem" for details on fixing this problem.
- Reason: "The server did not return the file size. The URL might point to dynamic content. The Content-Length header is not available in the server's HTTP reply" - A newsgroup post suggests that the proxy (if using one) is removing the Content-Length header.
In some cases, this might be due to lack of permissions for NETWORK SERVICE. See ME820379
and the link to "WSUS Solution" to solve this problem.
In my case, I only had to set the service to use the Local Service account. After this, it started downloading.
On a new installation of WSUS, several updates are set to the Approved/Install status by default. BITS and Windows Installer among them. Those updates were marked with a red X and refused to download.
I was able to set BITS on the WSUS server to foreground mode using the following three commands. I was then able to download the updates.
- Net stop bits
- "%programfiles%\Update Services\tools\osql\osql.exe" -S %Computername%\WSUS -E -b -n -Q "USE SUSDB update tbConfigurationC set BitsDownloadPriorityForeground=1"
- Net start bits.
In my case, this event occurred after moving WSUS to another server in which the content directory drive letter had changed. Ended up having to update the SUSDB database - tbConfigurationB.LocalContentCacheLocation - to reflect the new location.
I also had this event and looked at Microsoft KB article ME922330
. It talks about a SonicWall firewall and the "Enable HTTP Byte-Range request with Gateway AV" setting that is enabled. I noticed that mine was not enabled and thus not the cause of my problem. However, I figured that if this service could be causing problems then another may as well. I put the IP address of my WSUS server in the exceptions list for the IPS service, synced my WSUS server and the downloads started pouring in.
In my case, it was only the Windows Defender updates that were having problems synchronizing. After trying just about everything, I installed the optional "Root Certificates Update" and although it looked like nothing happened, retrying the update download after installing this worked for me. You can get the rootsupd.exe file by clicking on the "Root Certificates Update" link below.
In my case, setting the Update Service to use the Local System account helps. I needed to restart the Update Service and the Automatic Updates service to get downloads to start.
I had exactly the same problem, synchronization succeeded but then 0% of the updates were actually downloaded. This was on a newly configured W2k3 server. I had to do two things to resolve my issue:
1. I set the "Update Services" service to run using the "local system" account.
2. I set the "Network Service" to have NTFS modify from the root of the drive that houses my WSUS content. I have not yet tested changing the Network Service to having only read at the root, and more permissions on the WSUS content directory, as mentioned in the other posts.
See the link to "PatchAholic...The WSUS Blog - Content File Download Failed" for information on this event.
The problem is caused by a lack of permissions for the Network Service to read and write to the drive used by WSUS. See MS ME555505
- Reason: "The requested URL does not exist on the server" - In my case the proxy server we are using does not allow WSUS to initiate the web request to the Microsoft Update sites. I had to make an exception on our proxy server\firewall to allow the WSUS server to access Microsoft Update directly and bypass the proxy for the following addresses:
In my case, this event occurred when the drive was not formatted in the local system. The problem was that the wsusservice had no rights to the wsus folder. I set the wsusservice to run as local system account, and the problem was solved.
- Reason: "There is not enough space on the disk" - I fixed this problem by raising the quota of the Network service.
- 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 problem occurs if your proxy environment does not support HTTP 1.1 Protocol. You can manually work around this by configuring BITS. Download “Microsoft Windows Server Update Services server diagnostic tool”, extract file and run following command from command prompt:
- Reason: "The interface is unknown" - I restarted the service "Update Services" and the problem was solved.
- Reason: "The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header" - See the link to "Troubleshooting WSUS In Production" for information on this event.
- Reason: "Access is denied" - The fix is to insure that the Network Service account has read access to the drive the updates are stored on. You also have to make sure the Network Service account has at least modify rights to \wsus\WsusContent and its subdirectories.