How to Run a PS1 File in PowerShell (And Why It Sometimes Fails)

Running a .ps1 file — PowerShell's script format — sounds straightforward. Double-click, run, done. In practice, Windows often blocks the attempt entirely, throws a cryptic error, or opens the file in Notepad instead. Here's what's actually happening and how to handle it properly.

What a PS1 File Is

A .ps1 file is a plain text file containing PowerShell commands, saved with the .ps1 extension. PowerShell reads the file line by line and executes each command, just as if you'd typed them manually into the console. Scripts can automate backups, configure system settings, install software, manage files, or do virtually anything PowerShell commands support.

The catch: Windows deliberately restricts PS1 execution by default for security reasons. A double-clicked .ps1 file won't run automatically — it opens in a text editor instead. This is intentional.

The Execution Policy: The First Thing to Understand 🔒

Before a PS1 file will run, PowerShell checks the execution policy — a setting that controls which scripts are allowed to execute. There are four common policy levels:

To check your current policy, open PowerShell and run:

Get-ExecutionPolicy 

Most Windows systems return Restricted by default, which explains why scripts fail silently or throw permission errors.

How to Run a PS1 File: The Main Methods

Method 1: Run Directly from PowerShell (Recommended)

Open PowerShell, navigate to the folder containing your script, and call it using its path:

.YourScriptName.ps1 

The . prefix tells PowerShell the file is in the current directory. Without it, PowerShell looks for a system command with that name instead.

If the script is elsewhere, use the full path:

C:ScriptsYourScriptName.ps1 

If the path contains spaces, wrap it in quotes and use the call operator (&):

& "C:My ScriptsYourScriptName.ps1" 

Method 2: Change the Execution Policy

If you hit a policy error, you can adjust the setting — but understand the security implications first.

To allow locally created scripts while keeping downloaded scripts restricted (a reasonable middle ground):

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 

Using -Scope CurrentUser limits the change to your account rather than affecting the entire system. This avoids needing administrator elevation in many cases.

To revert when you're done:

Set-ExecutionPolicy Restricted -Scope CurrentUser 

Method 3: Bypass the Policy for a Single Run

If you don't want to change the system policy permanently, you can override it just for one execution:

PowerShell -ExecutionPolicy Bypass -File "C:ScriptsYourScriptName.ps1" 

This is commonly used in deployment tools, scheduled tasks, and automation pipelines where the script itself is trusted but the system policy stays locked down.

Method 4: Right-Click "Run with PowerShell"

Windows includes a right-click context menu option for .ps1 files: "Run with PowerShell." This works — but it uses the system-level execution policy, so if Restricted is active, the script still won't run. It also closes the PowerShell window immediately after execution, which makes it less useful for debugging.

Running Scripts That Require Administrator Privileges ⚙️

Some scripts modify system settings, install drivers, or touch protected directories. These require an elevated (admin) PowerShell session.

To open an elevated PowerShell window:

• Search for "PowerShell" in the Start menu
• Right-click → "Run as administrator"

Running a script without required elevation typically produces an "Access is denied" or "Insufficient privileges" error partway through execution — not always at the start, which can be confusing.

What Can Change the Outcome

Several factors affect whether a script runs cleanly:

• Where the script came from — Files downloaded from the internet carry a hidden "Zone.Identifier" tag. PowerShell treats these as remote scripts and applies tighter rules even under RemoteSigned. You can remove this tag by right-clicking the file → Properties → Unblock.
• PowerShell version — Windows PowerShell (5.1) and PowerShell 7+ handle some behaviors differently. Most basic script execution works the same, but module compatibility and certain syntax features vary.
• Script encoding — PS1 files saved with unusual character encoding can produce unexpected errors, particularly with special characters in file paths or strings.
• Scope of the execution policy change — Policies can be set at the Machine, User, or Process scope. A User-level RemoteSigned won't override a Machine-level Restricted set by Group Policy in a managed corporate environment.
• User account type — Standard accounts and administrator accounts face different restrictions, and domain-joined machines often have execution policies enforced centrally by IT.

The Part That Varies by Setup

The methods above cover the technical mechanics — and most personal or developer setups follow one of these paths. But whether a script runs cleanly also depends on things like Group Policy restrictions set by your organization, which PowerShell version shipped with your OS, whether the file was flagged as downloaded content, and what the script itself is actually trying to do.

A script that runs instantly on one machine might hit three separate blockers on another with a different Windows edition, account type, or IT policy in place. The commands are consistent — the environment around them is what shifts the result.