16

When setting up a scheduled task, for the action section I'm trying to access an environment variable for the location of the executable that I wish to run. This is mainly because on one machine the executable could be in C: on another it could be on D: I've verified that if I use a hard coded path my scheduled task runs, but if I change the action to point to "%MyAppPath%\MyApp.exe" the task won't start suffering a launch failure. I've verified that the environment variable is set up.

Is it even possible inside the action (and working directory) part of task schedule to reference an environment variable - is my syntax wrong.

On a side note, I did think about calling a BAT file and referencing the environment variable there, but that doesn't solve anything for me as the main issue is actually knowning whether the application (and the bat file too) is on C: or D: drives - inside the drive itself the path is the same.

UPDATE: It turns out you can use them with a machine reboot but perhaps there is a better way

1

6 Answers 6

26

You do not need a machine reboot. You should terminate Taskeng.exe and the next time scheduled task is run it will get an updated environment.

1
  • Thank you so mcuh! I've been struggling with it for days. I've been trying to restart the Scheduler service to no avail in Win7/Win2008 (need to run as SYSTEM to restart it), but this is so much simpler!
    – Timur
    May 15, 2014 at 14:47
2

I thought that you could reference environment variables from the Task Scheduler, but having just tried, it doesn't look like you can.

The one exception appears to be %PATH% so would it be possible to add your MyAppPath value to the %PATH% collection on each machine, then then just call MyApp.exe from the task scheduler, where the machine will be able to resolve the fully-qualified path as required?

3
  • 1
    Interesting, I just tried with %PATH% and could not get it to work. At that point I noticed a stupid typo when I'd updated %PATH%. I fixed the typo and verified that PATH was OK in a DOS box, but task scheduled still reported the problem - indicating it was seeing the "bad" version of %PATH%. Rebooting was needed to pick up the change (as you can't restart task scheduler). At that point it turned out I could now use my original environment variable. So the upshot is that you can use environment variablees, but a full machine reboot is needed to pick up any changes/new environment variables Sep 2, 2011 at 11:39
  • Will mark this as the answer as you were correct that you can use them but if task scheduler has run before you modified the job / added the reference to an environment variable, it will need a reboot of the machine. Sep 2, 2011 at 11:41
  • 2
    See tsvayer's answer - you don't need to reboot the machine. Just the task scheduler process. Sep 10, 2013 at 11:25
1

On a side note, I did think about calling a BAT file and referencing the environment variable there, but that doesn't solve anything for me as the main issue is actually knowning whether the application (and the bat file too) is on C: or D: drives - inside the drive itself the path is the same.

%~d0 will expand to the drive letter of where the batch file is located. (%~dp0 for drive+directory, and so on.)

1

tsvayer's answer didn't quite work for me, on a computer running Windows 7, but it pointed me in the right direction. Task Scheduler seems to be a service on my computer; it's name is Schedule; the display name is Task Scheduler.

Besides restarting it from the Services MMC, it can be restarted with the following wmic commands run from a Command Prompt window (with administrator privileges):

wmic service where "name='Schedule'" call StopService
wmic service where "name='Schedule'" call StartService

You can of course also restart the service using sc:

sc stop Schedule
sc start Schedule

Based on trial and error, it seems sufficient to disable and then re-enable a single task, if that's all you need to affect:

schtasks /Change /TN \"The name of the task\" /DISABLE
schtasks /Change /TN \"The name of the task\" /ENABLE
5
  • You cannot run any of this commands for the Schedule service even from a privileged console Mar 27, 2021 at 2:08
  • @SergeyNudnov Did you test on a computer running Windows 7? Mar 28, 2021 at 16:40
  • 1
    Initially I tested on Windows Server 2012 R2. But your question is fair. I have just tested on Windows 7. sc stop Schedule from privileged console gives Access Denied Mar 29, 2021 at 14:38
  • @SergeyNudnov My answer is over six (6) years old. It wouldn't be surprising that even the last versions of Windows 7 might behave differently. Thanks for the updates! Mar 29, 2021 at 19:02
  • @SergeyNudnov On newer, or server, versions of Windows, the Task Scheduler service might have a different name. I'd think that wmic and its commands still work, but it's been a few years since I've worked with Windows servers much at all. Mar 29, 2021 at 19:04
0

On a side note, I did think about calling a BAT file and referencing the environment variable there, but that doesn't solve anything for me as the main issue is actually knowing whether the application (and the bat file too) is on C: or D: drives - inside the drive itself the path is the same.

Expanding upon grawity's answer, I use a two step process. This allows me to use the path in other statements when needed.

SET WD=%~dp0
pushd %WD%

NOTE: pushd changes both drive and directory. And if you wanted to be clean, popd when you're done.

0

Neither restarting the service, nor terminating TaskEng.exe worked for me for tasks that repeat. Tasks can be created as one-off/daily/weekly etc. However within that you can also get the task to repeat e.g. a daily task that repeats every 10 minutes during the day. If this "sub" repeat interval is set then it never picks up new environment variables until you reboot. The exception is if you have a "one-off" task that repeats at a set interval - in which case the environment variables are picked up.

So as a workaround, I was able to replace a "daily" task that repeated every hour, with a one-off task that repeated every hour indefinitely.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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