Two MSTSCs and one WKSPRT, oh de doo dah day!

Hi,

I am implementing an enterprise SSO kiosk solution where we need to track the launch AND termination of an RDP session so if the session times out the workstation locks. Sounds simple? Not anymore.

We're using RDS 2012 R2 and the current Remote Desktop for Win7 (8.0), and it does some really bizarre process chaining to the point where it is just, well, unpredictable.

Using procmon we can see consistently that the workflow when launching the RDP file which connect to an RDS broker is as follows:

1. mstsc.exe launches
2. wksprt.exe (RemoteApp and Desktop Connection runtime) starts
3. A new mstsc.exe process starts up.
4. The original mstsc.exe then exits (sometimes!)
5. wksprt.exe continues running.
6. User disconnects or RDS session times out
7. wksprt.exe terminates the mstsc.exe process it started OR
8. the original one terminates
9. About 7 seconds later, if either mstsc.exe session is still running, it terminates

The problem with this is it makes it nigh on impossible to properly monitor the user logon/logout workflow in any consistent way! We don't know from one iteration to the next, what it's going to do.

If we track the first MSTSC process only, we correctly detect the user logon AND the session disconnect from the client side, but only if that first instance is the one that presents the connection dialog. Every now and again the second MSTSC process is the one that presents the UI, not the first one, so step 4 leads us to think the user's RDP session has terminated when it's actually only just starting up.

And my particular favourite... every now and then, one MSTSC.EXE instance dies when the user disconnects but the other one sticks around for 7-8 seconds so if you place a dependency on the "logout detection" on BOTH instances disappearing there's an 8 second window where the PC is sat unlocked and anyone can break into the thin client desktop.

And of course, wksprt.exe doesn't die unless you kill it manually.

Window focus tracking works partially, but we don't want to end up having to do weird stuff like mitigating a user pressing CTRL-ALT-DEL and breaking out to the local desktop by booting them out of their RDS session.

Does anyone have any ideas on how best to tackle this?

Tim Staddon