Enabling script execution requires changing the execution policy to RemoteSigned via the Set-ExecutionPolicy cmdlet in an elevated PowerShell session.
Windows blocks PowerShell scripts from running by default, which means admin tools, automation scripts, and installers that depend on PowerShell often fail on the first try. The fix is a single command — Set-ExecutionPolicy RemoteSigned — run in PowerShell as Administrator. This allows local scripts to run freely while still blocking unsigned scripts downloaded from the internet, giving you the flexibility you need without lowering security more than necessary.
What Is PowerShell Execution Policy?
PowerShell execution policy is a security control that determines whether scripts can run on your Windows machine and under what conditions. It isn’t a complete security boundary — Microsoft describes it as part of PowerShell’s layered security strategy — but it prevents accidental execution of untrusted scripts. The policy applies at multiple scopes, including the local machine, the current user, and the current session, with the LocalMachine scope being the default.
Changing the policy at the LocalMachine scope requires administrator privileges. Changes at the CurrentUser or Process scope do not, which makes them useful for temporary or personal adjustments.
Which Execution Policy Should You Choose?
RemoteSigned is the standard recommendation for nearly every Windows user. It lets scripts you write on your own machine run without a signature while requiring a trusted digital signature for any script downloaded from the internet. This balances usability with safety and is the policy Microsoft documents as the practical starting point.
The other policies serve narrower scenarios:
- Restricted — Blocks all scripts. This is the default on most Windows systems and provides maximum security, but it makes routine scripting impractical.
- AllSigned — Requires every script, including your own, to carry a trusted digital signature. Secure but cumbersome for everyday use.
- Unrestricted — Allows all scripts to run but displays a warning for remote scripts. Useful for testing, but less secure as a permanent setting.
- Bypass — Disables all enforcement with no warnings. Intended for temporary use only, never as a long-term policy.
- Default — Resets the policy to whatever the system’s built-in default is, usually Restricted.
Enable PowerShell Script Execution With RemoteSigned
Changing the execution policy to RemoteSigned takes about thirty seconds. The command applies to the entire machine unless you specify a different scope.
- Open PowerShell as Administrator. Right-click the Start button and select Windows PowerShell (Admin) or Terminal (Admin). A User Account Control prompt will appear — accept it.
- Run the policy command. Type or paste:
Set-ExecutionPolicy RemoteSigned - Confirm the change. Type Y when prompted and press Enter.
- Verify the result. Run
Get-ExecutionPolicy. The output should show RemoteSigned.
Microsoft’s official Set-ExecutionPolicy documentation confirms this as the standard method for enabling script execution on Windows systems.
If you lack administrator rights, apply the policy at the current-user scope instead: Set-ExecutionPolicy -Scope CurrentUser RemoteSigned. For a change that reverts when you close PowerShell, use the process scope: Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned. This last option requires no admin rights and resets automatically.
Checking Your Current Execution Policy
Before making changes, see what policy is currently active. Run Get-ExecutionPolicy to display the effective policy for the current session. To view every scope level at once — including any Group Policy overrides — run Get-ExecutionPolicy -List. The output shows policies in order of precedence, with the most restrictive applicable policy taking effect.
| Policy | What It Allows | When To Use It |
|---|---|---|
| Restricted | No scripts run at all | Default setting; maximum security |
| RemoteSigned | Local scripts run; remote scripts need a trusted signature | Standard choice for most users |
| AllSigned | All scripts require a trusted digital signature | High-security environments |
| Unrestricted | All scripts run; remote scripts trigger a warning | Development or testing with caution |
| Bypass | Nothing is blocked and no warnings appear | Temporary use only — not secure as a permanent policy |
| Default | Resets to the system’s built-in default (usually Restricted) | Restoring original settings |
| Undefined | No policy is set at this scope level | When policy is inherited from a higher scope or Group Policy |
Common Mistakes That Block Script Execution
Even with the right policy in place, scripts can fail for other reasons. Here are the most frequent problems and their solutions.
| Problem | What You See | The Fix |
|---|---|---|
| Not running as Administrator | “Access to the registry key is denied” | Launch PowerShell with Run as Administrator before changing LocalMachine policy |
| Group Policy override | Policy changes have no effect; Get-ExecutionPolicy shows a different value | Group Policy overrides local changes — check with rsop.msc or contact IT support |
| Wrong PowerShell architecture | Policy set but scripts still blocked | Make changes in the 64-bit Windows PowerShell console, not Windows PowerShell (x86) |
Missing .\ prefix when calling a script |
“The term ‘ScriptName’ is not recognized” | Use .\ScriptName.ps1 instead of just ScriptName.ps1 |
| 32-bit and 64-bit mismatch | Policy shows different values in each console | Set the policy separately in each architecture if you use both |
| UAC confirmation not accepted | Policy change prompt hangs or is ignored | Accept the UAC prompt, or use -Force with the command |
| Restricted policy still active at a higher scope | “Running scripts is disabled on this system” | Run Get-ExecutionPolicy -List to find which scope is enforcing the block |
Restoring The Default Policy When You’re Done
If you enabled script execution for a one-time task — an installer, a setup script, or a single automation step — restore the Restricted policy afterward. This is especially important on shared or managed machines where other users or policies depend on the default.
Open PowerShell as Administrator and run: Set-ExecutionPolicy Restricted. Confirm with Y and verify with Get-ExecutionPolicy.
If you used a per-user or per-session scope instead, no restoration is needed. The Process scope reverts when you close the console, and CurrentUser affects only your account. These temporary options give you the freedom to run scripts without leaving the door open permanently.
One last detail: always call scripts from the current directory with the .\ prefix. .\ScriptName.ps1 runs the file in your working folder. Typing ScriptName.ps1 without the prefix is the most common mistake people make after changing the policy correctly.
References & Sources
- Microsoft. “Set-ExecutionPolicy (Microsoft.PowerShell.Security) — PowerShell 7.6.” Official cmdlet documentation covering syntax, scopes, and security guidance.