Home / server / Questions / 160480
In Process
DavidN
Asked: 2010-07-15 12:44:52 +0800 CST

Can a service spawn a login session? Build server woes

  • 772

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.

windows service testing build-server

3 Answers

  1. 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.

    • 5

  2. 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.

    • 1

  3. 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.

    • 0