I've got a thing that I want to run on a server. This thing has to have a real desktop to interact with because it needs to perform automation (ghosting keystrokes and whatnot) on a program that runs on that server. I tried other methods of getting the thing done that I need to get done, and all the other paths failed, now I'm down to ghosting. (This is inviolate, I even talked to their tech support, there is no way to get done what I need to get done short of ghosting.)

The server in question can be configured to auto-log-in to a specific user, which I've done. The program is launched from an agent process running on that server (Tom will recognize it, it's the Jenkins agent). I discovered that I needed to change the agent from running as a service, to running as a program after the auto-log-in was complete, in order for the ghosting to work.

I can write any C# code that I like that will get launched, and it can call out to any other code that I want it to call out to. Right now it's calling out to an AutoIt program that launches the target app and ghosts in the desired keystrokes. This AutoIt app also has to call into the Microsoft test automation framework libraries to enumerate the contents of some of the menu items on that target app, because the target app was written in QT and AutoIt can't see the menu items all by itself.

Everything above *works* right now. Mostly.

Problem is that myself, or other users, might log into this server with remote desktop for maintenance purposes, and if they do, the ghosting fails to work afterwards. Regardless of whether they log out gracefully, or if they just close the remote desktop, either way that means that the screen of the server is now on the "lock" screen and not actually back at the real console desktop. This causes the automation to fail, at the part where it has to enumerate the menu items in the target application. It doesn't see anything because the target application isn't running on an actual live desktop.

I am able to force the logout of the remote desktop if, instead of just closing the remote desktop, I do these commands instead:

tscon.exe RDP-Tcp#0 /dest:console
tscon.exe RDP-Tcp#1 /dest:console
tscon.exe RDP-Tcp#2 /dest:console
tscon.exe RDP-Tcp#3 /dest:console
...

(actually only the first one is usually needed, the others are there for good measure in case more than one person tried to log in with RDP)

If I do that, or, if I reboot the server and never RDP into it in the first place, then the ghosting works. But if I close out of the remote desktop session WITHOUT issuing the above commands, then the ghosting fails because the computer isn't actually on an actual console/desktop session. Trying to issue TSCON commands after-the fact, after I have closed the remote desktop, don't work, they just say "Sessionname RDP-Tcp#0 not found" or whatnot.

What I'm trying to do is bullet proof this so that no matter what someone does to this server, the ghosting will work and will have a real live console session to do its nefarious work in.

Does anyone know of a way that, without the end-user being smart, that you can force the session back to the actual original logged in user session, after closing remote desktop? The behavior I would want would be like this:
- Computer boots up, auto-logs-in to user Administrator.
- Remote user logs into remote desktop, using User Administrator. The real screen of the server now says it's logged in remotely.
- Remote user ends his RDP session by clicking the close button on the window (not logging off, not running TSCON commands).
- Normally, this would leave the desktop at the "logged in remotely" lock screen. Instead, I want this to be back to the real desktop.

Anyone know how to make that happen in Windows Server 2008 R2?

The workaround that was done at a past game studio was to disable remote desktop and install VNC server on the machine. Clients then had to use a VNC client to get to the machine.

Not clean or ideal, but it's a workaround.

Run the broken program in a dedicated VM maybe?

Peter

This.

Or just get rid of the two programs concerned and use something that doesn't suck.

Aha, found the answer to my own question. I wasn't trying hard enough to go down the TSCON.EXE path.

This seems to work:

tscon.exe RDP-Tcp#0 /dest:console
tscon.exe RDP-Tcp#1 /dest:console
tscon.exe RDP-Tcp#2 /dest:console
tscon.exe RDP-Tcp#3 /dest:console
tscon.exe 0 /dest:console
tscon.exe 1 /dest:console
tscon.exe 2 /dest:console
tscon.exe 3 /dest:console
tscon.exe 4 /dest:console

One of those later ones (the "3" usually) seems to be the active console session and if you're on the lock screen then poof the lock screen is gone.

Interestingly (and perhaps predictably), it doesn't go back to the desktop if you have deliberately locked the desktop with the lock command. In that case it stays locked.

This only works if you've logged in via remote desktop, either left the RDP session open or closed it with the close button, and then you execute those commands on the machine.

Fortunately this was exactly the use-case I was trying to fix, so it works for me for now and produces the desired result.

Now on to the next step which is to see if it actually fixes the problem I was having. That's a task for tomorrow.

http://technet.microsoft.com/en-us/library/cc748841.aspx

A trigger tied to on disconnect from user session may do what you need.

Yup, I had already found that one, as a matter of fact, before even stumbling upon the final solution. At one point I had tried to set a trigger on user session disconnect, but using the earlier version of the command lines which didn't succeed at the desired task. I had been hoping that somehow the RDP session was still in its last stages of being active when the trigger got fired, but the session is instead completely disconnected by that time, so only the later-discovered versions of the command would work in that case. In any case, now I've got the correct information and commands, and I can implement then as triggers at RDP logoff or I can implement them in the program right before it does the ghosting, either way, or both.