PowerShell: Running Scripts is Disabled on this System

By default, PowerShell’s execution policy in Windows prevents the execution of any PowerShell script files (*.ps1). When attempting to run a .ps1 file, the console displays the error Running scripts is disabled on this system. This security mechanism, known as the Execution Policy, is designed to protect the user’s computer from potentially malicious code in third-party PowerShell scripts.

Attempting to run a PowerShell script file from the console results in the following error:

.\posh_script.ps1

File C:\ps\posh_script.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170 UnauthorizedAccess

Note. PowerShell 7 (pwsh.exe) supports execution policies on Windows. On non-Windows platforms (Linux and macOS), PowerShell does not implement Windows execution policies. The effective execution policy behaves as Bypass, and Set-ExecutionPolicy is not supported. Keep in mind that running Set-ExecutionPolicy on non-Windows platforms does not change the behavior and returns a warning message.

Checking Execution Policy settings

To check the current Execution Policy settings on a computer, use the following command:

Get-ExecutionPolicy

Execution Policy Is Not a Security Boundary

Keep in mind that PowerShell Execution Policy is designed to help prevent accidental script execution, but it is not a security boundary. Users can bypass execution policies in several ways if they already have permission to run PowerShell commands. You should view Execution Policy as a safety feature rather than a complete security control.

Execution Policy values

The default policy setting is Restricted. The following values are available for the Execution Policy:

• Restricted — running PS1 scripts is not allowed; only individual commands can be executed directly in the PowerShell (or pwsh) console. This is the default execution policy for client operating systems like Windows 10 and 11.
• AllSigned — all PowerShell scripts must be digitally signed by a trusted publisher before they can run (including scripts created locally on the machine). Unsigned scripts are blocked regardless of whether they were downloaded from the Internet/written by the current user.
• RemoteSigned — allows to run all local PowerShell scripts. It’s also permitted to run remote scripts (including those downloaded from the Internet or received via email) if they are signed with a valid digital signature. This is the default policy for Windows Server.
• Unrestricted — enables execution of any PowerShell script. A warning appears when attempting to run remote PowerShell scripts that are not digitally signed.
• Bypass — execution of any scripts is allowed, with no warnings or prompts displayed.
• Default — resets the Execution policy to default. For Windows Server it is RemoteSigned, for Windows 11/10 it is Restricted,
• Undefined — no execution policy is configured for the scope. PowerShell uses the next available policy according to scope precedence. If all scopes are Undefined, the effective policy defaults to Restricted on Windows client OSs and RemoteSigned on Windows Server.

For detailed info on execution policies, see Microsoft’s about_Execution_Policies documentation.

Real Security Controls for PowerShell

Execution Policy helps prevent accidental script execution, but it should not be considered a security control against a determined attacker. If your goal is to restrict script execution/reduce the risk of malicious PowerShell activity, you should consider using the following technologies:

• Windows Defender Application Control (WDAC) — allows only approved apps and scripts to run.
• AppLocker — enables admins to control which scripts, executables, and installers users are allowed to run.
• PowerShell Constrained Language Mode (CLM) — limits access to advanced PowerShell features, .NET classes, COM objects, and other functionality often abused by attackers.
• Antimalware Scan Interface (AMSI) — allows security products to inspect PowerShell script content before execution.
• Script Block Logging — records PowerShell script content in the Windows Event Log for auditing and threat hunting purposes.

For enterprise environments, we recommend combining execution policies with app control technologies (such as WDAC or AppLocker) together with PowerShell logging and AMSI-enabled security products.

Changing PowerShell execution policy

Use the Set-ExecutionPolicy cmdlet to change the PowerShell execution policy setting. Many guides on the Internet suggest changing the policy settings to ‘Unrestricted’ in order to run a PowerShell script. However, this is the least secure option, and we do not recommend using it.

The most balanced execution policy in terms of security and convenience is the RemoteSigned policy. To change the settings, run:

Set-ExecutionPolicy RemoteSigned

Scripts Downloaded from the Internet. PowerShell identifies files downloaded from the Internet using the Mark of the Web (MOTW) attribute. Even with the RemoteSigned execution policy, downloaded scripts must be digitally signed unless the MOTW attribute is removed. Here is an example:

Unblock-File .\script.ps1

If you only need to run a PowerShell script once, a better option is to allow scripts to run only in the current PowerShell session:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Now you can run any local scripts within the current session until you close the PowerShell.exe console.

Run a Single Script Without Changing the Execution Policy

If you only need to run a specific script and do not want to modify the execution policy settings on the machine, you can launch PowerShell with the Bypass execution policy for that process only:

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -File .\script.ps1

