Terminal Server Logging Blog Articles | Remote Desktop

Shadowing RDP Users: A Twisted History

March 21, 2016 By Andy Milford Leave a Comment

Alright folks, it’s 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 across various Windows Server implementations. And, I’ll cover some of the basics in Remote Desktop Commander that 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.

Legacy Shadow User RDP — Ahh, the good ole days of RDP user shadowing…

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 once, 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. It was clear that there would be two different approaches to shadowing RDP users for quite a while.

Given this challenge, we built a bit of magic quite some time ago into 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.

Intelligent RDP User Shadowing — Remote Desktop Commander makes this much easier…

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 Of This Twisted History?

These shadowing features come in versions of Remote Desktop Commander. So, luckily, this history doesn’t have too messy an ending.

Find out more about later developments in user session shadowing with Remote Desktop Commander or find out what fits your needs best – you can request a web demo from our team.

Updated: November 2020.

Avoiding UDP Transport Gotchas With RDP 8

February 16, 2016 By Andy Milford Leave a Comment

I’ve been writing and speaking a lot lately about the improvements found in version 8 of the Remote Desktop Protocol, which is used in Windows 8 and Windows Server 2012. Version 10 of RDP was just introduced in Windows 10, and it soon will be implemented in Windows Server 2016, adding some new enhancements over Version 8 which we’ll talk about soon. But back to the topic at hand…

UDP Transport in RDP 8 Boosts Throughput And Enhances User Experience

RDP version 8 is the first generation of the Remote Desktop Protocol that uses UDP alongside TCP for data transmission. Provided the RDP client supports RDP 8 (e.g. Windows 7 with RDP 8 Update, Windows 8, or Windows 10), the Windows 2012 RDSH server can transmit data using both UDP and TCP. This is a big deal, because UDP doesn’t suffer from TCP’s enforcement of its congestion-avoidance algorithm, so RDP 8 can push more data across the wire in a selected chunk of time via UDP (e.g. 2x to 8x more compared to TCP transport only), even over high latency links. Couple that with some nifty forward error correction techniques, and RDP 8 is able to boldly go into sketchy network conditions that previous versions would run screaming from.

But Watch Out For the Following Gotchas That Can Block UDP in RDP 8

Believe it or not, there are several common “gotchas” that can conspire against you to prevent UDP transport use with an RDP 8 or later Remote Desktop Connection. Let’s look at them in order:

Using a Windows Server 2008 Remote Desktop Gateway With Windows Server 2012 Remote Desktop Session Hosts

The Remote Desktop Gateway Role Service in Windows Server 2008 does not support UDP transport, so all connections via this legacy gateway will be forced to use TCP only. Not good. Make sure you upgrade your Windows 2008 server running the Remote Desktop Gateway Role Service to Windows Server 2012.

Forgetting to Explicitly Add an Endpoint For UDP in Windows Azure

This one is BIG if you are hosting your Remote Desktop Session Hosts in Windows Azure (or any other cloud service provider for that matter). By default, when you create a new Windows Server 2012 instance (with or without the RDSH role implemented), only the TCP endpoint for RDP will be created. See below:

You’ll need to go back behind any newly provisioned RDSH servers in Azure and remember to explicitly define a UDP endpoint for RDP like so:

Accidentally Disabling UDP Transport Via Server Side Group Policy Objects

One other potential problem is incorrectly setting the “RDP Transport Protocols” Group Policy setting, located under Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections. By default, both UDP and TCP will be used if the client supports it, but administrators can explicitly disable the use of UDP transport in this area.

So, there you have it. UDP transport in RDP 8 opens up so many possibilities in terms of user experience an overall Remote Desktop performance. However, you have to double check and make sure that it’s not being restricted right out of the gate.

Want to find out more about what transport protocols your clients use, bandwidth consumption, and connection quality? Click here to learn more about the Remote Desktop Commander, and start a $9 per server per month subscription to profile all of the above, plus much more.

Preventing Remote Desktop Logins For Privileged Users

February 2, 2016 By Andy Milford Leave a Comment

Recently, I was working with a client who had the interesting goal of preventing a specific domain administrator from logging on via Remote Desktop Services. They wanted the domain admin and other privileged accounts to only connect via the VMWare vSphere console (through the corporate firewall), and then start a console session.

Fortunately, this is easily accomplished via user rights assignments in Group Policy / Local Security Policy. To do this, open up your Group Policy editor, or, if on a non-domain system, launch secpol.msc, and adjust the “Deny logon through Remote Desktop Services” policy entry.

Add the users who you want to prevent from logging on via Remote Desktop Services, save, and then apply/refresh the policy and test.

Note that this works well in all scenarios, from Windows Server 2003 onward. There is an older setting for individual users in Active Directory user management called “Deny this user permission to logon to a Remote Desktop Session Host Server.” This setting worked in all scenarios back in Windows Server 2003. However, in Windows Server 2008 and Windows Server 2012, it only works when the RDSH server is configured in Application Mode, NOT Remote Administration mode. Only setting the “Deny logon through Remote Desktop Services” user right assignment in Group Policy will effectively block access across all RDSH modes.

For more, read this Microsoft support article.

Is This The Absolute Surefire Way To Prevent Those Remote Desktop Logins? Well . . .

