A better RDP client: Royal TS

Microsoft currently has two official RDP clients:  Remote Desktop Client (built-in to Windows XP Pro, and downloadable for nearly anything else), and the Remote Desktops MMC snapin (from the Windows 2003 Administration Tools Pack).

They have all the right features between them, but neither has all of them in one place.  The Remote Desktop Client has the most options, but can’t connect to console session (aka “session 0″) and is meant for one remote connection at a time.  The Remote Desktops Snap-in can do these two things, but is missing tons of other options, plus one especially dumb limitation:  It can’t connect to a port other than standard 3389.  (It gives an error “The server name cannot contain the following characters: spaces, tabs , ;  :  ” < > * + = \ | ? ,”  — Another over-zealous coder under-thinking his validation logic!)


Microsoft says the Remote Desktop Client can connect to the console session, via a command-line switch.  Not sure why it’s not a checkbox on the options dialog , but it doesn’t work for me anyway.  It removes the %sessionname% environment variable, but Terminal Services Manager still shows the session is a “RDP-TCP#” name.  Oh well. (turns out the console session has to already be logged in). 

Something else I found: you can’t connect to the console remotely with a non-admin account — it gives you an error that “To log on to this remote console session, you must have administrative permissions on this computer.”

The standalone Client is best when you’re working in-depth on one remote machine.  The Snap-in is better for when you’re working lightly on several machines, and don’t need the extra options.  In daily use, I usually find myself switching between the Snap-in and the Client.  It’s a small but constant pain.

This is all to say that I just found Royal TS from code4ward, which is a free, open-source (C#) app, which attempts to combine the best of both programs.  (It’s like the Snap-in interface, but on steroids.) 

I’ve been using it for a few days, and it’s very good.  I only wish it could do a better full-screen, or use less screen real-estate with the embedded view.  I may try my hand at C# just to hack it up.

Hm, the author’s site is down now.  Hopefully it’s temporary.  Meanwhile, here is is on Snapfiles: http://www.snapfiles.com/get/royalts.html


Enable concurrent Remote Desktop sessions on Windows XP

It’s possible after all.  XP Pro’s Remote Desktop can be hacked to give concurrent sessions.

To explain:  Windows XP’s Remote Desktop rocks, as does its ability to give me my console session later (with my work uninterrupted) from another machine.  Glaring in its absence, though, is the ability to remotely-rock while someone is locally-rocking the machine.  This can stink in a big way. 

For example, too often I’ve remotely logged in for something quick, only to see this nuisance:

Logon Message
The user --- is currently logged on to this computer. If you continue this user's Windows Session will end and any un-saved data will be lost. Do you want to continue?
Yes   No

Rather inconvenient.  Even worse, though, I’ve often been logged in and working remotely, when someone locally logs in.  No warnings or explanations, just *bam* disconnected!  (At least the first situation confirms the handover with both people.)

For history:  Remote Desktop’s daddy was Windows 2000 Server’s Terminal Services in Remote Administration Mode, which did allow (limited) concurrent sessions.  Microsoft added the console-session flexibility to XP’s Remote Desktop, but dropped the concurrent sessions.  Then 2003 Server’s (renamed) Remote Administration wrapped in XP’s console flexibility.  Later, XP’s SP1 promised concurrent access, then SP2 did.  Two strikes.  It did make an SP2 beta though, before being yanked later…

The silver lining:  Thanks to the termsrv.dll from that SP2 beta, it’s possible to hack XP for concurrent Remote Desktop sessions in a few minutes.  Just change a registry setting, reboot to Safe Mode, replace the DLL, and boot back into homebrewed XP Remote Administration goodness.

For the do-it-yourselfers:  Don’t wait for Longhorn (or whenever-they-may-get-to-it): here’s the how-to article, and here’s the needed termsrv.dll file.

I just stumbled on sala source’s Terminal Server Patch, which wraps up the whole process in a single convenient patch.  Very cool.


Mapping/Connecting a Drive Letter to a WebDAV or Front Page website

Mapping/Connecting a Drive Letter to a WebDAV or Front Page website


Apparently Windows XP makes this possible through an integrated WebDAV client and updated Net Use command.  For icing: if you have a Passport, you can map your online Documents folder to a drive letter with this command:
net use * “http://www.msnusers.com/My Web Documents/Documents” /persistent:yes /user:UserName@passport.com

Tons of cool possibilities with this…  (Now if we could just do the same with FTP!)

I just setup a webDAV-enabled website in IIS, enabled HTTPS, setup a couple virtual directories with pass-through authentication to my file server, and voila! thanks to the above trick, I can have secure, full-control remote access to it from anywhere.

Actually, there was a lot of toil to the process, since there are a lot of bugs and tricky bits with DAV, HTTPS, and UNC Virtual Directories.  Here’s useful info I found when wrestling my share of them…



Passthrough Authentication:

Web Folders: