5

I have a PowerShell script that runs manually using the PowerShell ISE. However, when run as a scheduled task using an administrator's credentials the task does not run with the expected results.

The script:

$request=new-object System.Net.WebClient
$request.DownloadFile("...url...", "C:\path\to\file.csv")

The administrator user has Full Control of both the script and the folder it is writing to. The URL exists and responds in a reasonable time (less than one second).

If I run the task manually the status is 0x41301 ("Currently Running") until I eventually end it. I have set the task up using both of these methods:

  1. Start a Program: C:\path\to\PS.PS1
  2. Start a Program: C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe with additional options -noninteractive -command "C:\path\to\PS.PS1"

Using option 1, the task history shows it has opened an instance of notepad.exe, but it never terminates it. Using option 2 it completes the task, but it doesn't download / create the file.

I have used Set-ExecutionPolicy Unrestricted as this is not a signed script.

How can I fix this problem?

Improve this question
4
  • 3
    Option 1 opens notepad.exe as that's the default action for the .PS1 file type -- that's what happens when you double-click a .PS1. Try these settings with option 2: "Start a program" "C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe" and "Add arguments" "C:\path\to\PS.PS1". You shouldn't need to worry about -noninteractive when running from a Scheduled Task unless you need it to interact with the desktop.
    – jscott
    May 4, 2013 at 10:27
  • 2
    and you dont want the -command flag you just specify the file: technet.microsoft.com/en-us/library/ee176949.aspx
    – Brock Hensley
    May 5, 2013 at 19:15
  • If you want to put your comment as an answer I'll accept it. I didn't use the -command flag, but still had issues. Turns out the script's path, even in quotes, can NOT have spaces. Scheduled Tasks wasn't reporting that as the fault, I ran it from the command line and it returned that as the error.
    – Aeisor
    May 9, 2013 at 18:57
  • Don't use Unrestricted, use RemoteSigned instead. That way you can only be nailed by internal malicious code.
    – Jeter-work
    Aug 30, 2016 at 1:38

4 Answers 4

Reset to default
6

As you are running a script file instead of a script block, the parameter that you should use is -File.

Additionally, setting the execution policy using the Set-ExecutionPolicy cmdlet does not guarantee that the script is executed in that context. The effective execution policy might be overwritten by group policy (GPO). To force this on on the execution of the file use the -ExecutionPolicy parameter

The command that you are looking for is as follows

powershell.exe -ExecutionPolicy Unrestricted -NonInteractive -NoProfile -File c:\path\ps.ps1

More information of these parameters can be found here.

Improve this answer
2
  • powershell.exe -ExecutionPolicy RemoteSigned -NonInteractive -NoProfile -File c:\path\ps.ps1 RemoteSigned is MUCH SAFER than Unrestricted. Your comment hits the key issue though, use -File to run the script, OR copy the contents of the script into the task and use -Command " script block here "
    – Jeter-work
    Aug 30, 2016 at 1:35
  • There's no additional value in setting the ExecutionPolicy to RemoteSigned as the file path is explicitly stated as local. The only reason it is at Unrestricted to circumvent malicious replacement of the local script downloaded from untrusted sources. In most cases, where the command line explicitly states a local path and the path is secured, you can use Bypass.
    – MFT
    Aug 31, 2016 at 3:38
1

The script file you are trying to run is not a natively trusted file. Use an ampersand before the file path to run the command:

Powershell.exe -ExecutionPolicy Unrestricted -Command { & 'C:\path\to\PS.PS1' }

Other PowerShell startup parameters can be found in PowerShell.exe Command-Line Help.

Improve this answer
0
0

Can you confirm your execution policy for all scopes, by:

Get-ExecutionPolicy -List

If you set the LocalMachine policy to RemoteSigned, you should be able to have a task definition like:

Start In: C:\Windows\System32\WindowsPowerShell\v1.0

Run: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -File c:\path\to\ps.ps1

Improve this answer
0

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.

https://technet.microsoft.com/en-us/library/cc722152.aspx
Improve this answer

You must log in to answer this question.

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