WSUS Download failed, error = 0x80244019

All,

I've tried quite a few things to fix this issue, but I've 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've 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's 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've 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\a6e4ed991 77b5f95ba446c3066c7e5e3\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.

[[ 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...pdate_services

In your newsreader:
news://msnews.microsoft.com/microsof...pdate_services
]]


rvvisse wrote:
> All,
>
> I've tried quite a few things to fix this issue, but I've 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've 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's 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've 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\a6e4ed991 77b5f95ba446c3066c7e5e3\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.

>rvvisse wrote:

>> We're trying to add a new forest of 14 servers

>> - The file is not physically missing on the wsus server, it's 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

>> Can any one help? I've been working on this for longer than a week

If the file is physically present, but the URL produces a '404' error from
all locations, then there's really only two possibilities:

[a] The URL is incorrect.

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

>> 2009-10-06 11:11:00:180 1108 14b4 DnldMgr Failed job file: URL =
>> http://<fqdn
>> removed>/Content/79/B65495BD42C584D905A9A4C5E4D643BD75D5A679.exe,

[a] can occur if you've 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're 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's possible for the WSUS Server to
see it's 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/pro...awrence.Garvin

Using FQDN was misleading. This was actually a machine name and I've 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'm 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's 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'm working on has some maybe unusual
security settings. It probably will have sensitive material on it in the
future so this isn't 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'm fresh out!

> If the file is physically present, but the URL produces a '404' error from
> all locations, then there's really only two possibilities:
>
> [a] The URL is incorrect.
>
> [b] The URL is being resolved to an incorrect IP Address.
>
> >> 2009-10-06 11:11:00:180 1108 14b4 DnldMgr Failed job file: URL =
> >> http://<fqdn
> >> removed>/Content/79/B65495BD42C584D905A9A4C5E4D643BD75D5A679.exe,
>
> [a] can occur if you've 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're 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's possible for the WSUS Server to
> see it's 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/pro...awrence.Garvin
>

"rvvisse" <> wrote in message
news:91D7E62F-010F-4BEB-9F16-...

> 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's 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.

This sounds to me like WSUS is not installed on this server and you're
looking at "leftovers" from a bad uninstall.

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


> Just a side note: The server that I'm working on has some maybe unusual
> security settings. It probably will have sensitive material on it in the
> future so this isn't 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.

For what it worth... it's 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's been
improperly "secured", even assuming the installation doesn't fail, it's
highly improbably that the environment will actually function correctly if
the installation actually succeeds.

My suggestion, based on what you've 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's
operational --unless you're 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/pro...awrence.Garvin

Sorry, the unusual security settings I'm 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're 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'm really open to any fixes.

Here's 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'm by no means a WSUS expert and I appreciate
your patience. Let me know if there's any more information that I could
collect.

"Lawrence Garvin [MVP]" wrote:

> "rvvisse" <> wrote in message
> news:91D7E62F-010F-4BEB-9F16-...
>
> > 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's 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.
>
> This sounds to me like WSUS is not installed on this server and you're
> looking at "leftovers" from a bad uninstall.
>
> And, btw... "not able to locate the 'Content' virtual directory"... YEP..
> that's the cause of the HTTP 404 error... :-/
>
>
> > Just a side note: The server that I'm working on has some maybe unusual
> > security settings. It probably will have sensitive material on it in the
> > future so this isn't 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.
>
> For what it worth... it's 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's been
> improperly "secured", even assuming the installation doesn't fail, it's
> highly improbably that the environment will actually function correctly if
> the installation actually succeeds.
>
> My suggestion, based on what you've 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's
> operational --unless you're 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/pro...awrence.Garvin
>

rvvisse wrote:

> Here's 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.

This is a fairly critical point. If it isn't there, WSUS is broken. If it is,
and if the file you're 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.


> 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'm by no means a WSUS expert and I appreciate
> your patience. Let me know if there's any more information that I could
> collect.
>
> "Lawrence Garvin [MVP]" wrote:
>
>> "rvvisse" <> wrote in message
>> news:91D7E62F-010F-4BEB-9F16-...
>>
>>> 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's 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.
>> This sounds to me like WSUS is not installed on this server and you're
>> looking at "leftovers" from a bad uninstall.
>>
>> And, btw... "not able to locate the 'Content' virtual directory"... YEP..
>> that's the cause of the HTTP 404 error... :-/
>>
>>
>>> Just a side note: The server that I'm working on has some maybe unusual
>>> security settings. It probably will have sensitive material on it in the
>>> future so this isn't 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.
>> For what it worth... it's 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's been
>> improperly "secured", even assuming the installation doesn't fail, it's
>> highly improbably that the environment will actually function correctly if
>> the installation actually succeeds.
>>
>> My suggestion, based on what you've 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's
>> operational --unless you're 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/pro...awrence.Garvin
>>

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's only a guess.

Thank you so much Lawrence and Harry for your help. You saved the day.

"Harry Johnston [MVP]" wrote:

> rvvisse wrote:
>
> > Here's 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.
>
> This is a fairly critical point. If it isn't there, WSUS is broken. If it is,
> and if the file you're 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.
>
>
> > 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'm by no means a WSUS expert and I appreciate
> > your patience. Let me know if there's any more information that I could
> > collect.
> >
> > "Lawrence Garvin [MVP]" wrote:
> >
> >> "rvvisse" <> wrote in message
> >> news:91D7E62F-010F-4BEB-9F16-...
> >>
> >>> 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's 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.
> >> This sounds to me like WSUS is not installed on this server and you're
> >> looking at "leftovers" from a bad uninstall.
> >>
> >> And, btw... "not able to locate the 'Content' virtual directory"... YEP..
> >> that's the cause of the HTTP 404 error... :-/
> >>
> >>
> >>> Just a side note: The server that I'm working on has some maybe unusual
> >>> security settings. It probably will have sensitive material on it in the
> >>> future so this isn't 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.
> >> For what it worth... it's 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's been
> >> improperly "secured", even assuming the installation doesn't fail, it's
> >> highly improbably that the environment will actually function correctly if
> >> the installation actually succeeds.
> >>
> >> My suggestion, based on what you've 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's
> >> operational --unless you're 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/pro...awrence.Garvin
> >>
>

"rvvisse" <> wrote in message
news:2122A0FB-5DE1-4D40-94F6-...
> 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.

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's bitten
people it ought to be higher up on my list.)


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

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


> 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.

I suspect there's 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 weren't 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/pro...awrence.Garvin

Yeah they haven't deployed any users to the new symantec protection on that
machine so it wasn't 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 don't know. At this point, everything's
working. And I'm all smiles. Thanks again.

"Lawrence Garvin [MVP]" wrote:

> "rvvisse" <> wrote in message
> news:2122A0FB-5DE1-4D40-94F6-...
> > 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.
>
> 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's bitten
> people it ought to be higher up on my list.)
>
>
> > Once we realized the mistake, they changed the Content folder to point to
> > the correct path (D:\WSUS\WSUSupdates) and everything magically worked
> > again.
>
> Of course, now, the SEP is broken. ;-)
>
>
> > 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.
>
> I suspect there's 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 weren't 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/pro...awrence.Garvin
>