The command mentioned above allows the specified script to run without changing the execution policy configured for the current user/machine.

The -NoProfile parameter prevents PowerShell profile scripts from loading, which can help you to avoid unexpected behavior during script execution.

You can use this method in:

• Scheduled Tasks;
• Software deployment tools (such as SCCM and Microsoft Intune);
• Automation scripts and CI/CD pipelines;
• One-time admin tasks.

Note. The Bypass execution policy applies only to the PowerShell process started by this command. It does not permanently modify the execution policy settings on the machine.

Scope parameter

Note that we used the Scope parameter in the last command. The Execution Policy has 5 scopes:

• MachinePolicy — enforced through Group Policy at the computer level.
• UserPolicy — enforced through Group Policy at the user level.
• Process — applies only to the current PowerShell session.
• CurrentUser — applies to the current user profile.
• LocalMachine — applies to all users on the computer.

List Execution Policy settings for different scopes:

Get-ExecutionPolicy -List

Higher-priority scopes override lower-priority scopes:

Restore the Default Execution Policy

If you no longer need a custom execution policy, you can restore the default behavior. In order to reset the execution policy to the default value for the OS, run the following command:

Set-ExecutionPolicy Default

On Windows client OSs, the default execution policy is Restricted. On Windows Server, the default is RemoteSigned.

Alternatively, you can remove the execution policy setting from a specific scope by setting it to Undefined:

Set-ExecutionPolicy Undefined -Scope CurrentUser

When a scope is set to Undefined, PowerShell uses the next available policy in the precedence order. If all scopes are Undefined, the effective execution policy falls back to the system default.

In order to check the current config, use the command:

Get-ExecutionPolicy -List

Why Set-ExecutionPolicy May Not Work

In some environments, especially in AD domains, you can enforce execution policy settings through Group Policy.

When you try to change the execution policy locally, PowerShell may return a message similar to:

Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope.

To determine which scope is currently controlling the execution policy, run the following command:

Get-ExecutionPolicy -List

If the MachinePolicy or UserPolicy scope has a configured value, the execution policy is being enforced through Group Policy and overrides local settings such as CurrentUser/LocalMachine.

Here is an example:

Scope ExecutionPolicy
—– —————
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser RemoteSigned
LocalMachine Restricted

In the example mentioned above, the effective execution policy is controlled by MachinePolicy, and local changes made with Set-ExecutionPolicy will not override the Group Policy setting.

Set Execution Policy settings through GPO

1. Open the Local Group Policy Editor (gpedit.msc).
2. Navigate to Computer (or User) Configuration > Administrative Templates > Windows Components > Windows PowerShell.
3. Open the Turn on Script Execution option.
4. Enable the policy and choose one of three options:
   Allow only signed scripts — AllSigned policy
   Allow local scripts and remote signed scripts — RemoteSigned policy
   Allow all scripts — Unrestricted policy
   

   

5. Save the settings and update the local Group Policy with the command:
   

   gpupdate /force

Set Execution Policy settings through Registry

Settings similar to this policy can be implemented directly through the registry:

REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v EnableScripts /t REG_DWORD /d 1 /f

REG ADD HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell /v ExecutionPolicy /t REG_SZ /d RemoteSigned /f

Verify the Effective Execution Policy

After changing the execution policy through PowerShell, Group Policy, or the registry, you should check the effective config by running the following command:

Get-ExecutionPolicy -List

The command displays the execution policy configured at each scope.

Here is an example:

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser RemoteSigned
LocalMachine Restricted

The effective execution policy is determined by the highest-precedence scope that has a configured value.

If you changed the registry settings directly, you may need to restart PowerShell/refresh Group Policy before the changes take effect.

In order to refresh Group Policy settings immediately, run the command:

gpupdate /force

Wrapping up

The Running scripts is disabled on this system error occurs because PowerShell’s execution policy prevents script execution by default.

In most cases, changing the execution policy to RemoteSigned provides the best balance between security and usability. For temporary cases, you should use the Process scope because it’s often the safest option due to the change applies only to the current PowerShell session.

In managed enterprise environments, you can enforce execution policy settings through Group Policy. If local changes do not take effect, you should use Get-ExecutionPolicy -List to determine whether a MachinePolicy/UserPolicy setting is overriding local config.

You should always use the least permissive execution policy that meets your operational requirements.

You should view Execution Policy as a safety feature rather than a security boundary. If you need to restrict PowerShell usage in enterprise environments, you should combine execution policies with technologies (such as WDAC, AppLocker, Constrained Language Mode, AMSI, and PowerShell logging).

Set-ExecutionPolicy RemoteSigned