Photo by Andrew on Unsplash

So there I was, trying to run a perfectly legitimate deployment script at like 11pm, and PowerShell just stares back at me with that wonderful error: "cannot be loaded because running scripts is disabled on this system." Classic. If you've ever needed to change the PowerShell execution policy and found yourself clicking through five different Stack Overflow tabs, this one's for you.

Here's the thing though — execution policy trips people up not because it's complicated, but because there are actually several ways to set it, and they don't all behave the same way. Scope matters a lot here, and most quick-fix guides gloss right over that part.

What Even Is Execution Policy?

PowerShell's execution policy is basically a safety guardrail that controls which scripts are allowed to run on your system. It's not a security boundary in the hardcore sense — Microsoft's own docs will tell you that — but it does stop you (and your users) from accidentally running something sketchy. Think of it as a "are you sure about this?" mechanism that's baked into Windows.

There are a handful of policy levels you'll actually encounter in the wild:

Restricted — Default on Windows clients. No scripts run. Period. You can still run individual commands interactively, but .ps1 files? Nope.

RemoteSigned — Honestly, this is the sweet spot for most people. Scripts you write locally run fine. Scripts downloaded from the internet need a digital signature. It's a reasonable balance.

AllSigned — Every script, even ones you wrote yourself, needs to be signed. More secure, but way more annoying in day-to-day admin work. I've seen this bite sysadmins who forgot to re-sign a script after a minor edit.

Unrestricted — Everything runs. You'll get a warning prompt for internet-downloaded scripts, but they'll still execute. Use this carefully.

Bypass — Nothing is blocked, nothing is warned. This one's mostly for automation pipelines where you've already handled trust elsewhere.

The Basic Command to Change It

Open PowerShell as Administrator (right-click → Run as Administrator — yes, you need elevation for most of these) and run:

Set-ExecutionPolicy RemoteSigned

PowerShell will ask you to confirm. Hit Y and you're done. Simple enough, right? But here's where most guides stop and where real-world stuff starts to get interesting.

Scope Is Where It Gets Tricky

The -Scope parameter is the part that actually matters in enterprise environments, and I can't tell you how many times I've seen it ignored. PowerShell checks execution policy across multiple scopes, and they stack in priority order.

The scopes, from highest to lowest priority:

MachinePolicy and UserPolicy — Set by Group Policy. If your org pushes these via GPO, your manual changes will be completely ignored. I've seen people spend an hour troubleshooting this before realizing GPO was just overwriting everything.

Process — Only applies to the current PowerShell session. Gone when you close the window. Super useful for one-off scripts.

CurrentUser — Applies just to you, stored in your user registry hive.

LocalMachine — Applies to everyone on the machine. This is what you're setting when you use Set-ExecutionPolicy without specifying a scope.

So if you want to temporarily allow scripts just for your current session without touching system-wide settings, do this:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

That's actually my go-to when I'm testing something quickly on a locked-down machine. It doesn't persist, it doesn't require as much justification in a change ticket, and it doesn't leave the system more permissive than it needs to be afterward.

Check What's Currently Set

Before you change anything, it's worth knowing what you're working with:

Get-ExecutionPolicy -List

This shows you every scope and what's set at each level. Way more useful than just running Get-ExecutionPolicy by itself, which only shows you the effective policy. When something's being overridden by GPO, this is how you figure that out.

The Insider Trick Most People Don't Know

Alright, here's one that's saved me more than once — if you need to run a single script on a restricted machine and you really can't (or don't want to) change the execution policy, you can pipe the script content directly to PowerShell and bypass the restriction entirely:

powershell -ExecutionPolicy Bypass -File "C:\scripts\myScript.ps1"

Or if you want to get a little creative, you can read and invoke the script content like this:

Get-Content "C:\scripts\myScript.ps1" | Invoke-Expression

Fair warning — Invoke-Expression has a bit of a reputation and a lot of security folk will raise an eyebrow at it. Use it in controlled situations, not as a general habit. But in a pinch, it works.

The other trick worth knowing: if you're deploying a policy change across a fleet of machines via a remote management tool or a logon script, you can skip the confirmation prompt with the -Force flag:

Set-ExecutionPolicy RemoteSigned -Force

Without -Force, the confirmation dialog will stall your automation. Found that out the hard way during a rollout once. Fun times.

A Note on Group Policy

If you're in a domain environment and your execution policy keeps reverting — Group Policy is probably the culprit. Check with your AD admin or look under Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell in the Group Policy Management Console. There's a setting called "Turn on Script Execution" that will override whatever you set locally.

Honestly, if you're managing a team's machines, setting execution policy through GPO is the right way to do it anyway. Keeps things consistent and documented.

Quick Reality Check

Don't set everything to Unrestricted or Bypass just to make scripts run. I've seen this on machines where someone just wanted to stop fighting with the error — totally understandable frustration — but then those machines sit like that for years. RemoteSigned covers 95% of legitimate use cases without leaving the door wide open.

And always check your current policy list before and after making changes. Thirty seconds of verification saves a lot of head-scratching later.

Hope this saves you some time the next time PowerShell decides to play gatekeeper at the worst possible moment.

Related: PowerShell Execution Policy Explained (And How to Actually Fix It)