How do I use Windows Task Scheduler to run an executable on a remote server?

Question

I am looking at consolidating all of our scheduled tasks that run on various servers (Win 2008 R2) within our domain on to one "Task Scheduling Server". I am a developer so I'm not even sure if this is a good idea or just a maintenance headache. One of our Network guys copied some of the tasks I monitor over to the new server and asked me to test them.

The main issue seems to be getting the application the task is trying to run, to run on the remote server rather than on the server that the task is scheduled on. The errors I am seeing are things like referenced dll's not being found. When I check the assembly the dll exists on the remote server but not on the Scheduling server. This makes me think that even though I have the "Start in" field filled in it isn't really starting in that location.

My settings on the edit Actions dialogue in this case are as follows -

Program/Script: \\server1\c$\some\long\path\myExe.exe
Add arguments (optional): arg1 arg2
Start in (optional):  \\server1\c$\some\long\path

Another example I have is with a batch file, and even with the "Start In" value set if I have relative paths in the script the paths are not found. If I change the paths to absolute paths it all works. In a batch file for example -

dir .\update /b /on >> ..\logs\logdir.txt

gets a invalid path error where as

dir \\server1\c$\my\path\update /b /on >> \\server1\c$\my\logs\logdir.txt

does work.

So my technical question is - how do it get the exe (and the batch file) to run on the remote server? And my network admin question is - is this a good way to manage scheduled tasks or is it better to have the schedules located on the same server as that which is doing the processing?

Solution

One way to accomplish this would be to use psexec like this:

psexec /accepteula yourserver.yourdomain CommandToExecuteRemotely

An alternative could be to enable PS Remoting on the remote server, then your scheduled task could be of the form

powershell -command "Invoke-Command -ComputerName yourserver.yourdomain  
    -FilePath ""C:\LocalScriptToExecuteRemotely.ps1"""

or

powershell -command "Invoke-Command -ComputerName yourserver.yourdomain  
    -Scriptblock { ScriptblockToExecuteRemotely }"

More alternatives with Powershell can be found in this chapter on remoting, e.g. using Invoke-RemoteExpression without having PS Remoting enabled.

Remember to use either the Windows CLI style escape character (caret: ^) or the Powershell style escape character (backtick: `) where applicable.

Also mind any required permissions on the remote machine – both presented solutions have options to pass credentials.

---

As for the admin question: it just depends on how you want to manage the tasks, but since you already need the executables on the remote server, I think in general it would be best to have the scheduled task also configured on the remote server.

The solutions above can still prove useful if you intend to then remotely manage your scheduled tasks using e.g. schtasks in your commands/scriptblocks :]
Note that the Powershell *-ScheduledTask cmdlets already incorporate the possibility to be run in a remote session or on a remote computer…

Comments

[Michael Hampton]

Whose bright idea was this? Many tasks run on specific servers because the work they do applies to that server. So moving them to another server would just cause you lots of headaches.

[joeqwerty]

This doesn't strike me as a particularly good idea, for reasons too numerous to mention.

[iamdudley]

@MichaelHampton My boss's idea. His background is network admin. I guess he'd like to be able to look at one place and see all the automated tasks that are running in his domain rather than having to know that tasks x, y, and z run on server1 and a,b, and c run on server2, etc. Possibly there are other ways to achieve this but it's not the sort of thing I usually work with so I just went with his suggestion.

[iamdudley]

@John-Gardeniers I'll try to make my future questions more terse. Cheers, James.

[Michael Hampton]

That's what we have monitoring systems for.