RDP Magic: Exploring the Console and Shadowing Functionalities of RDP
Any Administrator who manages more than a few Windows servers has used the Remote Desktop Protocol (RDP) at one time or another. It allows us to manage systems remotely so we don't necessarily have to physically be in the server room (are you crazy? That place is COOOLLDD!!! Brrrr...). Connecting to a server via RDP is fairly straightforward. You open the program, enter the server name or IP address and click connect. After, just type in your userid and password to authenticate. There are various settings you can customize in your RDP client such as the size of your remote desktop, colors, sounds, and even the amount of bandwidth used by your remote desktop connection. RDP also includes some unique functionalities that most people are not aware of.
Often we find ourselves having to install software like SQL or Exchange remotely. Installing via RDP causes problems and often fails because of the hardware mappings that occur within an RDP session. A possible solution to this problem is to install all software directly from the console, but in today's virtual world, sitting in front of the server in a data center may not be an option. So what do you do? Rely on some hardware monkey to install your critical database software? Of course not! If your server is running Windows Server 2003, there is a way to connect to the console remotely.
If you go to Start->Run and type 'mstsc /v:servername /f /console', you will get the same window as you usually do when connecting to a normal RDP session, but this will allow you to directly connect to the console session (session 0) just like if you would be sitting right in front of the server. You can verify this by opening the Terminal Services Manager and looking at which session you are connected to. This does not work on Windows 2000 Server. If someone else is logged into the console session when you attempt to connect, you will get this error:
The user domain\username is logged locally on to this computer. The user has been idled for <number> minutes. The desktop is unlocked. If you continue, this user's session will end and any unsaved data will be lost. Do you want to continue?
If you proceed, the user will be logged off and the computer will lock itself. If the userid's are the same, you will connect to the same session without any problems.
I'm sure many Administrators have come across situations where a problem occurs with a server and an alert is generated. Then everyone, even folks who cannot necessarily diagnose or fix the problem, will decide to remote into the server to see what's going on. This will unfortunately reserve the 2 available remote sessions and you will get this error when attempting to log on yourself:
The terminal server has exceeded the maximum number of allowed connections. The system cannot log you on. Please try again or consult your system administrator.
Now you can't get in to troubleshoot.
Connecting to the console basically gives you a third connection that most people don't know about. In most cases, this connection should be available, unless someone really is at the console or someone else beat you to it.
Along the same lines, you can shadow a current session. If another person is logged in, you can request to shadow their session by typing:
shadow x (where x is the users session number, which you can find in Terminal Services Manager)
You will receive a message stating:
Your session may appear frozen while the remote control approval is being negotiated. Please wait...
The user will then receive the following message:
domain\username is requesting to control your session remotely.
Do you accept the request?
Why would someone do this? Imagine my previous scenario where you have a lower level worker physically at the console and you want to teach him/her how to do something. You can call this person on the phone and ask him to login, then, you login remotely and shadow his session. From this point, he will be able to see what you are doing and can observe the proper procedure while you are explaining it to him. Make sure he takes notes! You wouldn't want to get called again for the same problem when there is someone on site who is able to fix it right?
I hope you have learned something new today about RDP and its capabilities. Now that you know this, you have a new tool in your Administrators toolbox to handle some remote situations.