PowerShell Run Script: How to Execute .ps1 Files

PowerShell Run Script: How to Execute .ps1 Files

PowerShell Tips Editor 2 min read
PowerShell Run Script: How to Execute .ps1 Files

You just wrote your first .ps1 file and double-clicking it opens Notepad instead of running it — or opens a terminal that flashes and disappears before you can read any output. PowerShell run script execution has several methods, each suited to different situations: interactive terminal use, automation via Task Scheduler, passing arguments, and running with elevated privileges. This post covers every way to execute a .ps1 file with working examples and all the common failure modes explained.

Run from Terminal with .\

The most common way to run a script is from a PowerShell terminal using a relative path with the .\ prefix. The dot-backslash explicitly tells PowerShell this is a local path, distinguishing it from a cmdlet name:

# Navigate to the script's directory first
Set-Location "C:\Scripts"

# Run with relative path
.\MyScript.ps1

# Or run directly from any directory using relative path from current location
.\subfolder\MyScript.ps1

You cannot run a script by typing just its name (e.g., MyScript.ps1) because PowerShell does not look in the current directory for commands by default — this is a security feature.

Run with Full Absolute Path

Running with a full path works from any working directory and is the correct approach in scheduled tasks and automation:

# Absolute path — works from any directory
& "C:\Scripts\MyScript.ps1"

# The & (call operator) is required when the path is in a variable or contains spaces
$scriptPath = "C:\Scripts\My Script With Spaces.ps1"
& $scriptPath

# Without & — only works if path has no spaces and is not in a variable
"C:\Scripts\MyScript.ps1"    # This doesn't work — just returns the string
C:\Scripts\MyScript.ps1      # This works only without spaces, but fragile

Running as Administrator

Scripts that modify system settings, install services, or manage other users’ processes require elevation. Launch an elevated terminal, or start PowerShell elevated programmatically:

# Start an elevated PowerShell window
Start-Process pwsh.exe -Verb RunAs

# Start pwsh.exe elevated and immediately run a script
Start-Process pwsh.exe -Verb RunAs -ArgumentList "-File `"C:\Scripts\InstallService.ps1`""

# From an already-elevated session, just run the script
.\InstallService.ps1

# Check if current session is elevated
$isAdmin = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(
    [Security.Principal.WindowsBuiltInRole]::Administrator)
Write-Host "Running as administrator: $isAdmin"

Run from Task Scheduler

Task Scheduler runs scripts as a service without a visible window. The action must call the PowerShell executable explicitly:

$action = New-ScheduledTaskAction `
    -Execute "pwsh.exe" `
    -Argument '-NonInteractive -NoProfile -File "C:\Scripts\DailyReport.ps1"'

$trigger  = New-ScheduledTaskTrigger -Daily -At "06:00"
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Hours 1)
$runAs    = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest

Register-ScheduledTask -TaskName "DailyReport" -Action $action `
    -Trigger $trigger -Settings $settings -Principal $runAs -Force

Write-Host "Task registered"

Use pwsh.exe for PowerShell 7 or powershell.exe for Windows PowerShell 5.1. The -NonInteractive flag prevents prompts that would hang the task.

Passing Arguments to a Script

Scripts with param() blocks accept arguments. Pass them by name or positionally when calling the script:

# Script: C:\Scripts\Backup.ps1
# param([string]$Source, [string]$Destination, [switch]$Force)

# Call with named arguments (recommended)
.\Backup.ps1 -Source "C:\Data" -Destination "\\nas\backup" -Force

# Call with positional arguments (matches param order)
.\Backup.ps1 "C:\Data" "\\nas\backup"

# From Task Scheduler, use -File and pass args after
# -File "C:\Scripts\Backup.ps1" -Source "C:\Data" -Destination "\\nas\backup"

Common Errors When Running Scripts

The two most common barriers to running scripts are execution policy restrictions and path syntax errors:

# Error: "running scripts is disabled on this system"
# Check current execution policy
Get-ExecutionPolicy -List

# Fix: set policy for current user (no admin required)
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

# Error: path with spaces fails without quoting
.\My Script.ps1     # Fails — PowerShell sees "My" as a command
& ".\My Script.ps1" # Correct — call operator with quoted path

# Error: "file cannot be loaded because running scripts is disabled"
# For a one-time bypass (does not change policy permanently)
powershell.exe -ExecutionPolicy Bypass -File "C:\Scripts\MyScript.ps1"

Common Errors and Fixes

  • Execution policy blocks .ps1 from running. The default execution policy on new Windows systems is Restricted (Windows) or RemoteSigned. Set it per-scope with Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned. This does not require admin rights and only affects the current user. Execution policy is a per-scope setting — changing it in one scope does not change another.
  • Script in path with spaces needs quoting with & operator. A path like C:\My Scripts\Run.ps1 must be run as & "C:\My Scripts\Run.ps1". Without the & call operator, PowerShell treats the quoted string as a string expression, not a command to execute.

Related Cmdlets / See Also

Wrapping Up

Use .\scriptname.ps1 for interactive terminal use, & "full\path\script.ps1" when the path contains spaces or is in a variable, and the pwsh.exe -File syntax for Task Scheduler. Set execution policy with Set-ExecutionPolicy RemoteSigned -Scope CurrentUser for a permanent fix, or use -ExecutionPolicy Bypass on the executable call for a one-time override.

Send-Item -To