WSUS on Server 2012 R2: Much Harder Than One Would Expect

In my organization, I have been using WSUS for some time to patch my desktops via Group Policy.  It is a very straightforward process that allows me some level of control over patch deployment without taking up too much of my time.  I deploy patches in two batches.  Microsoft releases hotfixes on the 2nd Tuesday of each month.  One week later, on the 3rd Tuesday of each month, I release to computers within the IT department, and a smattering of "test" systems throughout the organization, attempting to hit a random sampling throughout each department.  Once we've heard of no problems, a week later, on the 4th Tuesday, hotfixes go to the rest of the organization.

My WSUS server is running Windows Server 2003.  With that being officially end of lifed in July 2015, it was time to move this function to a newer server.

I was shocked at the complications I had when deploying to Windows Server 2012 R2.  I expected to install the feature via Server Manager and the Add Roles and Features wizard. While that was fundamentally what I did, I encountered a number of problems I had to correct.  It did not seem to work 'out of the box' as one would expect.  

Once I had WSUS online, I redirected some test computers to use the new server via Group Policy.  But All Computers in WSUS continued to show zero computers.  Investigation on the client, in the Event Log, under Applications and Services Logs | Microsoft | Windows | WindowsUpdateClient | Operational log yielded this error message:

Error
Source:        WindowsUpdateClient
Event ID:      25
Task Category: Windows Update Agent
General:       Windows Update failed to check for updates with error 0x80244019.

So I head to the Google machine and come back with this article:
http://support.microsoft.com/en-us/kb/920659 

The language in this article was slightly off for Server 2012, but I found that the IUSR account didn't have access to the folder in question.  I edited the NTFS rights (after taking ownership).  And that was one hurdle resolved.

Once I had that issue resolved, I could then use a web browser to get access to a relevant WSUS file (i.e. http://servername/selfupdate/wuident.cab) and I pressed on.

Only to realize that I still wasn't getting any clients showing up to WSUS.  The next thing I realized: the web site for WSUS hadn't gone into the Default Web Site, but was running in a separate site under WSUS Administration.

Now bare with me here as I'm not sure if this is designed correct behavior or I had something odd happen during install.  I didn't feel like specifying unusual ports in my Group Policy settings pointing my clients to WSUS (it was running on 8530 for http).  So I removed the binding for port 80 for the Default Web Site (Internet Information Services IIS Manager | Bindings, highlight http, Edit... button, change port to 8080, OK, Close).  I then set the WSUS Administration to port 80 in similar fashion.

But at that point, all I did is cause Update Services console to open with error messages indicating I needed to Reset the Server Node, which didn't clear the error message.  Whoops, I've broken things.  Back to Google I went.  

There were two additional steps to fix matters.  I needed to update a registry key.  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup.  Port Number needed to be switched to 80.  

One more command I ran was found in C:\Program Files\Update Services\Tools.  I needed to run WSUSUtil.exe.  The syntax was "wsusutil usecustomsite false".  

Rebooting after executing these two steps resolved matters for me.  (I found the info that helped me to figure this all out from multiple people here https://social.technet.microsoft.com/Forums/systemcenter/en-US/8907dd07-8cc2-4aec-b542-d52e4691ba1e/how-to-change-port-settings-in-wsus)

OK, so at LONG LAST, I had functional WSUS.  But, further minor headaches were to come.

Once I had computers in the new WSUS, finding needed updates, one of your available options it to right click a computer and select Status Report.

Doing so told me that I needed Microsoft Report Viewer 2008 Redistributable.  OK that's easy enough.  But wait, during that install, it told me I was missing .NET 2.0.  

Well, hang on a minute.  I certainly can't go download that and install it, that's too old.  So Googling leads me here: http://blogs.technet.com/b/schadinio/archive/2012/05/18/windows-server-2012-beta-how-to-configure-wsus-reporting.aspx.  

So either via GUI or via command line, you can install .NET Extensibility 3.5 (which will include the .NET 2.0 that you need).  But I was having problems.  I was providing the DVD ISO for Server 2012 and it was telling me the needed files were missing.  I was using the command line arguments to tell it to go download the needed files and those were failing.  I was getting errors 0x800f0906 and 0x800f081f (I don't remember which problem equated to which error code).  

The problem was: This is my WSUS Server.  I had already placed it in a location in Active Directory where it gets its Windows Update reconfigured to USE ITSELF to get downloads from.  So it wasn't going to Microsoft to get the missing files.

On top of that, I also encountered roadblocks because it needed some parent features installed.  The /all switch was necessary to get around that problem.  

I had to relocate it in Active Directory so it wasn't using a WSUS server, then this was the correct syntax to install .NET and go download needed files while using the provided DVD ISO (replace z with whatever drive letter you have mounted to your DVD or ISO):

dism.exe /online /enable-feature /all /featurename:NetFX3 /Source:z:\sources\sxs

Lo and behold, at long last, I had a functional WSUS!!!!!