U3 USB Flash Drive and Remote Desktop Woes

[Update: See this post for how I was able to resolve the problem presented below.]

Like a lot of people, I use USB flash drives. I recently saw a good deal on a "Verbatim 1GB Store 'n' Go U3 Smart Drive", so I purchased one. U3 (www.u3.com) is a platform with a number of components that allow for "personal workspace portability". Basically, you can install applications designed or adapted specifically for running in a "U3 Environment". You can take your data and programs with you everywhere. There are email programs, office productivity packages, browsers, security packages, etc. that all offer the ability to run without leaving a footprint on the host system's hard drive.

I thought that sounded pretty cool. Of course, I must have usage patterns that deviate from that which is expected or perhaps desirable. I have a bunch of computers in my office. My main system is a laptop. I use it as such - the thing lives on my lap. So the prospect of a USB drive sticking out of the back isn't really one that I relish for what I hope are obvious reasons. Instead, I plug my flash drives into a server in my office and just set up secure shares, and access my data that way.

The U3 drive, being what it is, offers the ability to password-protect the data / program partition (there is a system partition that "autoruns" a launchpad-type program). I figured I could plug the drive into the server, and remote-desktop in later to enter the password and manipulate the data, run the programs, or whatever.

The first server I tried this on was running Windows Server 2003. I remote desktop'd into the server and tried to run the launch program. No UI ever displayed. I tried it a few times and even tried to run the program in Windows XP Compatibility mode. I quickly gave up because I had other stuff to do.

The next time I tried this, the U3 drive was plugged into a Windows XP workstation. I remote desktop'd into the system and tried it again. Same result. I went into my office, logged into the workstation, ran the program, and was presented with a UI that wanted a password. After I entered the password and went back to my main system, I was able to access the data and programs on the U3 drive as I would expect.

This led me to believe that the developer(s) of the LaunchU3.exe program are specifically preventing the exact scenario which I depend on from working (I want to be able to enter the password in the launch program via the RDP session). So, I fired up Dependency Walker and profiled the naughty program. Sure enough, DW showed the following as the last few lines of the profile:

00:00:06.875: GetProcAddress(0x77E40000 [c:\windows\system32\KERNEL32.DLL], "ProcessIdToSessionId") called from "g:\LAUNCHU3.EXE" at address 0x0040352B and returned 0x77E580F7 by thread 0x1020.
00:00:06.875: GetProcAddress(0x77E40000 [c:\windows\system32\KERNEL32.DLL], "WTSGetActiveConsoleSessionId") called from "g:\LAUNCHU3.EXE" at address 0x0040352B and returned 0x77E41A2D by thread 0x1020.
00:00:06.906: Thread 0x1158 exited with code 0 (0x0).
00:00:06.922: Thread 0x1300 exited with code 0 (0x0).
00:00:06.922: Thread 0x10E0 exited with code 0 (0x0).
00:00:06.953: Thread 0xFA4 exited with code 0 (0x0).
00:00:06.953: Exited "g:\LAUNCHU3.EXE" (process 0xB08) with code 0 (0x0) by thread 0x1020.

So I wrote my own program to see what those functions (ProcessIdToSessionId and WTSGetActiveConsoleSessionId) returned for the values of the session Ids. Sure enough, the values returned by the functions were different when using a RDP connection - ProcessIdToSessionId said the session id was 0 and WTSGetActiveConsoleSessionId said the console session id was 2 when RDP'd into the console of the remote system. The launch program must compare the results and if they are different it immediately calls TerminateProcess.

It would be interesting to know why the developers of the launch application saw fit to prevent someone from running the launch program via RDP, but one can enter the password "locally" and still access the data remotely.

Someday when I get some time I'll write something to mess with the values returned by ProcessIdToSessionId and / or WTSGetActiveConsoleSessionId so that I can use the drive how I want to...