I'm trying to run a simple PS1 powershell script from the Task Scheduler. The task's Actions settings are Program: powershell and Add arguments: -executionpolicy bypass -file C:\Users\Robin\Documents\script.PS1.

The objective script.PS1 is accessed ok but a line within it (a call to another script: Rscript Z:\rscript.R) fails with the message:

Fatal error: cannot open file Rscript Z:\rscript.R
'rscript.R': no such file or directory

If I run the same line manually in Powershell it works ok. Moreover the following runs fine as a Run command: powershell -executionpolicy bypass -file C:\Users\Robin\Documents\script.PS1, which suggests the problem is in Task Scheduler. The task is set to run with highest privileges. I'm stumped.

Very grateful for assistance.

  • I wonder if its something to do with the 2nd script residing on a networked drive..
    – geotheory
    Commented Aug 8, 2013 at 12:38
  • Try creating a batch script to run powershell and call your script, then schedule the batch file. Let me know if it behaves the same way.
    – user201262
    Commented Aug 8, 2013 at 12:59
  • OK I've tried it using powershell.exe -file "C:\Users\Robin\Documents\script.ps1 and with Rscript Z:\rscript.R. In both cases the batch file works ok run manually but fails when called from Task Scheduler (same error message).
    – geotheory
    Commented Aug 8, 2013 at 13:47

6 Answers 6


I'm assuming that Z: is a network drive.

Scheduled jobs are (usually) run under a System account. Network drives aren't usually mapped for System. Even if you change it to run under your credentials (or any specific user credential), you just can't count on network shares being accessible. You'll need to either:

  1. Run the second script using a UNC path (and ensure that the system account has access to the UNC path)
  2. Map the network drive early on in your script (in PowerShell 3 you could use New-PSDrive, but), the simplest way is to run the NET USE Z: \\SERVER\SHARE command. Of course, you might need to add user credentials: password /USER:domain\user and you could also try adding /SAVECRED /PERSISTENT:YES and running that command once and hoping it sticks (but I'd still test-path and remap it if that's an option).
  3. Safest option: make a copy of the file locally.

Please check this one out from stackoverflow, seems pretty similar case: How can I convince powershell (run through task scheduler) to find my network drive?

  • The accepted answer on that page fails for me. When mapping the drive I get '$net' is not recognized as an internal or external command, operable program or batch file. And the environmental variables seem ok re system32 folder..
    – geotheory
    Commented Aug 8, 2013 at 14:44
  • Can i just say: $net.mappWHATTHEHECK? Just use net.exe
    – Jaykul
    Commented Aug 8, 2013 at 14:46
  • So what would the correct syntax? I'm not familiar with NET stuff. @zagrimsan is right about the network drive - the scheduler works fine on local files.
    – geotheory
    Commented Aug 8, 2013 at 15:01
  • Too bad I'm not familiar with PS but I'd have assumed it to work. The obvious alternate way would be to use UNC paths directly without mapping the drive, ie. using \\server\share\dir as proposed in the 2nd answer in the SO topic I linked.
    – zagrimsan
    Commented Aug 8, 2013 at 15:22

The command you tried from a batch file was wrong.

Try this command, and remember to keep the quotations.

powershell.exe -file ". 'C:\Users\Robin\Documents\script.ps1'" 

It seems that Task Scheduler doesn't manage correctly domain users validation... When you try to execute script manually user is identified as "[email protected]" When you try to execute it by Task Scheduler(only offline mode) user is identified as "user@" without domain. So in case script tries to copy or make any network operations that requires user validation results in no such file or not legal path errors etc...


Although you may have already found a resolution to your issue, I'm still going to post this note to benefit someone else. I ran into a similar issue. I basically used a different domain account to test and compare. The task ran just fine with "Run whether user is logged on or not" checked.

A couple of things to keep in mind and make sure of:

  1. The account being use to execute task must have "Logon as batch job" rights under the local security policy of the server (or be member of local Admin group). You must specified the account you need to run scripts/bat files.
  2. Make sure you are entering the correct password characters
  3. Tasks in 2008 R2 don't run interactively specially if you run them as "Run whether user is logged on or not". This will likely fail specially if on the script you are looking for any objects\resource specific to a user-profile when the task was created as the powershell session will need that info to start, otherwise it will start and immediately end. As an example for defining $Path when running script as "Run whether user is logged on or not" and I specify a mapped drive. It would look for that drive when the task kicks off, but since the user account validated to run task is not logged in and on the script you are referring back to a source\object that it needs to work against it is not present task will just terminate. mapped drive (\server\share) x:\ vs. Actual UNC path \server\share
  4. Review your steps, script, arguments. Sometimes the smallest piece can make a big difference even if you have done this process many times. I have missed several times a character when entering the password or a semi-colon sometimes when building script or task.

Check the link provided and hopefully you or someone else can benefit from this info. Be safe.


I run the following at the start of the script:

$pw = ConvertTo-SecureString "mypassword" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("domain\user", $pw)
New-PSDrive -Name X -PSProvider Filesystem -Root "\\\share"

Then I just use X as the drive instead of the share location (or the other drive letter if it's mounted to already). Simply put, I use X as a temporary drive to access the share that script uses.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .