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.

Unable to Sign In on Google Chrome to Office 365

My organization has been moving from hosting our own Exchange and Lync/Office Communications on premise to Microsoft hosted via Office 365.

I had implemented Active Directory Federation Services (ADFS) and Lync Online about 18 months ago.  ADFS had some challenges, but once I implemented it, it has been reliable.  During implementation, I got on-premise pass through Windows Authentication working and off-premise sign in working.  I had tested on versions of Internet Explorer, Mozilla Firefox, and Google Chrome successfully.

We're now readying to migrate to Exchange Online and away from our on-premise mail server.  During testing, several of us in IT began realizing that sign-ins from Google Chrome was not working.

On premise, you would be prompted with a Google Chrome pop up dialog.  You'd put in your credentials (email address and Active Directory password), and it'd take you right back to the logon prompt without error, and you'd never get in.

Off premise, you would be directed to our sign in page on our Federated Server Proxy server.  Same behavior, enter credentials, return right back to sign in page without error.

Googling this error tipped me off to the problem being that Google Chrome not supporting Extended Protection.  But I didn't know much about this, so I didn't know how to resolve the issue.

A case opened with Microsoft support got me directed to the fix, as documented here:
http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
The article mentions problems when using Fiddler Web Debugger, but it's the fix for a Google Chrome issue as well.

It's a setting within IIS.  The above link documents where the setting is within IIS to change it manually on each affected server (typically you have multiple ADFS servers for fault tolerance), or PowerShell commands to set this universally across the farm.

Once I made this change, my users can leverage Office 365 from any of the major browsers.