Windows 7 - WSUS Download failed, error = 0x80244019

Asked By rvvisse on 13-Oct-09 03:07 PM
All,

I have tried quite a few things to fix this issue, but I have resorted to
getting some outside help.

We're trying to add a new forest of 14 servers to an existing Windows Update
server.  Everything seems to be fine until it tries to download the updates.
All of the other servers that belong to the WSUS server do not have problems.


What I have found out:
- The SelfUpdate folder exists and has anonymous access
- No proxy settings are enabled or needed on the client
- URLscan is not installed on the server
- The file is not physically missing on the wsus server, it is there
- Pulling an .exe address from the logs up in IE gives a 404 error on my
servers, on servers that are updating correctly and also on the wsus server
- Firewall has not shown any denies
- No other firewall software exists and windows firewall is disabled
- We are in a separate active directory forest, but we do not have a WSUS
server available in this forest

Can any one help?  I have been working on this for longer than a week :(


See my log file below:

2009-10-06	11:10:52:163	1108	16b8	AU	  # WARNING: Download failed, error =
0x80244019
2009-10-06	11:10:57:164	1108	f24	Report	REPORT EVENT:
{CE27AAFF-EE18-4DAC-A9B1-B03376216D77}	2009-10-06
11:10:52:163-0400	1	161	101	{C896FBDD-74A2-441B-B50B-0C4CF7857700}	101	80244019	AutomaticUpdates	Failure	Content Download	Error: Download failed.
2009-10-06	11:11:00:180	1108	14b4	DnldMgr	WARNING: BITS job
{894964FC-BB05-43EB-B3B3-0511135BA92A} failed, updateId =
{D12B734F-1AC1-4383-819B-4285877CC1CD}.101, hr = 0x80190194, BG_ERROR_CONTEXT
= 5
2009-10-06	11:11:00:180	1108	14b4	DnldMgr	  Progress failure bytes total =
0, bytes transferred = 0
2009-10-06	11:11:00:180	1108	14b4	DnldMgr	  Failed job file: URL =
http://<fqdn
removed>/Content/79/B65495BD42C584D905A9A4C5E4D643BD75D5A679.exe, local path
=
C:\WINDOWS\SoftwareDistribution\Download\a6e4ed99177b5f95ba446c3066c7e5e3\WindowsServer2003-KB968816-x86-ENU.exe
2009-10-06	11:11:00:195	1108	14b4	DnldMgr	Error 0x80244019 occurred while
downloading update; notifying dependent calls.
2009-10-06	11:11:00:195	1108	16b8	AU	>>##  RESUMED  ## AU: Download update
[UpdateId = {6E4A30FE-29B6-4328-9D47-C7FBE6B7B7E8}]
2009-10-06	11:11:00:195	1108	16b8	AU	  # WARNING: Download failed, error =
0x80244019
2009-10-06	11:11:00:195	1108	16b8	AU	#########
2009-10-06	11:11:00:195	1108	16b8	AU	##  END  ##  AU: Download updates
2009-10-06	11:11:00:195	1108	16b8	AU	#############
2009-10-06	11:11:00:195	 800	1678	CltUI	AU client got new directive =
'Shutdown', serviceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, return =
0x00000000
2009-10-06	11:11:00:305	1108	fcc	AU	AU received handle event
2009-10-06	11:11:05:196	1108	f24	Report	REPORT EVENT:
{68765891-8C7D-4363-9C4C-59DE1AFCDBE3}	2009-10-06
11:11:00:195-0400	1	161	101	{6E4A30FE-29B6-4328-9D47-C7FBE6B7B7E8}	101	80244019	AutomaticUpdates	Failure	Content Download	Error: Download failed.
2009-10-06	11:12:28:048	1108	f24	Report	Uploading 14 events using cached
cookie, reporting URL = http://<fqdn
removed>/ReportingWebService/ReportingWebService.asmx
2009-10-06	11:12:28:064	1108	f24	Report	Reporter successfully uploaded 14
events.




PA Bear [MS MVP] replied to rvvisse on 13-Oct-09 03:29 PM
[[ Right pew, wrong church.  Forwarded to WSUS newsgroup
(microsoft.public.windows.server.update_services) via crosspost as a
convenience to OP.

On the web:
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.windows.server.update_services

In your newsreader:
]]
Lawrence Garvin [MVP] replied to PA Bear [MS MVP] on 13-Oct-09 04:21 PM
If the file is physically present, but the URL produces a '404' error from
all locations, then there is really only two possibilities:

[a] The URL is incorrect.

[b] The URL is being resolved to an incorrect IP Address.


[a] can occur if you have renamed the WSUS Server, updated the DNS, but not
properly dealt with the necessary requirements of renaming a WSUS Server.

[b] can occur if the DNS is simply incorrect, or since you are dealing with
client machines in a different forest, your FQDN may be getting resolved to
an external address, rather than an internal one.

[c] in addition, using FQDNs for internal use runs the risk that that
traffic is getting bounced through a proxy server, which is one more
possible avenue for dysfunction, and if the proxy server is configured to
block EXE downloads -- an HTTP 404 might be an expected response.


Given,  however, that this behavior is being exhibited ON the WSUS Server -
I'd suggest we start by troubleshooting the problem from there, and ignore
all of the other client machines until it is possible for the WSUS Server to
see it is own locally hosted virual directory.

1. Verify that the WSUS Server can properly resolve the FQDN of the WSUS
Server to the IP Address of the WSUS Server.

2. Confirm that FQDN-named traffic is not being unnecessarily routed through
a proxy server. (Or, a simpler solution, do not use FQDN URLs for internal
use, use simple hostnames, aliased through DNS (if necessary), and ensure
that clients have properly configured Domain Name Suffixes and are properly
appending the correct Domain Name Suffix(es) in their DNS Search Order
configuration.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
rvvisse replied to Lawrence Garvin [MVP] on 13-Oct-09 04:54 PM
Using FQDN was misleading.  This was actually a machine name and I have also
tried changing the machine name to the IP of the wsus server.  The WSUS
server sees that my machines are trying to connect to it, but it says that
the update is 99% complete.  So I know that I am hitting it.  I tried
localhost on the wsus server itself and was still given a 404.

The user we tested with was a domain admin, but is it possible that user
does not have privileges to see this?  Maybe a local admin is needed?

One interesting thing to note, I was not able to locate the "Content"
virtual folder in IIS that these links are pointing to.  The SelfUpdate
folder pointed to the program files/self update/ folder, but these appeared
to have old updates.  This content folder apparently points to the D: drive
in a WSUS directory.  Since it is not my WSUS server I need another admin to
help me take a look, but they seem to think everything is fine on their side.
If necessary I could investigate further tomorrow.

Just a side note: The server that I am working on has some maybe unusual
security settings.  It probably will have sensitive material on it in the
future so this is not exactly a stock installation.  I believe I have enabled
the required services in the GPO.. ie Automatic Updates and BITS, but if
anyone can think of any GPO settings that could make this happen, that would
also be helpful.

Thanks for the quick reply Lawrence!!  I really appreciate your ideas
because I am fresh out!
Lawrence Garvin [MVP] replied to rvvisse on 13-Oct-09 06:32 PM
This sounds to me like WSUS is not installed on this server and you are
looking at "leftovers" from a bad uninstall.

And, btw... "not able to locate the 'Content' virtual directory"... YEP..
that is the cause of the HTTP 404 error... :-/



For what it worth... it is pointless to try to troubleshoot a WSUS Server
with "unusual security settings". There is no documentation anywhere that
addresses the issue of "customizing security settings", and generally
speaking, if you change the security settings on WSUS-related resources, you
*will* break it. Futhermore, if you install WSUS to a machine that is been
improperly "secured", even assuming the installation does not fail, it is
highly improbably that the environment will actually function correctly if
the installation actually succeeds.

My suggestion, based on what you have posted so far, is that you might want to
fully uninstall whatever remnants of whatever WSUS appear to be there, and
install a *fresh* WSUS3SP2 on that system and verify that it is
operational --unless you are able to sort out exactly what is
installed/configured in that environment and identify why things seem to be
missing that should be there.

Further, as to locking down such a server, I'd recommend this process:

[1] Build a *TEST* environment to perform this process the first time.
[2] Install WSUS on a non-custom-secured server and verify all
functionality.
[3] Then, implement desired security enhancements, but be prepared to roll
out of them if WSUS shows indications of dysfunction.

To your point from your original post: "All of the other servers that belong
to the WSUS server do not have problems." This cannot be an accurate
indication if the Content virtual directory is missing from the IIS
configuration. Consider, also, comparing the configuration of these allegely
working machines against the configuration applied to these machines that
are not working.

Also, these two statements seem contradictory .. can you please clarify?:

[1] "I was not able to locate the "Content" virtual folder in IIS that these
links are pointing to."

[2] "This content folder apparently points to the D: drive in a WSUS
directory."


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
rvvisse replied to Lawrence Garvin [MVP] on 13-Oct-09 07:06 PM
Sorry, the unusual security settings I am referring to are on the 14 servers
that we are attempting to add as clients.  These security settings are a part
of DISA's Gold Disk if you are familiar with that.  Basically is a collection
of policy changes and security standards. I was wondering if there were any
policies that could cause this error.

As far as I can tell, the security is minimal on the WSUS server.   The WSUS
server has, I would guess, at least 100 computers that are successfully
receiving updates.  These 14 "client" servers that we are adding have never
been a part of a network and have been added in recently.  We have
successfully gotten other site provided services to work, with windows
updates being the sole exception.

So unfortunately, I am not the administrator of the WSUS server.  I really
only have rights to my 14 clients.  I initially went in with the assumption
the client was the problem, but I am really open to any fixes.

Here is what I found with my brief time with the WSUS server (with the help
of the other admin)....

1) I did not see a "Content" virtual folder in IIS... or I at least missed
it in the time that I had.
2) In searching the computer, I found what my client was looking for... a
folder called 79 and a file named B6549....exe in the D:/WSUS/Content
directory

