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!!!!!

Brute Force Approach To TSAdmin on Server 2012 R2

It's a common problem.  Your server has Remote Desktop enabled, and multiple administrators hop on to a server, don't properly log off, and you want to see who is connected and remotely disconnect them.

In Server 2003, we had tsadmin.exe.  In Server 2008, we had tsadmin.msc.  But in Server 2012 R2, we have... what?

I found what I will deem a brute force approach to fixing this problem.  Basically copying some files from a 2008 server along with some registry settings, and getting yourself something working on Server 2012.

From a 2008 server, copy:

• tsadmin.dll
• tsadmin.msc
• umcres.dll (this file was already on my Server 2012 system, so I did NOT overwrite)
• wts.dll

Then make the below registry modifications.  (I copied this text into notepad, saved with a .reg extension.  Double click from your server to execute.)

Reboot and voila.  tsadmin.msc will work for you.

I'm not going to highlight this as a best practice, but it is working for me.  Use at your own risk.  

Thanks to user stefnviarsson who documented this here: http://community.spiceworks.com/topic/352431-terminal-services-manager-equivalent-for-server-2012-rds 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\FX:{3FCE72B6-A31B-43ac-ADDA-120E1E56EB0F}]

"ApplicationBase"=hex(2):43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,\

  73,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,00,00

"About"="{00000000-0000-0000-0000-000000000000}"

"VersionStringIndirect"="@C:\\Windows\\System32\\umcRes.dll,-106"

"ProviderStringIndirect"=hex(2):40,00,43,00,3a,00,5c,00,57,00,69,00,6e,00,64,\

  00,6f,00,77,00,73,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,\

  5c,00,75,00,6d,00,63,00,52,00,65,00,73,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,\

  00,31,00,30,00,32,00,00,00

"NameString"="Remote Desktop Services Manager"

"HelpTopic"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,00,6f,00,\

  74,00,25,00,5c,00,68,00,65,00,6c,00,70,00,5c,00,74,00,73,00,5f,00,6d,00,61,\

  00,6e,00,61,00,67,00,65,00,72,00,2e,00,63,00,68,00,6d,00,00,00

"AssemblyName"="tsadmin"

"RuntimeVersion"="v2.0.50215"

"Description"="Manage Remote Desktop Services sessions"

"DescriptionStringIndirect"=hex(2):40,00,43,00,3a,00,5c,00,57,00,69,00,6e,00,\

  64,00,6f,00,77,00,73,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,\

  00,5c,00,75,00,6d,00,63,00,52,00,65,00,73,00,2e,00,64,00,6c,00,6c,00,2c,00,\

  2d,00,31,00,30,00,34,00,00,00

"LinkedHelpTopics"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,\

  00,6f,00,74,00,25,00,5c,00,68,00,65,00,6c,00,70,00,5c,00,74,00,73,00,5f,00,\

  6d,00,61,00,6e,00,61,00,67,00,65,00,72,00,2e,00,63,00,68,00,6d,00,00,00

"NameStringIndirect"=hex(2):40,00,43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,\

  00,77,00,73,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\

  75,00,6d,00,63,00,52,00,65,00,73,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,31,\

  00,30,00,33,00,00,00

"IconIndirect"=hex(2):40,00,43,00,3a,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,\

  00,73,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,75,00,\

  6d,00,63,00,52,00,65,00,73,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,31,00,31,\

  00,31,00,00,00

"FxVersion"="2.0.1.7"

"Type"="Microsoft.TerminalServices.Monitor.SnapIn.TSManagerSnapIn, tsadmin, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

"FolderBitmapsColorMask"=dword:00000000

"ModuleName"="tsadmin.dll"

"Provider"="Microsoft Corporation"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\FX:{3FCE72B6-A31B-43ac-ADDA-120E1E56EB0F}\NodeTypes]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\SnapIns\FX:{3FCE72B6-A31B-43ac-ADDA-120E1E56EB0F}\Standalone]

Windows Server 2012 - The Nags Continue - How to REALLY Disable UAC

In my organization, I had gotten a late start in to deploying Windows Server 2012 R2.  (The culprits were versioning on our backup system of EMC Avamar and our versions of VMware vCenter.)  

As such, I've just started deploying servers with it over the past 6 months or so.  

Part of my standard server build process (or within my VMware templates) includes disabling User Account Control (UAC).  

I'd hit the Start button, use the Search box and type in "user account control" and then go to Change User Account Control settings.  I'd drag the slider down to "Never notify" and expect not to be restricted from doing things on my own servers.  (Doesn't every administrator do this, really?  What was Microsoft thinking with this "feature" anyways?)

Yet when operating with Server 2012, I was still being restricted.  Trying to work with files within a system area like C:\Program Files, I'd would be unable to move files.  "You'll need to provide administrator permissions" with prompts like this:

Finding the right keywords to Google were a little challenging, but ultimately I found the answer here: http://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx.  

The GUI doesn't really disable UAC.  You need to use a registry tweak.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
Change DWORD "EnableLUA" from default value of 1 to 0 

You'll be rewarded for your effort with this pop up from the system tray:

"You must restart your computer to turn off User Account Control.  Click to restart this computer."

Then after a reboot, lo and behold, you won't be hampered from managing your own server. Enjoy.  

Concerning DLLs in the root of C drive; spyware infection? No

At work, I upgraded my laptop by replacing the hard drive with an SSD.  Boy, did it make a nice improvement in performance.  I took the purist approach and did a fresh install of Windows 7 and reinstalled all my applications.

Imagine my chagrin after a careful rebuild, only to find a number of DLL files in the root of my C drive.  I deleted them, only to find them returning regularly.

Doing some Googling on one of the DLL names (such as tsgetxu6ag55.dll) wasn't turning up good results.  I'd find lots of results to web sites that 'identify files' and would give me a lot of nonsense answers not clearly telling me if it was spyware, a legitimate file, or any useful info.

I stumbled onto what was going on once I started Googling what the file was.  The properties of the DLL made mention of Tom Sawyer.  Once I Googled that, lo and behold the answer came to light.

https://thwack.solarwinds.com/thread/55808

One piece of software I had reinstalled was SolarWinds IP Address Tracker.  The newer version apparently isn't well-written, and it dumps many files in the root of your C drive.  Well, that's helpful (NOT).

At that point, I searched and found an older version of the install and downloaded that.  No more pesky DLLs appearing in the root of my C drive.