How to Execute a PowerShell Script from Task Scheduler | Set

Task Scheduler runs PowerShell scripts through powershell.exe with a -File argument and -ExecutionPolicy Bypass to prevent failures.

The procedure to execute a PowerShell script from Task Scheduler is straightforward once you know the exact fields to fill. Drop a .ps1 path directly into the program field and the scheduler does nothing — it expects an executable, not a script file. The fix is powershell.exe as the program, the script path as a -File argument, and one permission assignment that every guide mentions but too many skip. Here’s the setup that works across Windows 10, 11, and Server editions.

Why Task Scheduler Can’t Run .ps1 Files Directly

Task Scheduler launches executables and registered script interpreters. A .ps1 file lacks a direct executable association that the scheduler can use for automated runs behind the scenes. Point the task at the script file itself and it records a success while doing nothing — no output, no error, no event log entry. The scheduler only passes the script to the PowerShell engine when you specify powershell.exe as the program and supply the script path as a -File parameter. Skip the engine invocation and the task silently wastes its trigger.

Executing a PowerShell Script From Task Scheduler: Step Order That Works

Three parts of the configuration cause most failures: the program name, the arguments string, and the user rights assignment. Nail these and the rest follows standard task creation.

1. Create the Task

Press Win + R, type taskschd.msc, and press Enter to open Task Scheduler. Right-click Task Scheduler Library and choose Create Task. Skip the “Create Basic Task” option — it lacks the security settings needed for background execution.

2. Configure the General Tab

Give the task a descriptive name in the Name field. Under Security Options, select Run whether user is logged in or not so the task triggers even when no one is at the desktop. Choose a service account with a non-expiring password — a personal account whose password rotates monthly will break the task after one cycle. Check Run with highest privileges if the script writes to protected paths or modifies system settings.

3. Set Your Trigger

Click the Triggers tab, then New. Choose the schedule that fits your automation — Daily, Weekly, or On a schedule for repeated intervals. Task Scheduler’s trigger system is identical here to any other scheduled task.

4. Configure the Action (Critical)

Click the Actions tab, then New. Set Action to Start a program. In the Program/script field enter:

powershell.exe

In the Add arguments field enter:

-ExecutionPolicy Bypass -File "C:\Full\Path\To\YourScript.ps1"

Replace the path with your script’s actual location. The double quotes around the path are mandatory if any folder name contains a space. The -ExecutionPolicy Bypass flag tells PowerShell to run the script regardless of the system’s execution policy — without it, a Restricted policy silently blocks unverified scripts. A comprehensive breakdown of each field is available in Netwrix’s detailed walkthrough of automating PowerShell with Task Scheduler.

If your script uses relative paths to reference other files, set the Start in field to the script’s directory (e.g., C:\Scripts).

5. Lock Down Conditions and Settings

On the Conditions tab, uncheck Start the task only if the computer is on AC power for servers. On the Settings tab, check Allow task to be run on demand so you can test manually, and set Stop the task if it runs longer than to a reasonable value — one hour works for most scripts — to catch a hung process.

What Permissions Does Task Scheduler Need to Run PowerShell Scripts?

The user account running the task requires the Log on as a batch job permission, which Windows does not grant by default. Without it, the task fails with Error 256 or never launches — this applies even if the account is a local administrator.

Granting Log on as a Batch Job

Open Local Security Policy (Win + R, type secpol.msc, press Enter). Navigate to Security Settings → Local Policies → User Rights Assignment. Find Log on as a batch job in the right pane, double-click it, and add the user or group that will run the task. Click OK and close the console — the change applies immediately with no reboot required.

On Windows Pro or Enterprise systems, the same setting is accessible through gpedit.msc under Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.

The execution policy is the other hurdle. Windows defaults to Restricted, which blocks all scripts. The -ExecutionPolicy Bypass argument in the task action overrides this at runtime without changing the system-wide policy. If you prefer a permanent change, run:

Set-ExecutionPolicy RemoteSigned -Scope LocalMachine

Common Mistakes That Cause Silent Failures

A task that records a successful run but produces no output is almost always one of these problems. Adding Start-Transcript at the start of the script and Stop-Transcript at the end writes a log file that shows exactly where the script broke.

• Missing Log on as a batch job permission. The task never launches PowerShell. Fix: add the user via secpol.msc.
• Relative path in the -File argument. The argument needs the full absolute path. A relative path resolves against PowerShell’s working directory, not the script’s folder.
• No quotes around a path with spaces. A path like C:\My Scripts\Backup.ps1 without quotes is parsed as two separate arguments. Always wrap the path in double quotes.
• No execution policy override. PowerShell silently blocks the script under Restricted policy. -ExecutionPolicy Bypass in the arguments fixes this.
• Mapped drive dependence. Drives like Z: are unavailable to scheduled tasks running in a different session. Use UNC paths (\\Server\Share\File) instead.

Verifying Your Task Runs Correctly

Before trusting the schedule, test the task manually. Right-click it in Task Scheduler Library and choose Run. Check the Last Run Result column — The operation completed successfully (0x0) means it ran. Then confirm the script’s actual output: if it writes a file, a log entry, or an event, verify it exists. If manual launch succeeds but the schedule fails, the “Run whether user is logged in or not” setting is the usual suspect — the account may be locked, missing the batch job right, or have an expired password.

One final detail: if you added -NoExit to the arguments during testing, remove it for production. The flag keeps the PowerShell console open, so the task never completes and overlapping instances pile up on your next trigger.