Event Viewer Errors 13042 13002 12002 12042 12052

I'm running WSUS 3.0, not the beta. These errors are on my WSUS server and
promply show when I run: wsusutil checkhealth

All are source: Windows Server Update
Event IDs in order from older to new, but all appearing in the same second.

13042 - Self-update is not working
13002 - Client computers are installing updates with a higher than 25
percent failure rate. This is not normal.
12002 - The Reporting Web Service is not working.
12032 - The Server Synchronization Web Service is not working.
12022 - The Client Web Service is not working.
12042 - The SimpleAuth Web Service is not working.
12052 - The DSS Authentication Web Service is not working.

---------

The server is 2003 standard with sp2.

Originally I was not getting clients to show. I tweaked some folder and IIS
permissions and the clients started show up, but none are receiving the
updates. I've read several articles from MS to see if I can access certain
..cab files through IIS and I can from client machines.

----------------

Any ideas or help would be appreciated. Oh, I also installed the 3.0 update
agent and applied the KB927891 afterwards on all machines on the domain.

"Chris" <Chris@discussions.microsoft.com> wrote in message
news:EF70A1AA-E89F-4A21-956B-C04BD62A9546@microsoft.com...
> I'm running WSUS 3.0, not the beta. These errors are on my WSUS server
> and
> promply show when I run: wsusutil checkhealth
>
> All are source: Windows Server Update
> Event IDs in order from older to new, but all appearing in the same
> second.
>
> 13042 - Self-update is not working
> 13002 - Client computers are installing updates with a higher than 25
> percent failure rate. This is not normal.
> 12002 - The Reporting Web Service is not working.
> 12032 - The Server Synchronization Web Service is not working.
> 12022 - The Client Web Service is not working.
> 12042 - The SimpleAuth Web Service is not working.
> 12052 - The DSS Authentication Web Service is not working.

> I tweaked some folder and IIS
> permissions and the clients started show up, but none are receiving the
> updates.

My gut feeling is that "tweaked some folder" and "IIS permissions" is
probably the key to your issue.

Can you expand on this statement a bit, please?

--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/pr...2-D095EB07B36E

Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

I'm not sure what to expand on. I messed with IIS permissions and folder
permissions to get some errors to go away that are not listed below. Prior
to do the changes, no clients would show up in the MMC snap in. After
messing with permissions, the clients now show up but have a status of not
reported in yet.

I can access the .cab files on the IIS server that are related to WSUS. But
nothing else is working beyond that. I'm unable to find any articles
explaining any of the errors above that work. Google searches show some
people having similiar problems in beta, but no resolutions.

Thanks for any help you can provide.


"Lawrence Garvin (MVP)" wrote:

> "Chris" <Chris@discussions.microsoft.com> wrote in message
> news:EF70A1AA-E89F-4A21-956B-C04BD62A9546@microsoft.com...
> > I'm running WSUS 3.0, not the beta. These errors are on my WSUS server
> > and
> > promply show when I run: wsusutil checkhealth
> >
> > All are source: Windows Server Update
> > Event IDs in order from older to new, but all appearing in the same
> > second.
> >
> > 13042 - Self-update is not working
> > 13002 - Client computers are installing updates with a higher than 25
> > percent failure rate. This is not normal.
> > 12002 - The Reporting Web Service is not working.
> > 12032 - The Server Synchronization Web Service is not working.
> > 12022 - The Client Web Service is not working.
> > 12042 - The SimpleAuth Web Service is not working.
> > 12052 - The DSS Authentication Web Service is not working.
>
> > I tweaked some folder and IIS
> > permissions and the clients started show up, but none are receiving the
> > updates.
>
> My gut feeling is that "tweaked some folder" and "IIS permissions" is
> probably the key to your issue.
>
> Can you expand on this statement a bit, please?
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)
> https://mvp.support.microsoft.com/pr...2-D095EB07B36E
>
> Everything you need for WSUS is at
> http://technet2.microsoft.com/window...s/default.mspx
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>

Changing permissions is rarely the solution to such a problem. In fact, in
all of the past two years of working with WSUS, the *only* time changing
permissions has been a solution is when the client is specifically receiving
HTTP '401' errors from the WSUS server, which is almost always because
somebody/something has disabled anonymous access on the IIS virtual server.

I suspect the correct resolution is going to be to put the permissions back
to where they were and troubleshoot the original problem, and implement the
correct solution for that original problem. I'll know that for certain once
I see what you changed.

In addition, what do you have in the way of error codes from the client(s)
concerning the original "will not show up" problem?

"Chris" <Chris@discussions.microsoft.com> wrote in message
news:AB2923A1-D1AF-4265-B736-21AFAE41B8C8@microsoft.com...

> My next thought is to uninstall WSUS and delete all folders. Then
> uninstall
> IIS and delete all folders. Reboot. Reinstall IIS and WSUS.

This would certainly remediate any lingering issues with permissions. :-)

--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/pr...2-D095EB07B36E

Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

"pharmboy" <pharmboy@discussions.microsoft.com> wrote in message
news:BE7222CE-3A56-4ED5-8311-8007FBC36198@microsoft.com...

> Surprisingly (to me at least) when I remove Anonymous Access from
> APIRemoting30 Properties, the console will start without issue. As soon as
> I
> enable Anonymous access, the admin console fails with the error above.

On my freshly installed, and functioning, WSUS 3.0 server, the APIRemoting30
virtual directory does *not* have Anonymous Access, thus, given that
removing it makes the system work -- I'd say you should remove it. :-)

--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/pr...2-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....

pharmboy wrote:

> I guess the reason I kept trying to enable Anon access there is the page
> here
> (http://technet2.microsoft.com/window....mspx?mfr=true)
> seemed to indicate it under the Appendix C heading, "Properties of the API
> Remoting Web service" unless I am misunderstanding it.

The page you reference currently indicates that ApiRemoting30 should *not* have
anonymous access. Either they've corrected it recently (quite possible) or you
were misreading it.

Harry.