Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

closed as too localized by Greg Askew, mdpc, Tom O'Connor, Khaled, Dave M Feb 13 '13 at 17:14

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
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. –  Michael Hampton Feb 12 '13 at 23:41
    
This doesn't strike me as a particularly good idea, for reasons too numerous to mention. –  joeqwerty Feb 13 '13 at 1:13
    
@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 Feb 13 '13 at 2:13
    
@John-Gardeniers I'll try to make my future questions more terse. Cheers, James. –  iamdudley Feb 13 '13 at 2:18
    
That's what we have monitoring systems for. –  Michael Hampton Feb 13 '13 at 2:34

1 Answer 1

up vote 3 down vote accepted

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…

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.