Photo by Ferenc Almasi on Unsplash

So you've just written a perfectly good PowerShell script, you double-click it, and Windows throws this at you: "cannot be loaded because running scripts is disabled on this system." It's one of those errors that looks scarier than it is — but it trips up even experienced sysadmins who haven't touched a fresh machine in a while. The PowerShell script execution disabled error is Windows protecting you from yourself, basically, and honestly I get it. But when you're trying to get something done, it's annoying as hell.

Here's what's actually happening under the hood.

PowerShell has something called an Execution Policy — it controls what kinds of scripts are allowed to run on the machine. By default, Windows sets this to Restricted, which means no scripts at all. Not even ones you wrote yourself five minutes ago. This is a security feature, not a bug, and it's worth understanding before you just nuke it and move on.

Check What You're Working With First

Before changing anything, run this to see your current policy:

Get-ExecutionPolicy

If it spits back Restricted, that's your problem. But here's the thing though — you should also check at all scope levels, because group policy can be overriding your local setting without you knowing:

Get-ExecutionPolicy -List

This shows you the policy at every scope: MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine. I've wasted a good 20 minutes before wondering why my policy change "wasn't sticking" — turns out a domain GPO at the MachinePolicy level was overriding everything I set locally. Classic.

The Quick Fix (and When to Use It)

For most people running scripts on their own machine, setting the policy to RemoteSigned is the right call. It lets you run local scripts freely, but anything downloaded from the internet has to be digitally signed. Good balance of usability and safety.

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Using -Scope CurrentUser means you're only changing it for your own profile, not system-wide. That's the responsible move, especially on a shared or corporate machine. If you're on your personal dev box and you just want things to work, -Scope LocalMachine applies it for everyone on the system — but you'll need to run PowerShell as Administrator for that one.

To do that: right-click the Start menu, hit Windows PowerShell (Admin) or Terminal (Admin) depending on your Windows version, then run:

Set-ExecutionPolicy RemoteSigned

The Nuclear Option (Use With Caution)

Unrestricted removes basically all restrictions. I've seen people recommend this on forums and it makes me twitch every time. It'll run everything — including scripts from the internet with no signing requirement. If you're in a locked-down lab environment or just messing around locally with no external scripts, fine. But don't set this on a production machine and forget about it.

Set-ExecutionPolicy Unrestricted

There's also Bypass, which is similar but doesn't even show warnings. Used a lot in CI/CD pipelines or automated deployments where you control the environment completely.

Insider Trick #1: Bypass Without Changing Any Policy

Here's something a lot of people don't know — you can run a specific script with execution policy bypassed just for that single session, without touching your system settings at all:

PowerShell -ExecutionPolicy Bypass -File "C:\Scripts\MyScript.ps1"

This is super handy when you're running something once, or when you're on a machine you don't want to modify. I use this constantly when I'm deploying scripts on client machines and don't want to mess with their existing policy setup. It doesn't persist, it doesn't change anything — it just runs the script and goes home.

Insider Trick #2: Unblock a Downloaded Script

Even with RemoteSigned set, you might still get blocked on a script you downloaded. That's because Windows marks downloaded files with a hidden "Zone Identifier" tag — basically a flag that says "this came from the internet, be careful." You can strip that flag off with one command:

Unblock-File -Path "C:\Scripts\MyDownloadedScript.ps1"

After that, the script runs like any local file. Alternatively, you can right-click the .ps1 file in Explorer, go to Properties, and check the "Unblock" checkbox at the bottom of the General tab. Same result, more clicks. Up to you.

Worth noting — this is separate from execution policy. People mix these two up all the time. Execution policy is about what category of scripts can run. The Zone Identifier block is about the origin of a specific file. You sometimes need to deal with both.

What If You're on a Domain and Can't Change Anything?

If your organization's Group Policy is locking down execution policy — which you'd see as a MachinePolicy or UserPolicy entry in that Get-ExecutionPolicy -List output — you genuinely can't override it from PowerShell alone. That's by design. You'd need to either talk to your domain admin or use the Bypass flag trick mentioned above as a workaround, assuming that's not also locked down.

Some orgs lock things down hard for compliance reasons, and that's fair. Don't try to work around security policy on a corporate machine without knowing what you're doing and whether it violates policy. I'm not your IT department, but I've been that IT department, and we noticed.

Quick Reference

Here are the execution policy levels from most to least restrictive, just so you've got them in one place:

• Restricted — No scripts at all (default)
• AllSigned — All scripts must be signed by a trusted publisher
• RemoteSigned — Local scripts run freely, downloaded scripts must be signed
• Unrestricted — Everything runs, warnings on internet scripts
• Bypass — Everything runs, no warnings whatsoever

For 95% of situations, RemoteSigned at the CurrentUser scope is the answer. It's what I default to on any new machine I set up. Set it, forget it, move on with your life.

Hope this saves you from staring at that error message for the next half hour — I've definitely been there.

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