Thanks again for your help.  I am by no means a WSUS expert and I appreciate
your patience.  Let me know if there is any more information that I could
collect.
Harry Johnston [MVP] replied to rvvisse on 13-Oct-09 09:35 PM
This is a fairly critical point.  If it is not there, WSUS is broken.  If it is,
and if the file you are trying to access exists and is in the right place,
something else is amiss.

You said at one point that the URL you were testing produced a 404 even from the
WSUS server itself.  Could you doublecheck this?  If this is true, and if the
URL is correct and the file exists, then there is definitely a problem with the
WSUS server and you can dump the problem on the administrator. :-)

Harry.
rvvisse replied to Harry Johnston [MVP] on 15-Oct-09 11:49 AM
OK GOT IT!

Here was the problem.  The administrator for the WSUS server had recently
installed Symantec Endpoint protection that OVERWROTE the content folder.
The content folder did exist after all, but it was pointing to the wrong
files.

Once we realized the mistake, they changed the Content folder to point to
the correct path (D:\WSUS\WSUSupdates) and everything magically worked again.

As to why the other 200 clients they have were working... my guess is that
they were pointing to the selfupdate folder as opposed to the content folder.
But that is only a guess.

Thank you so much Lawrence and Harry for your help.  You saved the day.
Lawrence Garvin [MVP] replied to rvvisse on 15-Oct-09 12:06 PM
That'll do it.

This issue with co-existence of SEP and WSUS has been known about for some
time.

(And my apologies for not thinking of SEP -- as many times as it is bitten
people it ought to be higher up on my list.)



Of course, now, the SEP is broken. ;-)



I suspect there is more to it than that. Either those client simply did not
have need to download any files thus had not shown any errors, or they
really were not working and the WSUS Admin was oblivious.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
rvvisse replied to Lawrence Garvin [MVP] on 15-Oct-09 03:36 PM
Yeah they have not deployed any users to the new symantec protection on that
machine so it was not an issue.  They'll have to reinstall using a different
virtual directory.

He told me he just had a new computer/user download all the updates before I
fixed it this morning.  So I do not know.  At this point, everything is
working.  And I am all smiles.  Thanks again.