A current environment is using Scheduled Tasks to identify various robots which need to execute. All those robots points to the same executable. Most of them are launched from the main server, others from Apps server and another one from an email server. So, those robots are spreaded so to allow parallel execution and be able to deliver the response time necessarily to accomplish all the related tasks within the expected timeframe. But, no matter from which server they are launched, they are all pointing to the same EXE which is on the Web server in a location such as h:\Robot\Robot.exe.

All this is nice and has worked very well so far. In fact, from the Web interface, we can stop and start those tasks as we wish. So, if there is an update to send, we can stop them all, upload and restart them all.

But, in a new environment, the following now applies:

1. This will no longer be a local drive from a server but a share located on another computer
2. No log in session will be allowed from all the remote destinations to launch those executables

This brings a few concerns:

Presently, we have an issue with privileges as from the Web, I need to assign an account to be able to execute the Process class which will stop or start the Scheduled Tasks related entry. The fact that this is no longer a local drive causes a problem as I need a local account, then the Scheduled Tasks entry need a local account to execute but also need to have full privileges on the share located on another computer. So, suggestions such as wrapping this task inside a VBS and executing that instead has been proposed but this will just add to the complexitiy of the situation.

The goal:

1. I would like to eliminate completely the need to schedule task as there is really no need to do that as our goal is simply for our Web application to be able to start those robots
2. Eliminate the need to do a login on any server that will need to execute the h:\Robot\Robot.exe
3. Turn that into a Windows Service

Questions:

1. Is this the better approach? We have used that before in another product and it works well. We can stop and start the service remotely but everything is local.
2. I would need to start several instances of the Windows Service, is this possible?
3. If this is a Windows Service, I assume it means we will have to install the Windows Service on each server that will need to execute it. Is that correct?
4. The Windows Service need to be able to have full privileges on those shares. Does this means I cannot use the system account and is it possible to use a domain controller account to run it?

If that would all work, the only downsize will be that when upgrade time will come, I will have to upload at various locations the new version instead of only one location as is the case right now. The advantages would be that we will no longer have to configure a setup locally and only execute the Windows Service, which will not require a login and that will satisfiy the client.