Error 13042 Windows Update is not working

Hi:
I've had error 13042 show up in the Application logs of my server running
WSUS.
I found other messages on this thread, and reset directory permissions of
the SelfUpdate directory of my Default IIS site and my Windows Update IIS
site as indicated (anonymous access using IUSR_Servername)

That made the problem go away for a few weeks, but now it's returned.
Any other ideas?

Thanks,
Tony

As a follow up to this problem, the Client Diagnostic Tool run on this server
gives me this:


WSUS Client Diagnostics Tool

Checking Machine State
Checking for admin rights to run tool . . . . . . . . . PASS
Automatic Updates Service is running. . . . . . . . . . PASS
Background Intelligent Transfer Service is running. . . PASS
Wuaueng.dll version 7.2.6001.788. . . . . . . . . . . . PASS
This version is WSUS 2.0

Checking AU Settings
AU Option is 4: Scheduled Install . . . . . . . . . . . PASS
Option is from Policy settings

Checking Proxy Configuration
Checking for winhttp local machine Proxy settings . . . PASS
Winhttp local machine access type
<Direct Connection>
Winhttp local machine Proxy. . . . . . . . . . NONE
Winhttp local machine ProxyBypass. . . . . . . NONE
Checking User IE Proxy settings . . . . . . . . . . . . PASS
User IE Proxy. . . . . . . . . . . . . . . . . NONE
User IE ProxyByPass. . . . . . . . . . . . . . NONE
User IE AutoConfig URL Proxy . . . . . . . . . NONE
User IE AutoDetect
AutoDetect not in use

Checking Connection to WSUS/SUS Server
WUServer = http://server2:8530
WUStatusServer = http://server2:8530
UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
Connection to server. . . . . . . . . . . . . . . . . . PASS

WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
&downloadBuffe
r) failed with hr=0x80190194

No Error description could be found


Thanks for your help,

Tony




"Tone-man 123" wrote:

> Hi:
> I've had error 13042 show up in the Application logs of my server running
> WSUS.

"Tone-man 123" <> wrote in message
news:581F9A25-2AC8-4054-A923-...
> As a follow up to this problem, the Client Diagnostic Tool run on this
> server
> gives me this:

> Checking Connection to WSUS/SUS Server
> WUServer = http://server2:8530
> WUStatusServer = http://server2:8530
> UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
> Connection to server. . . . . . . . . . . . . . . . . . PASS
>
> WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
> &downloadBuffer) failed with hr=0x80190194

This is not a permissions error.. this is likely a v-dir missing error in
the "Default Web Site"

Verify that the selfupdate folder exists in both the "Default Web Site" and
the "WSUS Administration" virtual servers on IIS.



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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

> This is not a permissions error.. this is likely a v-dir missing error in
> the "Default Web Site"
>
> Verify that the selfupdate folder exists in both the "Default Web Site" and
> the "WSUS Administration" virtual servers on IIS.
>

Yes, this folder exists under both places.
They both point to C:\Program Files\Update Services\SelfUpdate

Thanks,

Tony

"Tone-man 123" <> wrote in message
news:AC23DFCA-79A7-4AC1-BB6E-...

> WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
> &downloadBuffer) failed with hr=0x80190194

>> This is not a permissions error.. this is likely a v-dir missing error in
>> the "Default Web Site"
>>
>> Verify that the selfupdate folder exists in both the "Default Web Site"
>> and
>> the "WSUS Administration" virtual servers on IIS.
>>
>
> Yes, this folder exists under both places.
> They both point to C:\Program Files\Update Services\SelfUpdate

Then:

1. Verify that there is actually content in the C:\Program Files\Update
Services\Selfupdate folder.


and, even though this is a '404' error, not a '401' error...also:

2. Verify that both instances of the 'selfupdate v-dir has anonymous access
enabled.

3. Verify that the NTFS permissions on the C:\Program Files\Update
Services\Selfupdate folder matches that which is documented in the WSUS
Operations Guide.

4. Verify that nothing has been changed on the server with respect to the
IIS_WPG group and the IUSR_MachineName accounts.

> I found other messages on this thread, and reset directory permissions of
> the SelfUpdate directory of my Default IIS site and my Windows Update IIS
> site as indicated (anonymous access using IUSR_Servername)

And.. can you provide explicit details on what you did with reference to
"reset directory permissions of the Selfupdate directory" and WHY you did
that (since there's no legitimate procedure anywhere that calls for changing
those permissions, or any issue which has resulted in those permissions
being incorrectly changed - except by inappropriate human interaction).

I'm inclined to believe that you have complicated this problem with the
things you did trying to fix it without first properly identifying the
actual cause of the issue.

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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Hi Lawrence:
Thanks for your repsonse.

> 1. Verify that there is actually content in the C:\Program Files\Update
> Services\Selfupdate folder.
>

