Fluxtail
Sign in Create account
Log Management Guides

How to Enable PowerShell Script Execution on Windows

Fix “running scripts is disabled” in PowerShell. Check policy precedence, use Process or CurrentUser RemoteSigned, and unblock one trusted script.

By Fluxtail Engineering Updated

To enable PowerShell script execution after “running scripts is disabled on this system,” first check the policy in the same PowerShell window that will run the script. On an unmanaged Windows computer, RemoteSigned at Process scope allows locally created scripts for that session; CurrentUser persists for your account. Neither option overrides Group Policy, and a downloaded, unsigned script may still need a separate file-level decision. Review the script before changing either setting.

Check the effective policy before changing it

These commands are read-only. Run them in the shell where the error appeared:

$PSVersionTable.PSVersion
$PSVersionTable.PSEdition
Get-ExecutionPolicy
Get-ExecutionPolicy -List

Get-ExecutionPolicy shows the effective value. -List shows the scopes that produced it. Microsoft documents the precedence as MachinePolicy, UserPolicy, Process, CurrentUser, then LocalMachine. The first two are managed by Group Policy; a local Set-ExecutionPolicy command cannot replace them. Process is session-only, CurrentUser belongs to your account, and LocalMachine applies to all users. See Microsoft's execution-policy scopes and precedence.

Check the edition as well as the policy. Windows PowerShell 5.1 runs as powershell.exe; PowerShell 7 runs as pwsh.exe. They can coexist, but their locally set execution policies are managed separately. A value you set in one should not be assumed to apply to the other. Repeat the inspection in the exact edition your terminal, editor, scheduled task, or launcher uses.

Allow a trusted local script in this session

If the effective policy is Restricted, or another local setting blocks the script, and no organizational policy forbids the change, set RemoteSigned only for the current process. This is a state change for this PowerShell session and its child sessions; it is not a one-file permission:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
Get-ExecutionPolicy
Get-ExecutionPolicy -List
& '.\trusted-task.ps1'

Run those commands from the directory containing the reviewed script, or replace the example with its actual path. RemoteSigned permits unsigned scripts created locally, but requires a trusted signature for files PowerShell identifies as downloaded from the internet unless you deliberately unblock that file. The process setting disappears when the session and its child sessions close. Microsoft's Set-ExecutionPolicy reference documents the scope and the immediate effect.

If you need the same behavior in future sessions under your Windows account, the narrower persistent state change is:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Get-ExecutionPolicy
Get-ExecutionPolicy -List

CurrentUser does not require an administrator session in the normal case. It affects scripts you run as that user, not just the one file that failed today. Do not make a machine-wide change merely to run a single trusted script. If Get-ExecutionPolicy still shows an unexpected value, use -List to find the higher-precedence scope instead of repeating the command with broader permissions.

Check a downloaded script's trust marker

A different error—“is not digitally signed” while RemoteSigned is effective—often means Windows marked the file as downloaded. This is separate from the scope setting. Check this file only with a read-only command in Windows PowerShell 5.1 or PowerShell 7 on Windows:

Get-Item -LiteralPath '.\trusted-task.ps1' -Stream Zone.Identifier -ErrorAction SilentlyContinue

If the Zone.Identifier stream appears, inspect the script in an editor and verify its source before making any change. Then, only if you trust this exact file, remove its downloaded-file mark with this file-level state change:

Unblock-File -LiteralPath '.\trusted-task.ps1'

Unblock-File removes the mark; it does not change the execution policy, sign the script, or prove the code is safe. It also does not satisfy an AllSigned requirement for an unsigned script. Avoid unblocking a whole directory or wildcard set to solve one file's error. Microsoft's Unblock-File documentation shows this specific Windows trust-marker behavior. Not every download method adds the marker, so its absence does not establish that a file is safe.

After reviewing and, if appropriate, unblocking the file, try the exact script again:

Get-ExecutionPolicy
& '.\trusted-task.ps1'

The last command runs the script and may change files, services, or data according to what the script does. It is not a read-only test. A successful policy change only means PowerShell can attempt execution; it says nothing about the script's correctness or its own side effects.

If the script is still blocked

Read the exact error rather than trying progressively wider policy settings:

  • MachinePolicy or UserPolicy is defined: The device or account has a Group Policy setting. Ask the owner of that policy to approve a signed script or change the managed rule. A local Process or CurrentUser value cannot win over it. Microsoft's Group Policy settings reference describes the “Turn on Script Execution” rule.
  • AllSigned is effective: Even locally written scripts need a trusted publisher signature. Removing a download marker is not a substitute for signing. Use the organization's signing path rather than weakening its rule.
  • RemoteSigned is effective but the file is unsigned: Check the specific file's download marker and origin. A network-share path can also be classified differently on some systems; copy or trust decisions should follow your organization's policy.
  • The policy permits execution, but another security error remains: AppLocker or App Control for Business can restrict code separately from execution policy. Send the exact error, edition, script path, and Get-ExecutionPolicy -List output to the device administrator; do not disable application control to make this command work. Microsoft's PowerShell security overview distinguishes these controls.
  • The script starts but fails inside its own code: Execution policy is no longer the cause of that failure. Check the line number, required permissions, dependencies, and arguments instead.

PowerShell execution policy is a guard against accidental script execution, not a security boundary. It does not authenticate a script's author or make unfamiliar code trustworthy. On Linux and macOS, PowerShell does not enforce Windows execution policies; Set-ExecutionPolicy cannot enable them there. For a broader explanation of policy choices and managed environments, see the full guide to allowing PowerShell scripts to run.