# Can a service spawn a login session? Build server woes

To run some acceptance tests on my build server, I need to have a logged in user session open (the white testing framework needs to have a "screen" to test the WPF UIs) all of the time. This is obviously a fragile setup, and it introduces quite a bit of friction in our process.

Would it be possible to have a windows service running in the background that can then "spawn" a session that it logs into as a user, does some work (in this case the testing), and then log off? Or is there possibly a better way to handle my situation than what we're doing right now? It gets frustrating because, for example, if the application crashes at some point, the exception dialog box pops up, freezing our build server. I was thinking of disabling dr wastson to handle this, but I have this feeling that I'm going down a path fraught with peril.

-

First of all, a little more detail about your environment helps. I assume it is either Windows 2003 or Windows 2008 Server.

To be honest, I am not an expert in this regard, but who uses this box? If you have admin privileges on the box, you can use psexec (if you have not heard of it, is a free Sysinternals utility). You can have it start a process on the console session (so with the interactive desktop, in psexec parlance). If you auto-login in a box with the right registry settings, you can have PsExec do this if security settings be damned. The registry keys include storing the password in plaintext, so I would lock such an account down.

PsExec executes a program on a remote system, where remotely executed console applications execute interactively.

Usage: psexec [\\computer[,computer2[,...] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-<priority>][-a n,n,...] cmd [arguments]

. . .

-d         Don't wait for process to terminate (non-interactive).
-i         Run the program so that it interacts with the desktop of the


So, for what its worth, I guess you could start a session, then have a scheduled task batch script that looks for which user is logged in then do the following, which start a process with a given session or the interactive desktop if you do not specify, and it will not wait for the process to exit either. It will just spawn it.

 %SYSTEMDRIVE%\path\to\psexec.exe -i -d C:\path\to\your\app.exe


Now, if you have one of the Windows Server products, I think you can get away with logging in occasionally with RDP (mstsc.exe) using the console parameter, now the admin parameter in Windows 2008.

Then again, this is the rambling of a noobie. I could be way off-base with this working. Someone more knowledgeable could help.

-
I'm not much less of a newbie, but this sounds very reasonable. I've solved similar issues using psexec. I was hoping to snag the bounty here, but I'd say you've earned it. David, any response? –  Jeff McJunkin Jul 19 '10 at 20:31
I've used psexec in the past, for some reason it didn't hit me to use it here. Unfortunately, psexec doesn't play nice when it comes to piping output, when running something on the same box. It seems if a user is already logged in, it launches the process in a separate window; consequently, you don't see any output. Also, psexec runs into problems when you try to kill the remote process; you have to do it manually. Although it's slow, I eventually went with a VM, as all of the other options seem more brittle to me. I think half a bounty is fair here, you'll get it if I don't mark your answer. –  DavidN Jul 26 '10 at 15:43
Just a follow up, VMWare Server is free and works really well. If you add the following lines to the .vmx to set process priorities: priority.grabbed = "normal" priority.ungrabbed = "idle" and be careful about how much memory you allocate to the VM, it actually runs with little noticeable overhead. –  DavidN Jul 26 '10 at 21:49

The whole "log in and do work" scenario is a bit of a chicken-or-egg problem.

I would start with AutoHotkey and see if I couldn't get it to automate the UI elements I needed to manipulate. Back in w2K days, I used to have have a group of machines where we blocked GPO inheritance in order to explicitly allow "do not use ctrl-alt-del" and then used autoexec.bat to launch a process. If you can get it to that point, AHK can automate the rest. At absolute worst, you might need to use AHK to automate a VNC session, to get around the complexities of logging in directly.

I'm not keen on the "Service" strategy. There are limitations between services and the UI; the "allow service to interact with desktop" optionbox hints at the trouble you might have there.

-

Perhaps auto-logon is an option.

Obviously you need physical server security controls in place if this is not a VM.

Launch the required testing services as Startup programs for the auto-logon user. If it crashes reboot the box (via scripted interaction with DRAC, iLO, VMware ESX, whatever it's running atop), and the services will start up anew.

-