Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 13042 Source: WindowsServerUpdateServices

Self-update is not working.
EV100621 (Windows Update Services – Multiple Errors in Event Viewer) provides a solution for this type of problem (the steps the reconfigure WSUS).
ME2000598 indicates that on SBS this issue can occur if the Default Web Site is not running and/or has a site binding for SSL (HTTPS).
See EV100404 (WSUS KB2720211 : Common issues encountered and how to fix them) on suggestions about troubleshooting WSUS.
In my case the solution was very simple but took me hours to find. Our WSUS server has two network cards (LAN, WAN). The IIS was only bound to the internal IP and localhost address ( to allow internal access and avoid access from WAN. WSUS seems not to work when the IIS web is not bound to "all addresses".
I was getting a bunch of errors: 12002, 12032, 12022, 12042, 12052 for WSUS 3.0 SP1. I fixed this by enabling the iusr_serverx account in AD that was being used for anonymous authentication by this is IIS. (For added security, change the password then you have to change in IIS, Directory Security, Authentication & access control, as well).

Also, another possible resolution - remove the GUESTS account from the USER RIGHTS

Verify if the anonymous account you are using (IUSR_Server) is not deactivated (locked out) by accident.
The issue on our 2008 IIS 7 server was that all but the IPv6 local IP [::1] was bound to the default website. Once [::1] was bound to the website the error when away.
Check that you don't have a Group Policy which prevents remote logon to the the "guests" group. If you do - remove the IUSR_xxxxx account from the guests group on the local machine and restart IIS (iisreset). Seems to be an issue when updating from 2.x-3.x.
In my case I found the sollution here: EV100327 (Event Viewer Errors 13042 13002 12002 12042 12052). The solution was  to give WRITE access to Network Service on the folder %systemroot%\Temp.
I was receiving Event IDs 13042, 12002, 12012, 12032, 12022, 12042, and 12052. WSUS was installed on a machine that also had Exchange installed and was using the default website (on port 80) for web mail. The WSUS Administration site was set up on 8350, as per usual and all settings (security and registry) looked correct. I was playing around with wsusutil.exe and found a command option called "usecustomwebsite". Even though the registry setting was for port 8530, I went ahead and ran it (from C:\Program Files\Update Services\Tools): wsusutil.exe usecustomwebsite. After this, I ran wsusutil.exe checkhealth and all of the errors disappeared. Apparently usecustomwebsite does some changes other than the registry which seems to have fixed my problem.
In my case we were using RPCoHTTP with an SSL Cert and the Default Website was configured to Require Secure channel (SSL) and Require 128-bit encryption under Directory security.  Removing require secure channel (SSL) from the self-update virtual directory resolved the issue.
I saw these errors on a DC that had just been upgraded to Win2003 SP2. After 10 minutes, the error was corrected automatically and the event log said all websites were working now. This is shown in information events 13040, 12000, 12010, 12030, 12020, 12040 and 12050.
The following fixed the problem in my case. In IIS Manager, go to Default website > Selfupdate > Right-click Properties > Directory Security tab > IP addres and Domain restriction EDIT > and check "by default all computers will be" "GRANTED ACCESS".
I had the same problem with WSUS reporting a string of errors as shown below:

Self-update is not working.
The Reporting Web Service is not working.
The API Remoting Web Service is not working.
The Server Synchronization Web Service is not working.
The Client Web Service is not working.
The SimpleAuth Web Service is not working.
The DSS Authentication Web Service is not working.

The WSUS clientdiag.exe tool said everything was fine from the client end, but there were no updates to see. Do the following to fix the problem: Open IIS Manager, right click the Default Web Site, and look at the properties tab. The port should be 80, or whatever you use as the default http port. I was not using https. Click the Directory Security tab -> click Edit under Secure Communications and uncheck Require Secured Communications. You should also check that the selfupdate subdirectory has this unchecked if you are using http and not https. Now go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup. Check that the PortNumber is set to 80 (Decimal) or 50 (Hex). Check that UsingSSL is set to 0 (if you are not using SSL). Restart the services and the problem should be solved.

I found that the permissions on the Default Website in IIS had been changed. Right-click Default Website --> Permissions. Add in IUSR_servername and give it Read & Execute, List Folder Contents and Read permissions. Deny write permissions. This got mine working.
Event though this is the first error to show up in Event Viewer, the root cause in our case was that the default website could not start since some other service was using port 80. Once we changed the port on the default website and started it, this problem disappeared.
Make sure the IP address restriction exceptions for the virtual directory are configured for the server's actual IP. Go to the Selfupdate virtual directory Properties, click "Edit" under IP address and domain name restrictions. If the server's IP is not listed under the exceptions, self update will fail. You can run into this problem if you change the server's ip address after the initial installation. Do not forget to check the root "Default web sites" as well.
In my case, it was anonymous permissions in IIS on the selfupdate virtual directory. I added Everyone rights to the "\program files\update services\selfupdate" folder as well. To force a check to see if it fixes your problem, run "wsusutil.exe checkhealth" from "C:\Program Files\Update Services\Tools". Check the application logs afterwards.
From a newsgroup post: "Make sure the value for PortNumber under the "HKLM\SOFTWARE\Microsoft\Update Services\Server\Setup" key is set to the correct port (the one your WSUS site is on)".
WSUS requires that a "SelfUpdate" virtual directory exist on the website that is hosted on port 80. Even if you have your WSUS site running on port 8530 for example, you need to create a virtual directory within the site on port 80 called "Selfupdate" and map it to C:\program files\update services\selfupdate. Make sure you allow anonymous users access on the Directory Security tab as well as allow directory browsing. See the link to “WSUS: SelfUpdate Tree is not working” for the full article.
This error occurred when I upgraded WSUS from WSUS 2 to WSUS 3. I fixed this error by going to Control Panel -> Administrative Tools -> Internet Information Services (IIS) Manager. In IIS open "Default Web Site", click "Properties" on SelfUpdate, go to Directory Security -> Authentication and Access Control and enable Anonymous access for user IUSR.
ME920659 has information that may prove helpful for this problem.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.