4

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?

  • 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 '13 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 '13 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 '13 at 18:57
  • Don't use Unrestricted, use RemoteSigned instead. That way you can only be nailed by internal malicious code. – Xalorous Aug 30 '16 at 1:38
5

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.

  • 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 " – Xalorous Aug 30 '16 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 '16 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.

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

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

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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