In that directory there is:
AU directory
WSUS3 direcory
iuident.cab
wuident.cab

If you drill down through the directories, you find other cab files.


>
> and, even though this is a '404' error, not a '401' error...also:
>
> 2. Verify that both instances of the 'selfupdate v-dir has anonymous access
> enabled.
>

Yes.

> 3. Verify that the NTFS permissions on the C:\Program Files\Update
> Services\Selfupdate folder matches that which is documented in the WSUS
> Operations Guide.

I found a discrepancy in the rights of the Inventory directory and one of
the registry keys. I reset these as in the manual, restarted the Update
Services service, and I'm still getting the error.
>

> 4. Verify that nothing has been changed on the server with respect to the
> IIS_WPG group and the IUSR_MachineName accounts.
>

I'm not sure what changes I'd be looking for, but that group and user exist.
They look OK.

> > I found other messages on this thread, and reset directory permissions of
> > the SelfUpdate directory of my Default IIS site and my Windows Update IIS
> > site as indicated (anonymous access using IUSR_Servername)
>
> And.. can you provide explicit details on what you did with reference to
> "reset directory permissions of the Selfupdate directory" and WHY you did
> that (since there's no legitimate procedure anywhere that calls for changing
> those permissions, or any issue which has resulted in those permissions
> being incorrectly changed - except by inappropriate human interaction).
>

My apologies for not being clear. When I mentioned resetting permissions, I
was referring to clicking the 'Allow Anonymous Access' box under the vdirs in
IIS Manager, which I did for both the Default Web Site and the WSUS
Administration web site.


> I'm inclined to believe that you have complicated this problem with the
> things you did trying to fix it without first properly identifying the
> actual cause of the issue.

The anonymous access change (above) is the only other change I made.

When I restart the service, I get a 501 Message that Update Services Service
Started. Then about 5 seconds later I get the dreaded 13042 Error.

Thanks for your help,
Tony



>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"Tone-man 123" <> wrote in message
news:F0602E04-D7ED-4F9B-9288-...

>> I'm inclined to believe that you have complicated this problem with the
>> things you did trying to fix it without first properly identifying the
>> actual cause of the issue.
>
> The anonymous access change (above) is the only other change I made.
>
> When I restart the service, I get a 501 Message that Update Services
> Service
> Started. Then about 5 seconds later I get the dreaded 13042 Error.

This error can also be caused when the Update Services service has been
configured to use an account other than the NT AUTHORITY\Network Service
account, which could also be responsible for making the selfupdate content
invisible to the webservices and Client Detection Utility, but fully visible
to a browser.

Please verify that the service is configured to use the correct account.


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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

> This error can also be caused when the Update Services service has been
> configured to use an account other than the NT AUTHORITY\Network Service
> account, which could also be responsible for making the selfupdate content
> invisible to the webservices and Client Detection Utility, but fully visible
> to a browser.
>
> Please verify that the service is configured to use the correct account.
>

Thanks for your reply.
The Update Services Service is using the NT AUTHORITY\Network Service account.

Any other ideas?

"Tone-man 123" <> wrote in message
news:BE74FD38-D4E4-409C-BF92-...
>> This error can also be caused when the Update Services service has been
>> configured to use an account other than the NT AUTHORITY\Network Service
>> account, which could also be responsible for making the selfupdate
>> content
>> invisible to the webservices and Client Detection Utility, but fully
>> visible
>> to a browser.
>>
>> Please verify that the service is configured to use the correct account.
>>
>
> Thanks for your reply.
> The Update Services Service is using the NT AUTHORITY\Network Service
> account.
>
> Any other ideas?

Not based on the current information available on this issue.

So let's go back to the beginning. Pretend this is your very first post, and
tell me *everything* you think is relevant about this issue, and everything
else that might only be possibly remotely relevant. Somewhere in there is a
key piece of information not yet shared that will explain why you are
getting this commonly encountered error that cannot be resolved with
commonly implemented and proven solutions.

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

MS WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

> So let's go back to the beginning. Pretend this is your very first post, and
> tell me *everything* you think is relevant about this issue, and everything
> else that might only be possibly remotely relevant. Somewhere in there is a
> key piece of information not yet shared that will explain why you are
> getting this commonly encountered error that cannot be resolved with
> commonly implemented and proven solutions.
>

OK, thanks. Here's the history of this server.
WSUS was working fine on this server, and then we changed to a new Anti
virus vendor. The AV software had a false positive and quarantined some WSUS
relevant files (I'm not sure which ones). WSUS stopped working.
It took me a while to figure out what happened, but once I did, I updated
the Anti virus engine and definitions. I then had to reload WSUS, at which
point, it started working fine again for a few months. I could synchronize,
see computers, and push out updates. My last update approval was about a
month ago, and it worked fine.