Starting remote processes in a Windows network

Question

I have several slave machines and a master machine which together run a distributed application. Processes on each slave machine have to have a GUI and network access (I think it would be called an interactive process then). For ease of use it would be nice if the master machine could start/stop the processes on those slave machines.

My first idea was to use WMI and the Win32_Process class to start a remote process but upon further investigation it was reveiled that processes started this way are non-interactive and isolated, and thus cannot have any GUI. A note says that one can use Win32_ScheduledJob.Create to create a remote interactive process, but it runs under the LocalSystem account which I would like to avoid (also I couldn't even get it to run properly).

What would be good ways to solve this problem? Maybe it is possible to launch a helper application which in turn starts a proper process, but that seems quite dirty.

Edit: PsExec was really clunky when I tried it and slow as hell (not sure why). Looking further at PsExec it seems it installs a temporary service on the remote machine to launch the application. Would this be the only way to spawn an interactive process using a proper identity? Should I include a helper service in the setup for the nodes? But even then, how would I communicate with it then?

Answer 1

PsExec is part of the sysinternals suite that can do that

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

If your servers are running windows 2008 you can also use

Terminal Services Remote App

Answer 2

You can use the "at" command.

Open a command-line and type

at /?

Into the terminal. The one downside is that the time on the remote system needs to be within some reasonable delta of yours. It's also not instant. You have to wait a few seconds to make sure the remote scheduler doesn't miss the event entirely.

There is a WMI equivalent to this, and has the same basic caveats as at:

LISTING 3: Code to Create an Interactive Process on Windows Server 2003, Windows XP, and Win2K SP3 Machines

Const INTERVAL = "n"
Const MINUTES  = 1

strComputer = "compaq575"
strCommand  = "calc.exe"

Set objWMIService = _
    GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objScheduledJob = objWMIService.Get("Win32_ScheduledJob")

Set objSWbemDateTime = _
    CreateObject("WbemScripting.SWbemDateTime")
objSWbemDateTime.SetVarDate(DateAdd(INTERVAL, _
    MINUTES, Now()))

intReturnValue = objScheduledJob.Create(strCommand, _
    objSWbemDateTime.Value, False, 0, 0, True, intJobID)
WScript.Echo "Job ID: " & intJobID

I think most of the other ways to do it (without installing your own service) have been turned off by various service packs because of vulnerabilities.

Answer 3

The following two post use .NET to execute remote processes.

1. Using WMI

   http://weblogs.asp.net/steveschofield/archive/2006/06/06/WMI---start-a-process-on-remote-machine-passing-credentials_2E00_.aspx

2. Codeproject Example

http://www.codeproject.com/KB/IP/RemotingExec.aspx

The examples execute with custom credentials & the remote executable is a Win Form app. Hope this helps.

Answer 4

If the enire group is reasonably under your control, it may be possible to implement these remote processes as Windows Services. A service can be interactive (not by default though) and it can be remotely controlled via the standard Service Control Manager running on each Windows PC.

Answer 5

The PSTools suite was developed by Sysinternals and was so great that the company was purchased by Microsoft some time later. Using these tools is the best way to accomplish your task.

I see you mentioned a problem with running applications interactively. May I suggest using the /i switch to run the application interactively. PSTools offers all of the functionality you are looking for. You just need to play around with the switches to obtain your desired result.

I've never experienced the slowness you describe in my applications that use PSTools.

Answer 6

May I ask why the slave processes need to have a GUI? I have a similar set up, but needed a GUI only during initial set up.

Anyway, here's what I've done, but unfortunately it relies on the process running as the LocalSystem account, which I understand you're trying to avoid, if you really need the GUI.

To give you a little bit of background, the application I had to distribute was Hudson, and this was an earlier version where the way you distribute it is by running a Java WebStart application, and thus the need for a GUI (at least during set up, to help troubleshooting).

What I did was set up the slave applications as services on the slave machines by using sc.exe (which is a PITA to get right, fortunately you only do this once). Something along the lines of:

sc.exe create SlaveService binPath= c:\path\to\slave.exe type= interact DisplayName= "The Slave Service"

Note the spaces after the parameters (binPath= etc), those are necessary. Note also that I found it easier to drop the "type= interact" and manually change it in the service console.

Then on the master, also using sc.exe, I start the service remotely:

sc.exe \\slavemachine start SlaveService

And verified that the program was running on the slave machines.

Now in my case, I did not really need the GUI, other than for initial troubleshooting. As soon as I got everything running properly, I simply configured the service to run as a service account, but no longer in interactive mode.

I hope you find this helpful.

Answer 7

There's a couple of components you're going to need to make this happen.

First, you'll need a method of communicating with the remote machine.

Second, you'll need something on the remote machine listening that can start your application.

The other suggestions above all use something built-in for one or both of these components, which is fine, so long as the restrictions of any of the given solutions are appropriate.

PsExec looks like the most promising, out-of-the-box solution. Otherwise, you can roll your own app to listen to simple messages via TCP/named pipes/whatever and just spawn appropriate sub-processes. The only caveat with that is you'll want to be pretty careful around security, especially if any of the machines are publicly exposed.