PowerShell script won't execute as a Windows scheduled task

Question

I have a PowerShell script (that works). In Windows Task Scheduler I created a new task to execute "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe", passing the argument as my PS1 script. When the task runs I get a Last Run Result of 0x1.

I updated my script to write to a log file when the script opens and that isn't happening. It's almost like the task can't even open Powershell.exe.

Does this sound accurate? What could the issue be or how do I work around it?

briantist · Accepted Answer · 2017-10-05T21:16:43.997

72

If the problem you're having is with Execution Policy, then you can also set the execution policy of a specific invocation of PowerShell. This is what I usually do when executing PowerShell through a scheduled task:

powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File \\path\to\script.ps1

Why?

-NoProfile

This ensures that you don't rely on anything in the user's PowerShell profile, and avoids the overhead of executing that additional code.

-NoLogo

This mostly doesn't matter; maybe it does if you're capturing the output of your script. Mostly it makes me feel better.

-NonInteractive

Ensures that your task won't wait indefinitely if something in your script unexpectedly prompts the user. With this switch, the script will just exit instead; at least you'll have an error code instead of a hanging script.

-ExecutionPolicy Bypass

You can use Unrestricted here or whichever execution policy you like. This is probably the one you need the most.

Why I prefer setting Execution Policy this way:

Because I don't want the task to depend on a global non-default setting that you may have other reasons to change in the future. If some other process depends on a different execution policy, then it's not at odds with your task this way.

Plus it's always nice not to have to change the defaults. Less to remember/document/test.

Bonus

See JohnLBevan's answer for some additional causes of 0x1 result in a scheduled task.

edited Oct 05 '17 at 21:16

answered Aug 07 '14 at 00:04

briantist

45,546
6
82
127

2

An old answer, but it's still solving problems - Thanks! This solved a problem with a scheduled task that worked fine using an admin account but wouldn't run correctly using a service account. Checked the permissions and everything looked fine, but still kept getting an error. Running as listed above fixed the problem. – DoWhileNot Jun 27 '16 at 18:10
Also check if the account that is running the task has execute access to the folder you specify in the Scheduler Task. – Allan Simonsen Nov 10 '17 at 10:03
1

Thank you! I just added `-ExecutionPolicy Bypass` and my PowerShell script ran perfectly as a scheduled task in Windows. I'm so grateful that you shared this! I've spent days searching for the answer. Thanks again! – bhall Apr 30 '21 at 20:48
Glad to hear @bhall ! – briantist Apr 30 '21 at 23:59
2

For me, I found that the `File` switch has to come *after* `ExecutionPolicy` once, I rearranged the arguments to match this answer it began working – Baa Jul 08 '22 at 13:39
I had an issue inside a python script called by the task scheduler, where the root cause was using mapped network drives (e.g. P:\) paths instead of UNC. It failed whether I ran it directly or with a powershell wrapper. – Phlogi Aug 11 '22 at 09:13

JohnLBevan · Answer 2 · 2019-04-24T06:51:21.267

There are several possible causes for a PowerShell script invoked by the task scheduler to complete with code 0x1:

The execution policy does not allow the script to run. See Briantist's excellent answer for detail on this.
The task does not have the Run with highest privileges flag (checkbox on the task's General tab) enabled.*
Parameters are being passed to the script incorrectly. If using an approach such as -File ".\MyScript.ps1" -Parameter1 'Demo', instead try: -Command "& .\MyScript.ps1 -Parameter1 'Demo'"

*As Ben points out in the comments, Run with highest privileges doesn't have to be enabled / it depends if the script requires admin rights (e.g. if some commands like Set-ExecutionPolicy or Stop-Process may require these). If you're not sure, try ticking the option to see if it fixes your issue; if it doesn't seem to make a difference, leave it unchecked.

As noted, failure to `Run with highest privileges` is only one of several causes, and one should understand what it does, and confirm that it is in fact the cause of the failure, prior to leaving it checked. For an explanation of what, exactly, that checkbox does, see https://social.technet.microsoft.com/Forums/windows/en-US/7167bb31-f375-4f77-b430-0339092e16b9/how-does-quotrun-with-the-highest-privilegesquot-really-work-in-task-scheduler-?forum=w7itprogeneral . — Ben Johnson, Oct 24 '18 at 20:57

score 3 · Answer 3 · edited Nov 11 '18 at 05:52

I've done this before and had similar issues. It's almost always the PowerShell security settings. Most obviously, I would double-check your execution policy (assuming that you've set it).

Which user does the task run as? Has that user run a PowerShell script before? If I remember right, each user is prompted to "allow" PowerShell scripts to run (Y/N), when running a script for the first time (regardless of execution policy). That has bitten me before. Try:

logging-in as that user
check the execution policy
kick-off the script from a PowerShell prompt
reply to any prompts that follow.

After the first run, you shouldn't have to worry about that again, and it should run from the task scheduler just fine.

Depending on your domain security, you might also have to set the group execution policy. Here's an article that details how to do that, as well as a couple other things to check: PowerShell Security.

Thanks @BryceAtNetwork23! That article was very informative, and ultimately led me to the solution.. to check the checkbox "Run with highest privileges" lol. Thanks! — ewitkows, Oct 22 '12 at 17:07

score 2 · Answer 4 · edited Nov 11 '18 at 05:58

2

The previous answers are of great value. I added the below value in the Add Arguments field.

-noninteractive -nologo -command "&{path\to\script.ps1}"

Make sure to add the ampersand and enclose the path in curly braces. Don't forget to have double quotes before ampersand and after closing curly braces.

edited Nov 11 '18 at 05:58

Peter Mortensen

30,738
21
105
131

answered Oct 20 '17 at 05:14

Devesh3710

21
3

score 0 · Answer 5 · edited Jun 20 '20 at 09:12

If you don't have any error messages and don't know what the problem is - why PowerShell scripts don't want to start from a Scheduled Task, do the following steps to get the answer:

Run CMD as a user who has been set for Scheduled Task to execute the PowerShell script
Browse to the folder where the PowerShell script is located
Execute the PowerShell script (remove all statements that block the error notifications if any exists inside of the script like $ErrorActionPreference= 'silentlycontinue')

You should be able to see all error notifications.

In case of one of my script it was:

Unable to find type [System.ServiceProcess.ServiceController]. Make sure that the assembly that contains this type is loaded.

And in this case I have to add an additional line at the beginning of the script to load the missing assembly:

Add-Type -AssemblyName "System.ServiceProcess"

And the next errors:

Exception calling "GetServices" with "1" argument(s): "Cannot open Service Control Manager on computer ''. This operation might require other privileges."

select : The property cannot be processed because the property "Database Name" already exists

McQuestion · Answer 6 · 2020-12-08T19:25:51.683

I solved this issue using the above answer from @briantist, but I wanted to isolate exactly which switch was solving the problem.

It had nothing to do with -ExecutionPolicy, -Noninteractive, -NoLogo, -NoProfile or any other system privilege, user account running the script, etc.

Just needed to add -File in front of the script path in the Task Scheduler > Actions > Arguments field. Without this switch PowerShell was launching and the task history was showing Action Completed, but the script was not executing.