I have an executable that needs to be run on an E:/ drive, Windows Server 2012 is installed on the C:/ drive. I've created a scheduled task that has the full path to the target executable (E:/stuff/target.exe), and has the working directory set (E:/stuff/).
This fails, task scheduler tells me that the directory name is invalid. If i remove the working directory, it tells me access is denied. This can't be right, The entire drive is both shared, and has file permissions set to "everyone" with full control. The account running the task can definitely run it (i can do so through cmd.exe). Sidenote: I've tried all permutations of the path, using backslashes, forward slashes, quotes, and non-quotes. This is not due to KB2452723.
I've tried having a batch file which uses "CD" to set the working directory to E:/stuff/, then call the program, which works when i run it. Unfortunately, when run through Task Scheduler, it never changes the working directory, and tries to call target.exe from the system drive (where it doesn't exist).
I've also tried making a symbolic link ("mklink /D") from C:/temp/ to E:/stuff/, in the vain hope that i could fool task scheduler, but it won't follow the link, and tells me that the directory could not be found.
I cannot figure out why task scheduler would fight this so hard, nor what the correct practice would be to get this to work. Has anyone successfully run a file on a non-system drive with task scheduler?
Best Answer
After banging head against wall for a few hours, i found a solution. It appears that in Server 2012, scheduled tasks cannot touch directories which do not have explicit allow permissions for the account you're using to run the file. It doesn't matter if that account is in a group which is allowed into the directory.
e.g., If i want to run E:/stuff/target.exe using account THINGS\svcAccount , then THINGS\svcAccount must be given explicit full control over E:/stuff in order to run. I had assumed that if THINGS\svcAccount was in the administrators group, and the administrator group had full control over E:/stuff, it would inherit permissions. Server 2012 does not do that.
This only seems to apply to scheduled tasks - running a command window or a powershell window as THINGS\svcAccount works exactly as expected.