Self-update is not working
Aaron Tech
working. The error appears several times a day. Is there anyway to fix
this?
![Winfried Sonntag [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXdEqZtpkXz0AFa1lLZBTRauO9fuu7812JL6tBjN90kK4_WHg=s40-c)
Winfried Sonntag [MVP]
> I am recieving and event ID 13042 with a description of: Self-update is not
> working. The error appears several times a day. Is there anyway to fix
> this?
http://wsusinfo.onsitechsolutions.com/articles/020.htm
Winfried
--
http://www.microsoft.com/germany/windowsserver2003/technologien/updateservices/default.mspx
http://www.wsuswiki.com/Home
rwhemme
WSUS is also a client and I am also getting the 13042 event ID.
Mine occur every 12 hours. I have checked all suggestions I've run across,
ie: self-update and the permissions, etc. My 'client' reports without issue,
my WSUS will sync every morning as I've scheduled, etc. Everything that I
can tell is set up, configured and working just fine, so why would I still be
getting a 13042?
Thanks in advance for any assistance!
"Lawrence Garvin" wrote:
> "Winfried Sonntag [MVP]" <Winfried...@gmx.de> wrote in message
> news:1uvv3sor8nwc2$.dlg@ID-163725.user.individual.de...
> > Aaron Tech schrieb:
> >
> >> I am recieving and event ID 13042 with a description of: Self-update is
> >> not
> >> working. The error appears several times a day. Is there anyway to fix
> >> this?
> >
> > http://wsusinfo.onsitechsolutions.com/articles/020.htm
>
> These days, the most common reason for this error is that the server has
> been recently upgraded to WSUS 3.0 SP1, and the installer bleated the
> /selfupdate virtual directory.
>
> If that's the case:
> 1. Create a virtual directory called 'selfupdate'.
> 2. Set the path to C:\Program Files\Update Services\selfupdate
> 3. Enable anonymous access on the 'selfupdate' virtual directory.
>
> --
> Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
> Senior Data Architect, APQC, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2008)
>
> 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
>
Lawrence Garvin (MVP)
news:FE4BE1B0-62FE-4BCD...@microsoft.com...
>I am running WSUS 3.0 sp1 on a Server 2003 Standard. The Server hosting my
> WSUS is also a client and I am also getting the 13042 event ID.
>
> Mine occur every 12 hours. I have checked all suggestions I've run
> across,
> ie: self-update and the permissions, etc. My 'client' reports without
> issue,
> my WSUS will sync every morning as I've scheduled, etc. Everything that I
> can tell is set up, configured and working just fine, so why would I still
> be
> getting a 13042?
>
> Thanks in advance for any assistance!
1. Please run the Client Diagnostic Tool on your WSUS Server and post the
results.
2. Please post the *actual* 13042 events you're receiving on your WSUS
Server.
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
rwhemme
*****
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.784. . . . . . . . . . . . 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://WSUSServerName:8530
WUStatusServer = http://WSUSServerName:8530
UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
Connection to server. . . . . . . . . . . . . . . . . . PASS
WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
&downloadBuffe
r) failed with hr=0x80190190
No Error description could be found
Press Enter to Complete
*****
Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
Date: 11/21/2008
Time: 3:24:49 PM
User: N/A
Computer: XXXXX
Description:
Self-update is not working.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
Date: 11/21/2008
Time: 9:24:40 AM
User: N/A
Computer: XXXXX
Description:
Self-update is not working.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
Date: 11/21/2008
Time: 3:24:37 AM
User: N/A
Computer: XXXXX
Description:
Self-update is not working.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
Date: 11/20/2008
Time: 9:24:34 PM
User: N/A
Computer: XXXXX
Description:
Self-update is not working.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
Date: 11/20/2008
Time: 3:24:31 PM
User: N/A
Computer: XXXXX
Description:
Self-update is not working.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
*****
Thanks again in advance!
Lawrence Garvin (MVP)
> Here are the results as requested:
> Checking Connection to WSUS/SUS Server
> WUServer = http://WSUSServerName:8530
> WUStatusServer = http://WSUSServerName:8530
> UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
> Connection to server. . . . . . . . . . . . . . . . . . PASS
>
> WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
> &downloadBuffer) failed with hr=0x80190190
This 0x80190190 error is an HTTP 400 error. An HTTP 400 error is returned
when the server gets a bad request.
You can get specific details about the exact nature of the '400' error from
the IIS logs for the Default Web Site.
Since you've opted to *HIDE* the URL... which, unfortunately, is critical to
diagnosing this error any further,
there's nothing more I can do than point out that you have a defective URL.
Why it's defective I cannot say.
rwhemme
know that is correct. All my other clients do not show this error. I just
didn't know if this was common with the client that was also the WSUS server.
As far as the Event Viewer logs, it correctly stated the name of the client
(which again is also where the WSUS is installed).
rwhemme
But, just to reiterate, the WSUS Server name and the 'Client' in question
are the same.
Also, I just got done going through the registry on the client, and all the
settings are good there as well. The settings are pointed to the correct
URL, etc. When I check the WidowsUpdate log entries, the self-check to see
if it needs self-update or not comes back as no, as the self-update client is
a newer revision that what is required (7.2 & 7.1 respectfully).
As I said, everything appears to be normal, but I continually get the same
event at 3:30 and again at 9:30, and then again 12 hours apart, telling me
self-update is not working.
I am currently having a difficult time covering up the keyboard marks on my
forehead! This is just really bugging me ... sorry for the rant and thanks
in advance for your help.
Lawrence Garvin (MVP)
> Sorry - no edit button ...
>
> But, just to reiterate, the WSUS Server name and the 'Client' in question
> are the same.
>
> Also, I just got done going through the registry on the client, and all
> the
> settings are good there as well. The settings are pointed to the correct
> URL, etc. When I check the WidowsUpdate log entries, the self-check to
> see
> if it needs self-update or not comes back as no, as the self-update client
> is
> a newer revision that what is required (7.2 & 7.1 respectfully).
>
> As I said, everything appears to be normal, but I continually get the same
> event at 3:30 and again at 9:30, and then again 12 hours apart, telling me
> self-update is not working.
>
> I am currently having a difficult time covering up the keyboard marks on
> my
> forehead! This is just really bugging me ... sorry for the rant and
> thanks
> in advance for your help.
>> > Here are the results as requested:
>>
>> > Checking Connection to WSUS/SUS Server
>> > WUServer = http://WSUSServerName:8530
>> > WUStatusServer = http://WSUSServerName:8530
>> > UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
>> > Connection to server. . . . . . . . . . . . . . . . . . PASS
>> >
>> > WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
>> > &downloadBuffer) failed with hr=0x80190190
>>
>> This 0x80190190 error is an HTTP 400 error. An HTTP 400 error is returned
>> when the server gets a bad request.
Okay.. let's bypass your HTTP 400 for the moment...
Verify that there is a 'selfupdate' virtual directory in the "Default Web
Site" on the WSUS Server.
Verify that there is a 'selfupdate' virtual directory in the "WSUS
Administration" website on the WSUS Server.
Verify that both instances of the 'selfupdate' virtual directory have
Anonymous Access enabled.
>> You can get specific details about the exact nature of the '400' error
>> from
>> the IIS logs for the Default Web Site.
Run the Client Diagnostic Tool again on the WSUS Server. Note the time.
Inspect the IIS logs... find the log entry for the HTTP 400 error that is
being returned to the WSUS Server at the time the Client Diagnostic Error
was encountered.
Post the log entry. DO NOT EDIT the log entry!
rwhemme
> Verify that there is a 'selfupdate' virtual directory in the "Default Web
> Site" on the WSUS Server.
>
> Verify that there is a 'selfupdate' virtual directory in the "WSUS
> Administration" website on the WSUS Server.
>
> Verify that both instances of the 'selfupdate' virtual directory have
> Anonymous Access enabled.
>
With regard to the IIS logs, which one am I looking for specifically? I ran
the diag tool on the client / server and noted the time, but when I went to
c:\windows\system32\logfiles\w3svc1, the log is empty. Am I looking in the
wrong place?
Lawrence Garvin (MVP)
> With regard to the IIS logs, which one am I looking for specifically?
The IIS Logs for the "Default Web Site" and the "WSUS Administration"
website.
> I ran
> the diag tool on the client / server and noted the time, but when I went
> to
> c:\windows\system32\logfiles\w3svc1, the log is empty. Am I looking in
> the
> wrong place?
There should be a w3svc2 folder for the "WSUS Administration" website.
rwhemme
(c:\windows\system32\logfiles\), then no, there is no w3svc2 folder. There
is the w3svc1 folder, and various other folders that start with w3svc1, but
then have other numbers at the end of the file name (ex: W3SVC124299038).
Although, I think I may have sumbled onto what was causing my issue, but I'm
not positive yet. I was able to prove network connectivity by opening up IE
on the client and going to: http://lmcit:8530/selfupdate/wuinect.cab, which
prompted me to d/l the cab file. Although this tested fine, I was still
getting the 13042 event.
But after checking to make sure (yet again) that everything was set to
Anonymous Access (which they were), the WSUS selfupdate directory also had
the 'Integrated Windows Authentication' checked.
I have unchecked that particular box and am hopeful that is what was causing
the events to appear. If that does not resolve it, I am at a complete and
total loss.
Your input?
Thanks in advance
rwhemme
for the
"WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
&downloadBuffer) failed with hr=0x80190190
No Error description could be found
Press Enter to Complete"
But if I'm going to get a 13042 again, it'll occur within the next 10
minutes or so ...
Lawrence Garvin (MVP)
> If I have been looking in the correct directory
> (c:\windows\system32\logfiles\), then no, there is no w3svc2 folder.
> There
> is the w3svc1 folder, and various other folders that start with w3svc1,
> but
> then have other numbers at the end of the file name (ex: W3SVC124299038).
Okay.. my mistake. (I knew better, was just being brain-dead.)
*One* of those other numbered folders is the folder for the "WSUS
Administration" website.
To find the correct folder, open the Properties dialog for the "WSUS
Administration"website. In the logging section of the Web Site tab, click on
Properties. This will open the Logging Properties dialog. At the very bottom
of that dialog, the web site filename is listed.
To find the correct number,
rwhemme
this won’t be the Great American Novel, but I do want to try and include as
much information as possible for easier trouble shooting, so I hope I’ve
included the right stuff, so here we go…
I located the correct log file and ran the diag on the client/server (noting
the time as 9:13 am), which also gave me the same results as last time.
I’ve included the segment of the IIS log right before to right after,
although it states the time as being 15:13 (3:13 pm)? In looking through the
log, I didn’t see anything in reference to an HTTP 400 error, but maybe there
is something in there that your eyes can pick up that these newbie’s don’t
see…
=========
2008-11-26 15:12:00 172.16.17.6 POST /SimpleAuthWebService/SimpleAuth.asmx -
8530 - 172.16.17.111 Windows-Update-Agent 200 0 0
2008-11-26 15:12:00 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.111 Windows-Update-Agent 200 0 0
2008-11-26 15:12:00 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.111 Windows-Update-Agent 200 0 0
2008-11-26 15:12:00 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.111 Windows-Update-Agent 200 0 0
2008-11-26 15:12:01 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.111 Windows-Update-Agent 200 0 0
2008-11-26 15:12:34 172.16.17.6 POST
/ReportingWebService/ReportingWebService.asmx - 8530 - 172.16.17.6
Windows-Update-Agent 200 0 0
2008-11-26 15:12:44 172.16.17.6 HEAD /selfupdate/wuident.cab 0811261512 8530
- 172.16.17.70 Windows-Update-Agent 200 0 0
2008-11-26 15:12:44 172.16.17.6 HEAD
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0811261512 8530 - 172.16.17.70
Windows-Update-Agent 200 0 0
2008-11-26 15:12:44 172.16.17.6 GET
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0811261512 8530 - 172.16.17.70
Windows-Update-Agent 200 0 0
2008-11-26 15:12:46 172.16.17.6 POST
/ReportingWebService/ReportingWebService.asmx - 8530 - 172.16.47.100
Windows-Update-Agent 200 0 0
2008-11-26 15:12:50 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.70 Windows-Update-Agent 200 0 0
2008-11-26 15:12:50 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.70 Windows-Update-Agent 200 0 0
2008-11-26 15:13:05 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.70 Windows-Update-Agent 200 0 0
2008-11-26 15:13:34 172.16.17.6 POST /SimpleAuthWebService/SimpleAuth.asmx -
8530 - 172.16.17.101 Windows-Update-Agent 200 0 0
2008-11-26 15:13:34 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.101 Windows-Update-Agent 200 0 0
2008-11-26 15:13:34 172.16.17.6 POST
/ReportingWebService/ReportingWebService.asmx - 8530 - 172.16.17.101
Windows-Update-Agent 200 0 0
2008-11-26 15:13:38 172.16.17.6 GET /clientwebservice/wusserverversion.xml -
8530 - 172.16.17.6 Windows-Update-Agent 200 0 0
2008-11-26 15:14:08 172.16.17.6 POST
/ReportingWebService/ReportingWebService.asmx - 8530 - 172.16.64.200
Windows-Update-Agent 200 0 0
2008-11-26 15:14:12 172.16.17.6 POST
/ReportingWebService/ReportingWebService.asmx - 8530 - 172.16.21.25
Windows-Update-Agent 200 0 0
2008-11-26 15:14:12 172.16.17.6 HEAD /selfupdate/wuident.cab 0811261514 8530
- 172.16.17.51 Windows-Update-Agent 200 0 0
2008-11-26 15:14:12 172.16.17.6 HEAD
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0811261514 8530 - 172.16.17.51
Windows-Update-Agent 200 0 0
2008-11-26 15:14:12 172.16.17.6 GET
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0811261514 8530 - 172.16.17.51
Windows-Update-Agent 200 0 0
2008-11-26 15:14:19 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.51 Windows-Update-Agent 200 0 0
2008-11-26 15:14:19 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.51 Windows-Update-Agent 200 0 0
2008-11-26 15:14:19 172.16.17.6 POST /ClientWebService/client.asmx - 8530 -
172.16.17.51 Windows-Update-Agent 200 0 0
=========
Now for the other ‘stuff’ – Default website is set to a static IP:80 and has
the IUSR in the permissions with read/execute, list folder contents & read,
and has write denied. The WSUS site shows an IP of “(All Unassigned)”:8530
with the SSL port 8531. It does NOT have the IUSR listed in permissions,
just shows Administrator, Authenticated Users, Network Service, System &
Users.
The IUSR is also not listed in the permissions for the Default Self Update
virtual directory, or in the WSUS Content (although does have a WSUS Admin)
or in the WSUS Self Update directories.
For the authentication under properties, the WSUS Content directory is the
only that has the enable Anonymous access checked. The Default, Default Self
Update, WSUS and WSUS Self Update directories have the enable Anonymous
access along with the Integrated Windows authentication checked.
My question regarding that is all the directories have the Anonymous access,
but what is the purpose of also having the Integrated Windows access? Is
that a security thing? My Supervisor likes to have a very secure shop (and
not that I blame her), but I just want to know what the Integrated Windows
access is for.
And finally (I think), when I go to the client and open IE and run
http://lmcit:8530/selfupdate/wuinect.cab, I get an error, but when I do the
same thing, but run http://YourWSUSServer:Port/selfupdate/iuident.cab, I get
prompted to download that cab file.
With all that being said, unless I am missing something within the process
itself, it does report to my console as expected, it has the current self
update client, and did successfully receive the last round of updates, so I
guess that is why I am so confused and frustrated that I am consistently
getting that 13042 event regarding the Self-Update Client not working.
Thank you yet again for your time and your input. It is HIGHLY appreciated!
DaveMills
wrote:
>Now for the other ‘stuff’ – Default website is set to a static IP:80 and has
Do you mean the web site is set to listen on a fixed IP and not "All
Unassigned"? IIRC you need both the IP and "localhost" which is why "All
Unassigned" is the default setting for WSUS"
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
rwhemme
Unassigned" to match the WSUS Website? If so, should that resolve my issue?
Thanks in advance.
DaveMills
wrote:
>If I'm understanding you correctly, the Default Website should be set to "All
>Unassigned" to match the WSUS Website? If so, should that resolve my issue?
I do not know what else you web server has to do but I would at least try that
to see if it solves you issue. Certainly WU needs Localhost and that does not
match a fixed ip
KumarSundaram
I had the same problem running WSUS 3.1. All clients would check in fine and
everything except I kept getting "Self-update is not working" event.
I am running WSUS on 8530 and on the default port 80 we have a Intranet site
running. All I did was created a "SelfUpdate" Virtual Directory under the
Intranet site and (although there is one already exists under "WSUS
Administration) pointed the virtual directory to C:\Program Files\Update
Services\Selfupdate and gave anonymous access (read).
I restarted the default website, WSUS Administration and finally the update
services. The error has gone away and everything appears to be normal.
I hope this helps.
Lawrence Garvin (MVP)
news:A144CEE3-0404-4FA2...@microsoft.com...
> Hi Everyone!
>
> I had the same problem running WSUS 3.1. All clients would check in fine
> and
> everything except I kept getting "Self-update is not working" event.
>
> I am running WSUS on 8530 and on the default port 80 we have a Intranet
> site
> running. All I did was created a "SelfUpdate" Virtual Directory under the
> Intranet site and (although there is one already exists under "WSUS
> Administration) pointed the virtual directory to C:\Program Files\Update
> Services\Selfupdate and gave anonymous access (read).
>
> I restarted the default website, WSUS Administration and finally the
> update
> services. The error has gone away and everything appears to be normal.
Kumar, while your remediation is certainly the correct steps to take for the
"Selfupdate not working" scenario, in the other case here, the issue is an
HTTP 400 error message attempting to access the selfupdate content. If the
selfupdate virtual directory were simply missing, IIS would have returned an
HTTP 401 error (0x80190191).
In fact, the HTTP 400 (0x80190190) is caused by an invalid request -- most
likely as a result of a defective URL configured for the WSUS Server, or a
proxy server that is mangling the URL en route to the WSUS Server.
>> "WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL,
>> &downloadBuffer) failed with hr=0x80190190