PowerShell says scripts are disabled? Check this first

A .ps1 file fails with “running scripts is disabled on this system”. Before copying a Set-ExecutionPolicy command from a forum, inspect the policy in the same PowerShell window that produced the error. Get-ExecutionPolicy and Get-ExecutionPolicy -List only read settings; they do not run the blocked file or change a policy. This guide covers PowerShell on Windows.

Check that the message is about execution policy

PowerShell reports policy-related failures with messages such as “running scripts is disabled on this system” or “the file is not digitally signed”. A “command not found”, missing path or unavailable module is a different problem; changing policy will not fix it.

Run these commands in the window where the failure happened:

Get-ExecutionPolicy
Get-ExecutionPolicy -List

The first command returns the effective policy for that session. The second displays the configured scopes. They are read-only checks. Microsoft documents both commands in the Get-ExecutionPolicy reference .

Here is an example of the output. It is a Microsoft documentation example, not a reading from your PC:

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

In this example, CurrentUser is more restrictive than LocalMachine, so the effective result is AllSigned. The separate Get-ExecutionPolicy command tells you what actually applies; you do not need to guess from a single row.

Read the scope before changing anything

A setting can apply to one session, one account, everyone on the computer or be managed by an organisation:

• MachinePolicy and UserPolicy come from Group Policy. If either contains a value on a work or school PC, ask your IT administrator before changing anything. A local command cannot override a Group Policy.
• Process applies to the current PowerShell session and its child processes. It goes away when that session closes.
• CurrentUser applies to your account. LocalMachine applies to all users of the PC.

PowerShell shows the scope values in precedence order. Read the effective result from Get-ExecutionPolicy, and avoid comparing a setting from one PowerShell window with an error from another: a session-level policy can differ. Microsoft's about_Execution_Policies reference explains the scope order and how Group Policy takes precedence.

What the policy names mean

The policy changes the conditions under which PowerShell loads configuration files and runs scripts. It does not decide whether code is useful or trustworthy.

• Restricted allows individual commands but blocks script files.
• RemoteSigned does not require signatures for scripts written locally. Scripts marked as downloaded from the internet must be signed by a trusted publisher unless they are unblocked.
• AllSigned requires scripts and configuration files to be signed by a trusted publisher, including files you wrote yourself. A signature does not guarantee that a script is harmless.
• Unrestricted allows unsigned scripts, while warning before scripts marked as coming from outside the local intranet.
• Bypass blocks nothing and gives no warning or prompt. Microsoft describes it for controlled applications that have their own security model; it is not a routine fix for an error.
• Undefined means no policy is set at that scope. Other scopes or the Windows default determine the effective result.

For exact behaviours and Windows-specific details, see Microsoft's about_Execution_Policies reference .

Why a downloaded script can be blocked

With RemoteSigned, the file's internet-origin mark can matter even when it is sitting in a folder on your PC. If the script is unsigned, PowerShell may refuse to run it. Microsoft also notes that some download methods do not add this mark, so a missing mark is not proof that a file is safe.

Unblock-File removes the mark; it does not inspect the code or establish who wrote it. Microsoft's own example says to read and verify a script before unblocking it. Do not use it just to make an error disappear, especially for a file from a message, an unfamiliar website or a prompt that told you to paste a command.

Get scripts from the publisher's official source. If the publisher provides a signature or checksum, follow its instructions to check it. If you cannot verify the source, leave the file alone.

Execution policy is not malware protection

Microsoft explicitly describes execution policy as not a security boundary. It is a defence-in-depth setting that can help prevent accidental script execution. It is not an antivirus scan, and a script that passes the policy check can still be harmful. A blocked file is not, by itself, proof that the file is malware.

If the error still does not make sense

1. Re-run both read-only commands in the exact PowerShell session that produced the error.
2. If a Group Policy scope is set, ask the administrator responsible for the PC.
3. If only a local scope appears, check whether the file came from a trusted publisher and whether it is signed. Do not change a machine-wide setting just because a search result recommends it.
4. If the error is about a missing command, path or module instead, troubleshoot that specific message.

Keep the exact error text, the PowerShell window and the scope output together when asking the publisher or IT for help. Never run an unknown script just because a policy error has gone away.

Microsoft references

• about_Execution_Policies
• Get-ExecutionPolicy
• Set-ExecutionPolicy

*This is a documentation-based diagnostic guide, not a malware test. It helps explain the policy error; it cannot establish that a particular script is safe.*