WSUS client problem downloading updates
Rob
the Windows Update Agent API to check for updates on a WSUS server and
download the updates. The check for updates part works great. The problem
occurs when I try to download the updates. At that point the download fails
and I get the following error message in my windowsupdate.log file. KB955069
is not getting download in the snippet below.
2008-11-20 09:30:43:468 3720 8f4 COMAPI -------------
2008-11-20 09:30:43:468 3720 8f4 COMAPI -- START -- COMAPI: Download
[ClientId = <NULL>]
2008-11-20 09:30:43:468 3720 8f4 COMAPI ---------
2008-11-20 09:30:43:468 3720 8f4 COMAPI - Forced: No; Download priority: 3
2008-11-20 09:30:43:484 3720 8f4 COMAPI - Updates in request: 1
2008-11-20 09:30:43:484 3720 8f4 COMAPI - ServiceID =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
2008-11-20 09:30:43:484 3720 8f4 COMAPI <<-- SUBMITTED -- COMAPI: Download
[ClientId = <NULL>]
2008-11-20 09:30:43:484 1220 a50 DnldMgr *************
2008-11-20 09:30:43:484 1220 a50 DnldMgr ** START ** DnldMgr: Downloading
updates [CallerId = ]
2008-11-20 09:30:43:484 1220 a50 DnldMgr *********
2008-11-20 09:30:43:484 1220 a50 DnldMgr * Call ID =
{B40FB152-EECE-4FE1-AE38-A69C1685664B}
2008-11-20 09:30:43:484 1220 a50 DnldMgr * Priority = 3, Interactive = 1,
Owner is system = 1, Explicit proxy = 1, Proxy session id = -1, ServiceId =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
2008-11-20 09:30:43:484 1220 a50 DnldMgr * Updates to download = 1
2008-11-20 09:30:43:484 1220 a50 Agent * Title = Security Update for
Windows XP (KB955069)
2008-11-20 09:30:43:484 1220 a50 Agent * UpdateId =
{1A544E1D-4157-43A6-93FA-0283CBE2D93C}.102
2008-11-20 09:30:43:484 1220 a50 Agent * Bundles 1 updates:
2008-11-20 09:30:43:484 1220 a50 Agent *
{90BD94E6-CAC9-4763-AFB8-A9AE2A42861A}.102
2008-11-20 09:30:43:500 1220 a50 DnldMgr *********** DnldMgr: New download
job [UpdateId = {90BD94E6-CAC9-4763-AFB8-A9AE2A42861A}.102] ***********
2008-11-20 09:30:43:500 1220 a50 DnldMgr * Queueing update for download
handler request generation.
2008-11-20 09:30:43:500 1220 a50 DnldMgr Generating download request for
update {90BD94E6-CAC9-4763-AFB8-A9AE2A42861A}.102
2008-11-20 09:30:44:375 1220 a50 Handler Windows Patch download for UpdateId
= {90BD94E6-CAC9-4763-AFB8-A9AE2A42861A}: selected action is download
full-file.
2008-11-20 09:30:44:375 1220 a50 DnldMgr *********** DnldMgr: New download
job [UpdateId = {90BD94E6-CAC9-4763-AFB8-A9AE2A42861A}.102] ***********
2008-11-20 09:30:44:812 1220 a50 DnldMgr * BITS job initialized, JobId =
{6DEE96F0-5E5D-4CE8-B982-CDC753B406F4}
2008-11-20 09:30:44:890 1220 a50 DnldMgr * Downloading from
http://xxx/Content/F3/FA864585A7D761BA0F940EFF151672871D0E69F3.exe to
C:\WINDOWS\SoftwareDistribution\Download\0a18cd232f6e18775fe5d3e4dcf13ec2\WindowsXP-KB955069-x86-ENU.exe (full file).
2008-11-20 09:30:44:968 1220 a50 Agent *********
2008-11-20 09:30:44:968 1220 a50 Agent ** END ** Agent: Downloading
updates [CallerId = ]
2008-11-20 09:30:44:968 1220 a50 Agent *************
2008-11-20 09:30:54:171 1220 efc DnldMgr WARNING: BITS job
{6DEE96F0-5E5D-4CE8-B982-CDC753B406F4} failed, updateId =
{90BD94E6-CAC9-4763-AFB8-A9AE2A42861A}.102, hr = 0x80200011, BG_ERROR_CONTEXT
= 5
2008-11-20 09:30:54:171 1220 efc DnldMgr Progress failure bytes total = 0,
bytes transferred = 0
2008-11-20 09:30:54:171 1220 efc DnldMgr Failed job file: URL =
http://xxx/Content/F3/FA864585A7D761BA0F940EFF151672871D0E69F3.exe, local
path =
C:\WINDOWS\SoftwareDistribution\Download\0a18cd232f6e18775fe5d3e4dcf13ec2\WindowsXP-KB955069-x86-ENU.exe
2008-11-20 09:30:54:468 1220 efc DnldMgr WARNING: Download job failed
because of insufficient range support.
I've read through many forum entries and I've checked out what I can. I saw
that the 80200011 error is caused by not receiving the "Content-Length" in
the Server response. I used the following link as a reference.
http://technet.microsoft.com/en-us/library/cc720473.aspx
One thing I wasn't sure about in the log above, was the reference to
"Explicit proxy = 1". If I don't have a proxy, what does that do?
Using that as a starting point, here's what I have found
1. I've checked that I'm not going through a proxy server. I also ran a
test using a VMWare environment. I put a client on the same subnet as the
WSUS server and got the same response.
2. The problem has to do with the WSUS server not providing the
"Content-Length" field in the response from a HEAD request. Below is an
example where the "Content-Length" is not in the return packet.
HEAD /Content/F3/FA864585A7D761BA0F940EFF151672871D0E69F3.exe HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: */*
---------------: --------
User-Agent: Microsoft BITS/6.7
Host: xxx
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Fri, 21 Nov 2008 16:35:04 GMT
Content-Type: application/octet-stream
Last-Modified: Thu, 25 Sep 2008 02:07:25 GMT
Accept-Ranges: bytes
ETag: "802cf273b31ec91:a6d"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
3. I did some testing by using telnet to access the WSUS server and adding
in the HEAD request above. I found that if I remove the
"Accept-Encoding:gzip,deflate" part I do get the "Content-Length". This is
shown below
HEAD /Content/F3/FA864585A7D761BA0F940EFF151672871D0E69F3.exe HTTP/1.1
Accept: */*
---------------: --------
User-Agent: Microsoft BITS/6.7
Host: xxx
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Length: 926760
Content-Type: application/octet-stream
Last-Modified: Thu, 25 Sep 2008 02:07:25 GMT
Accept-Ranges: bytes
ETag: "802cf273b31ec91:a6d"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 25 Nov 2008 15:27:37 GMT
4. I found that .cab files have no problem getting the "Content-Length"
even if the "Application-Encoding" exists. This is shown below
HEAD /selfupdate/wuident.cab?0811242237 HTTP/1.1
Accept-Encoding: gzip,deflate
Accept: */*
---------------: --------
User-Agent: Microsoft BITS/6.7
Host: xxx
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Length: 10144
Content-Type: application/octet-stream
Last-Modified: Tue, 17 Apr 2007 09:12:58 GMT
Accept-Ranges: bytes
ETag: "0891a97d080c71:a6d"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 25 Nov 2008 17:44:23 GMT
5. Using "wuauclt.exe /detectnow", works. In my captures I saw that this
method uses "GET" instead of "HEAD". The "GET" requests provide the
"Content-Length" with or without the "Accept-Encoding". This is shown below
GET /Content/F3/FA864585A7D761BA0F940EFF151672871D0E69F3.exe HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: */*
---------------: --------
Range: bytes=0-4659
User-Agent: Microsoft BITS/6.7
Host: xxx
Connection: Keep-Alive
HTTP/1.1 206 Partial Content
Content-Length: 4660
Content-Type: application/octet-stream
Content-Range: bytes 0-4659/926760
Last-Modified: Thu, 25 Sep 2008 02:07:25 GMT
Accept-Ranges: bytes
ETag: "802cf273b31ec91:a6d"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Fri, 21 Nov 2008 21:58:43 GMT
Does anyone know why the WSUS server wouldn't be giving the Content-Length,
in this case, and what I could do to try to get it to provide the
Content-Length to get BITS to follow through with the Update download?
Thanks,
Rob
Diana
0x80200011 BG_E_MISSING_FILE_SIZE
Do you have a Firewall (Norton, FortiGate-800 Firewall, etc)?
Please check to see if the policy on the firewall is blocking .exe from
being downloaded.
Diana
Diana Smith [MSFT] <dias...@hotmail.com>
CSS Security Team
This posting is provided "AS IS" with no warranties, and confers no rights.
"Rob" <R...@discussions.microsoft.com> wrote in message
news:02CC422A-C33E-4092...@microsoft.com...
Lawrence Garvin (MVP)
The first thing you need to do is apply Service Pack 1 to your WSUS
installation.
> I'm using
> the Windows Update Agent API to check for updates on a WSUS server and
> download the updates.
> 2008-11-20 09:30:54:468 1220 efc DnldMgr WARNING: Download job failed
> because of insufficient range support.
> 2. The problem has to do with the WSUS server not providing the
> "Content-Length" field in the response from a HEAD request.
Why are you using HEAD requests?
> 5. Using "wuauclt.exe /detectnow", works. In my captures I saw that this
> method uses "GET" instead of "HEAD". The "GET" requests provide the
> "Content-Length" with or without the "Accept-Encoding".
Yes.... that's how it's supposed to work.
> Does anyone know why the WSUS server wouldn't be giving the
> Content-Length,
> in this case, and what I could do to try to get it to provide the
> Content-Length to get BITS to follow through with the Update download?
It's not the "WSUS Server" that's at issue here. It's how you're using the
API, BITS, and IIS.
"WSUS" is totally out of the picture once you start requesting content from
the simple virtual directory /Content.
If the WUA initiates the download request, in response to a successful
detection, it queues a job to BITS, and BITS initiates the download, using a
GET request (as you've noted).
So, my first question, still, is; What is it that you're doing that's
generating a HEAD request.
And if you want to keep doing that, and you've noticed that you need to
disable client-side compression to get it to work, then that's what you have
to do. But that has nothing to do with WSUS, that's simply the behavior of
IIS/BITS in response to using a HEAD request to get a file. (Where you
probably *should* be using a GET request anyway! - which, as you've noted,
works flawlessly.)
Hows about we back up and you explain *exactly* what you're doing with the
WUA API, specifically how you are executing the detection, and initiating
the download request.
Admins have been using the WUA API for eons now to do these type of
operations, and I've never seen this issue reported before, so I have a
strong feeling it must be something you are doing.
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
Rob
There is no firewall or any policy blocking exe files. In fact, I am able
to successfully download the exe file if using "wuauclt /detectnow" (ie WUA)
instead of the API. This proves that a firewall or policy is not blocking
the access. Based on my captures it does look like WUA is just using a GET
request instead of a HEAD request followed by a GET request
It seems that the problem is with the IIS/WinHTTP/BITS not sending the
content-length in the HEAD response. The "Content-Length" should be returned
no matter what, right? Of course the content has to be static content. I
understand that dynamic content does not necessarily return the
"Content-Length". That is not the case here, though.
Lawrence,
Unfortunately, the WSUS server is not under my control, so I can't force
them to upgrade, although I did ask the question. I did test with a test
WSUS server running SP1 and it had the same problem.
I'm actually using the Cisco NAC Agent to run the WSUS checks and downloads.
The Agent uses the WUA API to synchronize the database and download the
updates. That's a long way of saying, I'm not sure why it's sending the HEAD
request.
Are you saying that disabling client-side compression will fix the problem?
Rob
Rob
I actually ran then example in the WUA API MSDN page at
http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx
I ran a capture while the script ran and found that this script kicks off
the HEAD request as well, so this must be part of the way the WUA API works.
Does that seem right to you?
Thanks,
Rob
Lawrence Garvin (MVP)
> Lawrence,
>
> I actually ran then example in the WUA API MSDN page at
> http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx
>
> I ran a capture while the script ran and found that this script kicks off
> the HEAD request as well, so this must be part of the way the WUA API
> works.
> Does that seem right to you?
Hmm..... maybe its a quirk of how the WUA functions directly,
as opposed to what's been coded in the API.
Let me look into this.
Lawrence Garvin (MVP)
> I'm actually using the Cisco NAC Agent to run the WSUS checks and
> downloads.
> The Agent uses the WUA API to synchronize the database and download the
> updates. That's a long way of saying, I'm not sure why it's sending the
> HEAD
> request.
>
> Are you saying that disabling client-side compression will fix the
> problem?
It seems to me that if the client is sending a field identifying the
willingness to accept compressed files, and the presence of that field in a
HEAD request is causing IIS to not send the Content-Length field, and
removing that field resolves the problem, then Yes, disabling client-side
compression would seem to be the logical resolution to the problem.
However, disabling compression when a fair number of the files to be
transferred across the link are compressible, is not an ideal solution. Not
only that, it won't affect just WSUS transfers, but anything else
transferred as well.
Personally, since you've isolated the cause (use of the HEAD), I'd bounce it
back up to Cisco, point out to them the defect you've discovered, and ask
them when a properly designed version will be available. I'd even go so far
as to consider not using such a defective product -- particuarly if it's
going to have an adverse impact on other operations.
Rob
I know alot more about VB Scripting. The bad news is that I don't see a
solution. I tried to ge the asynchronous download working, to see if that
would help, but I couldn't get that working.
I was able to make one discovery though. I have a home machine that goes to
Microsoft for updates. From this computer, I see the following in the
windowsupdate.log file
If I telnet to port 80 on au.download.windowsupdate.com and manually add a
HEAD command with the information above, I get the following
HEAD
/msdownload/update/software/secu/2008/09/windowsxp-kb955069-x86-enu_fa864585a7d761ba0f940eff151672871d0e69f3.exe HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: */*
---------------: --------
User-Agent: Microsoft BITS/6.7
Host: au.download.windowsupdate.com
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Length: 926760
Content-Type: application/octet-stream
Accept-Ranges: bytes
ETag: "802cf273b31ec91:803b"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Age: 340503
Date: Sun, 30 Nov 2008 16:47:53 GMT
Last-Modified: Thu, 25 Sep 2008 02:07:25 GMT
Connection: keep-alive
You'll notice that the "Content-Length" appears in the response. So....it
looks like Microsoft has fixed something on their internet Windows Update
servers that is different from the WinHTTP version that is given for WSUS
servers. What do you think I should do at this point?
Rob
Rob
thinking is based on the following two items
1. The "Content-Length" is successfully returned when a HEAD request is
submitted to the Microsoft Windows Update site. From the HEAD response in
the information in the trail below, you can tell the server is running IIS
6.0. There must be other settings that I'm missing on my IIS 6.0 server that
are not allowing the "Content-Length" to be returned. It would be nice to
find out what the Microsoft site has that I don't so I can add it to my IIS
WSUS server and be done with this issue.
2. I also have a CentOS Linux box at home running Apache 2.0. I uploaded
one of the Microsoft update exe files to the server and did the HEAD request.
I did get the "Content-Length" returned there. Assuming the Apache server
is handling HTTP 1.1 requests correctly, this means that the IIS 6.0 needs a
change to handle HEAD requests correctly. Below is the request and response
from my Apache server
HEAD /KB955069.exe HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: */*
---------------: --------
User-Agent: Microsoft BITS/6.7
Host: 10.1.1.6
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Sun, 30 Nov 2008 23:31:11 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Sun, 30 Nov 2008 23:28:00 GMT
ETag: "33986a9-e2428-71eb6000"
Accept-Ranges: bytes
Content-Length: 926760
Connection: close
Content-Type: application/octet-stream
Let me know what you think....
Thanks,
Rob
Rob
The fundamental problem was that the client was sending the
"Accept-Encoding:gzip,deflate", which told the server that chunked encoding
was supported. Chunked encoding and sending the "Content-Length" are
mutually exclusive, meaning that you can't have both in the same response
header. The following link provides a pretty good description
http://www.ibm.com/developerworks/web/library/wa-httpiis/
I got around this by disabling the HTTP compression on the IIS server.
Lawrence alluded to this, but didn't provide the specific details no how to
do it. Here's how to do it assuming you are running IIS 6.0
1. Open the IIS Manager
2. Right click on the "Web Sites" folder
3. Click on "Properties"
4. Click on the "Service" Tab
5. Uncheck the "Compress application files" box
6. Restart IIS
I spent a fair amount of time trying to remove the
"Accept-Encoding:gzip,deflate" from the WUA API download VBScript at
http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx
but it didn't look like there were options for that. It might have been
possible with the WinHTTP API, but I wasn't sure how that was called within
the WUA API. If anyone can help me out with that, I would greatly appreciate
it.
Rob
Lawrence Garvin (MVP)
> I got around this by disabling the HTTP compression on the IIS server.
> Lawrence alluded to this, but didn't provide the specific details no how
> to
> do it.
Some misunderstanding, perhaps?
I never said to disable HTTP compression on the IIS Server.
Doing so is definitely *not* recommended.
What I said was that if using the methdology you've chosen to do was
necessary, and you *needed* the ability to have Content-Length fields in the
return (e.g. the ability to use BITS in background mode), then perhaps you
could disable compression at the *CLIENT*.
> I spent a fair amount of time trying to remove the
> "Accept-Encoding:gzip,deflate" from the WUA API download VBScript at
> http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx
> but it didn't look like there were options for that.
But, if you cannot disable it at the client... then my suggestion would to
be keep looking for a solution.
Disabling compression at the server is not an appropriate solution.
Rob
Sorry about that. I guess it's back to the drawing board. At least I now
know fundamental reason why it's not working and at least one way to make it
work.
Thank you for the pointers and please let me know if you run across anything
that could help.
Thanks,
Rob
Rob
What do you think of just disabling HTTP compression for .exe files.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true
Alternatively, I could just turn off compression on the Content directory,
where the downloads are kept
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true
Rob
One other point of note. It appears that the update.microsoft.com site has
compression disabled on their server. When I sen the HEAD request, including
the "Accept-encoding: gzip,deflate", I do receive the "Content-Length" field.
Do you think that's a correct assumption?
Here's the output from the request
HEAD
/msdownload/update/software/secu/2008/09/windowsxp-kb955069-x86-enu_fa864585a7d761ba0f940eff151672871d0e69f3.exe HTTP/1.1
Accept-Encoding: gzip, deflate
Accept: */*
---------------: --------
User-Agent: Microsoft BITS/6.7
Host: au.download.windowsupdate.com
Connection: Keep-Alive
HTTP/1.1 200 OK
Content-Length: 926760
Content-Type: application/octet-stream
Accept-Ranges: bytes
ETag: "802cf273b31ec91:803b"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Age: 340503
Date: Sun, 30 Nov 2008 16:47:53 GMT
Last-Modified: Thu, 25 Sep 2008 02:07:25 GMT
Connection: keep-alive
Lawrence Garvin (MVP)
> Lawrence,
>
> What do you think of just disabling HTTP compression for .exe files.
> http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?
mfr=true
Given that EXE files are the most likely to benefit from compression being
enabled, I would recommend against that.
> Alternatively, I could just turn off compression on the Content directory,
> where the downloads are kept
> http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true
The CONTENT directory is the primary reason compression is recommended to be
enabled.
Lawrence Garvin (MVP)
> Lawrence,
>
> One other point of note. It appears that the update.microsoft.com site
> has
> compression disabled on their server.
The =update.microsoft.com= site is not the same site that the *content* is
downloaded from. The benefits from compression at =update.microsoft.com= are
minimal at best, just as they would be by enabling compression only on the
/clientwebservice or /simpleauthwebservice folders of your WSUS Server,
given that the typical packet transfer from that site is measure, at most,
in only a few KB per session.
> Here's the output from the request
> HEAD
> /msdownload/update/software/secu/2008/09/windowsxp-kb955069-x86-enu_fa864585a7d761ba0f940eff151672871d0e69f3.exe
> HTTP/1.1
> Accept-Encoding: gzip, deflate
> Accept: */*
> ---------------: --------
> User-Agent: Microsoft BITS/6.7
>>>>> Host: au.download.windowsupdate.com <<<<<
Take a look at the hostname providing the *CONTENT*.
I believe you'll find that =au.download.windowsupdate.com= has compression
enabled.
Rob
First of all, thank you very much for answering my questions. I've read
many of your other posts on this forum and I highly value your opinion.
In the trail below, I meant au.download.microsoftupdate.com and not
update.microsoft.com. Sorry, typo on my part.
Based on the link http://www.ibm.com/developerworks/web/library/wa-httpiis/,
it appears that the HTTP response should contain the "Content-Encoding" field
to show what type of compression is being used. If that field does not
exist, I'm assuming compression will not be done. Is that your understanding
as well? Below is the excerpt from the site.
When the server sends back the resulting content, the Content-Encoding
header reveals to the browser the format used to compress the content.
Listing 2 is an example of an HTTP header in a response with compressed
content. Note the Content-Encoding and Transfer-Encoding headers -- the
content length is not specified in the HTTP header.
I was using that as a basis for saying that au.download.microsoft.com was
not using HTTP compression. As a secondary measure, I found a website that
tests other sites for website cmopression. The site is
http://www.port80software.com/products/httpZip/
It showed the site as uncompressed with the following report
Summary:
URL:
http://au.download.windowsupdate.com/msdownload/up
date/software/secu/2008/09/windowsxp-kb955069-x86-
Scope of analysis: Real-time data -- target file compression reports only
(no supporting files).
Web server type:
Microsoft-IIS/6.0
Compression status: Uncompressed
Rob
Rob
compression. It's called Website Analyzer.
http://www.vigos.com/products/website-analyzer/
Rob