WSUS Failure

Part of the fun of inheriting a network is discovering what your predecessors have done.  It’s even worse when some "expert" consultants (IT Terrorists) have had their way.

I installed a new WSUS server today.  All was well for hours.  Managed servers were discovered and downloading patches.  But suddenly, those servers stopped updating their status.  SCOM 2007 was alerting.  Uh-oh!  I was at home so I fired up the VPN and had a look.

The following events were appearing in Event Viewer on the WSUS server:

13042 Self-update is not working
12002 The Reporting Web Service is not working.
12012 The API Remoting 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 saw loads of blog and forum entries.  It just came back to one thing … IIS.  Opening the web sites and virtual directories gave me the dreaded "You’re not authorised to view this page" warning.  I’ve worked at a web hosting company so I’ve seen how a corrupted metabase could lead to IUSR hell.  But this was different.  IUSR was OK.

Then it struck me.  Some consultants had played "security expert" in this AD.  I’d already found tonnes of issues in this AD deployment from not understanding DNS to installing Windows 2003 in 10GB partitions (amateurs!).  I checked the policies in GPMC and sure enough, IUSR was not being granted "Allow log on locally".  This was overwriting the local security policy of the WSUS server.  My WSUS box was fine until policy applied and IUSR lost it’s right to log on locally on the WSUS server.

Some AD re-engineering and everything was sorted and my WSUS box was back to normal.

One thought on “WSUS Failure”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.