Table of Contents
The error message you’re seeing: “PowerShell running script is disabled on this system” typically occurs because PowerShell’s execution policy is set to restrict the running of scripts.
The execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. Here’s how you can resolve this issue:
Check Current Execution Policy
First, to determine your current PowerShell execution policy, let’s open PowerShell as an Administrator and execute the following command:
Get-ExecutionPolicyThis command retrieves the current execution policy setting. If it yields ‘Restricted’, that is probably the reason the script is not executing.
Change Execution Policy
To enable script execution, you can change the execution policy with the Set-ExecutionPolicy command. There are several policies you can set, but the most common for enabling scripts are:
- RemoteSigned: Setting the execution policy to “RemoteSigned” allows you to run local scripts without any digital signature, while scripts from remote sources (like the Internet) must be digitally signed by a trusted publisher. This policy is a balance between security and usability, preventing potentially harmful scripts from running unless they are verified while allowing easier execution of local development scripts
- Unrestricted: Allows all scripts to run, which can be riskier as it doesn’t distinguish between local and downloaded scripts.
To change the policy, use the following command in PowerShell run as Administrator:
Set-ExecutionPolicy RemoteSigned
#Set-ExecutionPolicy UnrestrictedIt should now return the policy you just set.
Now that the execution policy has been changed, try running your script again. It should execute without the previous error.
Additional Notes
Execution policies can be set at different scopes (LocalMachine, CurrentUser, Process), which might override each other. If scripts still don’t run, you may need to specify the scope:
Set-ExecutionPolicy RemoteSigned -Scope LocalMachineBypassing Policy for a Single Session: If you do not want to change the policy permanently, you can bypass it for a single session:
powershell.exe -ExecutionPolicy Bypass -File "pathtoyourscript.ps1"This command runs your script with a policy of Bypass just for this session.
PowerShell Execution Policies:
PowerShell employs execution policies as a protective measure against potentially harmful scripts. These policies define the parameters for loading configuration files and executing scripts within PowerShell. Below is a summary of the various execution policies that are available in PowerShell:
1. Restricted
- This is the default execution policy on Windows client systems (Windows 10/11).
- Description: It does not allow any scripts to run. PowerShell will only allow individual commands.
- Use Case: Use this setting on systems where you want maximum security and do not need script execution.
2. AllSigned
- Description: Scripts can run, but only if they have been signed by a trusted publisher. Before running a script for the first time, you are prompted whether you trust the publisher.
- Use Case: This setting is used in environments where you need a high level of security and only want to execute scripts that are verified by a trusted entity.
3. RemoteSigned
- This is the default execution policy on Windows server systems (Windows Server 2012/2016…).
- Description: Allows scripts to run that are written on the local computer and not downloaded from the Internet. Any script downloaded from the Internet (including those received by email or from a network share) must be signed by a trusted publisher.
- Use Case: Ideal for a balance between operability and security. Commonly used where some level of script usage is necessary but still maintaining control over externally sourced scripts.
4. Unrestricted
- Description: This policy allows all PowerShell scripts to run. However, it will warn you before running scripts or configuration files that are downloaded from the Internet.
- Use Case: Useful in environments where scripts are a fundamental part of daily operations and there’s confidence in the source of all scripts running on the system.
5. Bypass
- Description: Nothing is blocked and there are no warnings or prompts. This execution policy is designed for configurations where scripts are integral to the application and blocking script execution is not desirable.
- Use Case: This setting is typically used in automated scenarios, such as scripts that may be part of automated deployment or testing processes where warnings and prompts need to be suppressed.
6. Undefined
- Description: No execution policy is set in the current scope. If all scopes are set to Undefined, the effective execution policy is Restricted.
- Use Case: This is used to effectively remove a more specific policy setting that has been configured at a narrower scope. This allows system defaults or higher scope policies to take precedence.
Not a reader? Watch this related video tutorial:
