1

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?

|improve this question
  • Is this E: drive a network mapped drive? – afrazier Jul 22 '13 at 0:31
  • It's a local drive. I should have mentioned, this is running on a VM, so it's probably actually the same physical drive as the C: drive. – Knetic Jul 22 '13 at 0:41
  • A few requests, can you do the command NET USE from a command prompt and copy the output here, also can please run icacls E:/stuff and copy the output of that too? (please edit your question with these updates, don't post them as comments) – Scott Chamberlain Jul 22 '13 at 2:56
5

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.

|improve this answer
  • I wonder if there's some checkbox to toggle in the scheduled task definition to control this behavior – afrazier Jul 23 '13 at 1:09
  • If svcAccount is in the Administrators group, then just ticking the "Run with highest privileges" checkbox should enable it to access the path via its Administrator membership. – RomanSt Oct 27 '14 at 0:37
  • romkyns: No, at the time that I had the problem (admittedly, a year and a half ago), all the scheduled tasks I was running were with highest privileges and a service account. I no longer have access to the environment to test, so it's possible that it's since been fixed, but that was the behavior in 2013. – Knetic Jan 4 '15 at 5:29
  • Interesting - I found out that I cannot access files outside the local folder where my .cmd file was running, but when I changed the working folder on the Windows task to the same location as the .cmd file it could then access the files in the same folder (no permissions change needed). – James Wilkins Jan 29 at 5:03
3

Drive mappings aren't seen by services or tasks. Use an UNC path instead. 

\\server\share\directory\someprogram.exe

Another option is to schedule a batch file to run and include a drive mapping there. In a batch file it is easier to use pushd/popd to map without worrying about what drive letter it gets (pushd can map to a drive letter and switch to that drive letter, popd can unmap and return to the previous drive letter).

pushd \\server\share
\directory\someprogram.exe
popd
|improve this answer
  • Didn't work, it stated that access was still denied, even when using the UNC path (i also tried using the admin share path, e.g., "\\localhost\E$\stuff") When i ran a command window as the same service account that is being used by the scheduled task, and ran the same pushd/popd commands, it worked as expected. Only when running through task scheduler did it fail. – Knetic Jul 22 '13 at 18:02

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.