Alright folks … time for a post on the fun, twisted history of shadowing RDP users in Microsoft Remote Desktop Services. Not a month goes by that I don’t field a call from an administrator confused about the shadowing changes implemented in Windows Server 2012. Plus, I want to tell you all about what we’ve done in Version 3.6 of Remote Desktop Commander to make these RDP shadowing variations as seamless as possible among the different Microsoft OS versions.
First Rule of Shadow Club: You CANNOT Shadow RDP Users on Windows Server 2012, ONLY Windows Server 2012 R2
This keeps biting RDS admins in the butt. There is ZERO support for shadowing in Windows Server 2012. I’ve written at length about many of the radical changes between RDS on Windows Server 2008 and Windows Server 2012. Microsoft literally roto-rootered the whole RDS stack in Windows Server 2012, tearing out old plumbing and integrating new plumbing related to RemoteFX and RDP enhancements. It took them until the Windows Server 2012 R2 release to put Humpty Dumpty mostly back together again. So unless you REALLY like pain, don’t upgrade to Windows Server 2012 – bypass it and upgrade to Windows Server 2012 R2 or Windows 2016.
Review: Legacy Shadow Techniques for RDP Users on Windows Server 2003 and Windows Server 2008
Yes, I included Windows Server 2003 because I know some of you deviants still have some Windows 2003 systems running in your enterprise, long after extended support and updates have expired. That’s fine you slackers – blame legacy apps and management.
Back in the good ole days of simpler operating systems, to shadow you would either:
1.) Fire up a copy of TSAdmin (Remote Desktop Services Manager), highlight the user session in question, then right mouse click to shadow them, OR:
2.) Command line it with the shadow command, passing it the user’s session ID and the server their session was located on.
Both of these approaches required you to run the app or the command from within a Remote Desktop session; you could not issue these commands directly from the console session of a server or workstation.
New Shadow Techniques for RDP Users in Windows Server 2012 R2 (and Windows 8.1 and Windows 10)
Alright, let’s engage in some fantasy now shall we? Let’s say that all of your servers are Windows 2012 R2, and all of your workstations are Windows 8.1 or Windows 10. Ha ha! See how funny I can be? In this case, you can use the new command line arguments built into the Remote Desktop Connection Client (mstsc.exe) to get the party started.
NOTE 1: Unlike Windows Server 2008, Windows Server 2003, and Windows 7, you DO NOT already have to be running in a remote desktop session to start shadowing another user session. You can be logged into the console session of your own desktop, laptop, etc and jump right into shadowing a remote user’s session, IF:
1.) Your Windows system is running Windows 8.1, Windows 10, Windows Server 2012 or later.
2.) Their Windows system is running Windows 8.1, Windows 10, Windows Server 2012 or later.
If either one of the systems is at a lower OS level, this new approach won’t work.
NOTE 2: In Windows Server 2012 R2, by default you need to be a local administrator on the machine hosting the sessions you wish to shadow. This is a major shift from Windows Server 2008 and earlier operating systems. There is a way around this however with a gnarly command you can run inside Powershell.
Again, provided you live in this magical world of fairy tales, unicorns, and homogeneous operating systems, you simply launch mstsc.exe with the appropriate combination of command line switches, such as:
1.) Switch /v, which is the remote computer with the session you want to shadow (e.g. /v:MY2012SERVER)
2.) Switch /shadow, which accepts the session id of the user session that will be shadowed (e.g. /shadow:1)
3.) Switches /control and /noConsentPrompt, which determine whether you can control or only view the session, and whether or not the user is notified that you are shadowing their activity, respectively.
Putting it together: mstsc /v:TARGETSERVER /shadow:1 /noConsentPrompt lets you monitor (but not control) session 1 on TARGETSERVER without notifying the user.
The RDP Shadow Reality: You Run a Heterogeneous Network Full of Systems That Are At Different OS Levels.
I gave a talk on RDP 8 at TechMentor two weeks ago, and asked for a show of hands to find out who had deployed Windows Server 2012 in their environment. The vast majority of attendees were still running Windows Server 2008, and those who had started deploying Windows Server 2012 still had a lot of Server 2008 systems in place. So the reality is, you’ll be dealing with two different approaches to shadowing RDP users for a while.
Given this challenge, we’ve recently built a bit of magic into our latest version of Remote Desktop Commander when it comes to shadowing users. We automatically detect whether or not you want to shadow a user on the local system or a remote system, and we also look at the OS level of both the local machine and the remote machine. If both systems are running Windows 8.1, 2012 R2, Windows 10 or later, we shell out immediately to MSTSC with the new options. If there is an OS level mismatch, we’ll first establish a client RDP session on the remote system, and then auto launch a helper utility on the remote system that will invoke the appropriate shadowing technique to start shadowing the desired session.
In addition, as you can see in the above screenshot, we give you even more options before starting the RDP user shadow attempt. For instance, you can temporarily override the GPO that controls whether or not users are notified that their session will be shadowed. You can also start your client session in Admin mode, so that the connection broker doesn’t block you from connecting to the desired server in the collection.
The best part? These shadowing features come in both versions of Remote Desktop Commander – the Lite edition, which handles basic session management and user shadowing, and the Remote Desktop Commander Suite, which handles all of the above plus does extensive monitoring, reporting, session recording, performance tracking, all for only $9 per server per month.