So, the above would not prevent an Administrator from altering a Group Policy object to remove themselves from this policy restriction. Therefore, using a tool like our Remote Desktop Commander Suite to audit privileged user sessions is a smart idea.

Using Remote Desktop Commander in conjunction with Group Policy, you can turn on heightened session auditing for specific users, routinely creating session recordings and screen captures for review later.

Quite a bargain for only $9 per server per month, if we do say so ourselves.

New Remote Desktop Services Hotfixes for Windows Server 2012 R2

January 6, 2016 By Andy Milford Leave a Comment

Greetings folks.

The Remote Desktop Services team at Microsoft has just released several new hotfixes for Windows Server 2012 R2 RDS deployments, one of which is pretty significant:

Our Old Friend, the Remote Desktop Licensing Manager.

High Importance Hotfixes

Scenario where too many users signing on can corrupt the RDS Licensing Server database.
Apparently, if there is a high volume surge of many users logging on at the same time, this can corrupt the licensing server DB. Not good!

Lower Importance Hotfixes

Remote Desktop Licensing Manager Tool corrupts reports in large farms.
Not an issue unless the report goes over 4KB in size, so this should only affect larger farms.

Disappearing RemoteApp windows
As a developer, this one fascinates me a bit. It only affects applications that temporarily disable window painting via the WM_SETREDRAW windows message. Still, if you’re having an issue with certain app windows disappearing when hosted via RemoteApp, it’s worth looking into this hotfix.

Remote Desktop Easy Print speed issues
Ahh yes, the continued bane of all RDS/Citrix admins’ existence – printing. After an OS upgrade to Windows Server 2012 R2, a new *feature* can make printing through the Easy Print driver take longer. This hotfix gives you better control over whether printing starts during or after spooling is completed.

That’s all for now.

— Your humble Microsoft RDS MVP

Do you need complete RDS/XenDesktop monitoring & reporting for only $9 per server per month? Review our sample reports and watch demonstration videos here.

Remote Desktop Performance: Key Metrics to Watch

January 4, 2016 By admin Leave a Comment

So, you’ve implemented a brand new Remote Desktop Services (RDS) or Citrix XenDesktop farm. Now, you want to start monitoring different metrics to get a better handle on Remote Desktop performance in general or maybe determine which users and/or clients are the most costly in terms of resources used.

Here are the key remote desktop performance categories you need to keep an eye on, and why they’re so important:

CPU Usage

While RDS Dynamic Fair Share Scheduling (and the built in Citrix XenApp equivalents) help evenly distribute CPU load amongst “plain vanilla,” “task worker” user sessions, this technology is not a panacea. For some MSPs and on-premise Remote Desktop Services shops, some users will require a much larger share of CPU (implemented via the Windows System Resource Manager) in order to run their beefier software. In other situations, Dynamic Fair Share Scheduling may let you inadvertently stuff too many users on an existing virtual machine, because DFSS will dutily throttle available CPU down to the point where common tasks may take *forever* to complete. Therefore, it is still very important to look at remote desktop CPU consumption patterns by user, even down to the process level running in the user sessions.

Memory Usage

Unlike DFSS above, there is no way to throttle available remote desktop memory per user session, which makes it even more critical to monitor remote desktop memory consumption both by user session aggregate and on a per process basis. By analyzing memory use by user and by process, you can better optimize the farm, and/or silo certain users and/or applications on specific servers that are better provisioned for their memory needs.

Bandwidth Usage

We’ve written at length about Remote Desktop Bandwidth consumption here and here, but many admins continue to be surprised at how much bandwidth RDP or ICA can use, depending on how it has been configured. Remote Desktop Protocol Version 8 and higher can double, triple, or even quadruple bandwidth use in certain use cases when UDP is enabled alongside TCP for transport. Moreover, if you permit transfer of files and screenshots via cut and paste, bandwidth can be consumed in a hurry. Since this has a significant impact on the user experience for others if RDP usage saturates the external Internet link, it’s important to see which users consume the most bandwidth, and what they are doing when they consume it.

Connection Quality

If you’ve moved your RDS farm to Windows Server 2012 or later, you can now get a much greater handle on individual user session latency and “potentially available bandwidth” via new RemoteFX performance counters. This quickly lets you determine if user connection problems are on their end, or if many of your users are experiencing high latency due to a load or networking problem on your end. Unfortunately, these performance counters are not very easy to correlate with individual users, but fortunately, our Remote Desktop Commander Suite can do this automatically for you.

Leverage an Affordable Remote Desktop Performance Monitoring Solution

We’ve touched on four big remote desktop performance monitoring areas above. While Citrix provides some monitoring capabilities in its expensive, upper licensing tiers (via EdgeSight / Director), smaller shops running regular Microsoft Remote Desktop Services are not provided with built in monitoring tools, short of what an admin can script together with PowerShell. While you can look at upper tier monitoring solutions, the per concurrent user price of these tools are rather steep, especially as they are sold through the channel.

For only $9 per server per month, let our Remote Desktop Commander Suite offering monitor each of those areas for you.

Please review our sample reports, demonstration videos, and feature listing now. Then, consider starting your subscription with us. With a 30-day money back guarantee and free initial support, you have absolutely nothing to lose.