Wednesday, January 26, 2011

Remote Control a RDS session in a mixed Remote App and Full Desktop environment

With RemoteApp becoming more and more a common scenario in environments where a Full Remote Desktop is also offered that raises the question, what about Remote controlling a user’s session?

For the people that didn’t already know, Remote Control (often called shadowing) is most commonly used to deliver support to end users. It gives the ability to view, and even interact, with the users Remote Desktop Session.
Before you try to shadow a session keep in mind that you can shadow a session only from another RDP session (because you are intercepting the graphics output of the shadowed session). So you can’t do this from the console. You can only shadow sessions connecting to a full desktop. “Ah”, you say “So if I’m trying to remote control a RemoteApp Session I’ll get an error or a warning?” That’s the funny part, you won’t!
There is nothing in the user interface that prevents you from Remote Controlling a RemoteApp session, and you won’t see any warnings. But, shadowing a RemoteApp session simply isn’t supported, and doesn’t work as you might want to. Here’s why; it requires communication between the server and the client to position the window in the right way and that communication simply doesn’t exist. If the user shadowing the session moves the application’s window it might disappear or become unresponsive to the end-user.
So how to tell the difference between a Full Desktop and a RemoteApp session? The Remote Desktop Services Manager doesn’t tell you the difference that easy. The key to this is the fact that full desktop sessions use Explorer.exe  and Userinit.exe and RemoteApp sessions use Rpdshell.exe and Rdpinit.exe, respectively.
Of course you can ask the end-user to describe the session to you in order to figure out whether it’s a RemoteApp or not but, with all due respect, most end-users will not see or even know the difference.
So here’s two ways to quickly check it out remotely:
1. Open the Remote Desktop Services Manager, select the farm or the RDSH server in question and hit the processes tab. Look for the user that you want to remote control and check whether his or her session has a process rdpshell.exe running, if that’s the case then don’t even try to Remote Control.
2. Fire up a command prompt on the RDSH server and enter:
query process Freek.Willem /SERVER:RDSH01
You can get a result like:

USERNAME SESSIONNAME ID PID IMAGE
freek.willem rdp-tcp#1 2 2276 taskeng.exe
freek.willem rdp-tcp#1 2 3433 rdpclip.exe
freek.willem rdp-tcp#1 2 2937 dwm.exe
freek.willem rdp-tcp#1 2 3637 explorer.exe
freek.willem rdp-tcp#1 2 2712 winword.exe
freek.willem rdp-tcp#1 2 2637 powerpnt.exe
freek.willem rdp-tcp#1 2 3112 excel.exe
No rdpshell.exe here, so note down the Session ID (in this case 2) and start shadowing directly using by entering:
shadow /SERVER:RDSH01 2
That’s all! Happy shadowing!

Some extra info:

How to Connect to and Shadow the Console Session with Windows Server 2003 Terminal Services
http://support.microsoft.com/kb/278845
How to Shadow a Terminal Server Session Without Prompt for Approval
http://support.microsoft.com/kb/292190
 

2 comments:

  1. Incredible ¿this information exist in any MS document about Remote DEsktop Services?

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete