Anavem
Languagefr
How to Fix 'Running Scripts is Disabled on This System' PowerShell Error

How to Fix 'Running Scripts is Disabled on This System' PowerShell Error

Resolve PowerShell execution policy errors by checking current policies, setting RemoteSigned policy, and implementing security best practices for script execution.

April 9, 2026 12 min
mediumpowershell 8 steps 12 min

Why Does PowerShell Block Script Execution by Default?

PowerShell's "running scripts is disabled on this system" error occurs because Microsoft sets the default execution policy to Restricted for security reasons. This prevents malicious scripts from running automatically and protects users from potentially harmful code downloaded from the internet or received via email.

The execution policy system uses multiple scopes - from Group Policy settings that administrators control down to individual user preferences. Understanding these scopes is crucial because they override each other in a specific hierarchy, and simply changing one setting might not solve your problem if a higher-priority policy is in place.

What Are the Different PowerShell Execution Policies?

PowerShell offers several execution policy levels, each balancing security with functionality. RemoteSigned is the sweet spot for most users - it allows locally created scripts to run freely while requiring digital signatures for scripts downloaded from external sources. This policy prevents drive-by script attacks while maintaining productivity for legitimate development work.

The policy system works across both Windows PowerShell 5.1 (built into Windows) and the newer cross-platform PowerShell 7.x. If you have both versions installed, you'll need to configure policies separately for each, as they maintain independent settings.

When Should You Modify Execution Policies?

You'll encounter this error when running PowerShell scripts for automation, system administration, or development tasks. Common scenarios include running deployment scripts, configuration management tools, or custom automation solutions. The key is choosing the right approach - temporary fixes for one-time needs, user-specific changes for individual developers, or system-wide policies for managed environments.

Implementation Guide

Full Procedure

01

Check Current Execution Policy Settings

Before making changes, you need to understand your current PowerShell execution policy configuration. PowerShell uses multiple scopes that can override each other.

Open PowerShell as Administrator by right-clicking the Start button and selecting "Windows PowerShell (Admin)" or "Terminal (Admin)" on Windows 11. Run this command to see all policy scopes:

Get-ExecutionPolicy -List

This displays five scopes in priority order:

  • MachinePolicy: Set by Group Policy (highest priority)
  • UserPolicy: Set by Group Policy for current user
  • Process: Current PowerShell session only
  • CurrentUser: Registry setting for current user
  • LocalMachine: Registry setting for all users (default: Restricted)

Verification: Look for "Restricted" in the LocalMachine scope - this is what causes the error. If MachinePolicy or UserPolicy show anything other than "Undefined", your organization controls policies via Group Policy.

Pro tip: The first non-"Undefined" policy in the list takes effect. Group Policy settings always override local registry settings.
02

Apply Temporary Fix for Single Session

If you need to run a script immediately without changing permanent settings, use a temporary bypass. This is perfect for testing or one-time script execution.

For a single script execution, run:

PowerShell -ExecutionPolicy Bypass -File .\script.ps1

Replace script.ps1 with your actual script name. Alternatively, to bypass the policy for your current PowerShell session only:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

This allows you to run multiple scripts in the same session without permanent changes.

Verification: Run Get-ExecutionPolicy to confirm it shows "Bypass". Open a new PowerShell window and run the same command - it should show "Restricted" again, proving the change was temporary.

Warning: Bypass disables all security checks. Only use this for trusted scripts and close the PowerShell session when finished.
03

Set RemoteSigned Policy for Current User

The recommended permanent solution for individual users is setting RemoteSigned policy for the CurrentUser scope. This allows local scripts to run while requiring digital signatures for downloaded scripts.

Run this command in any PowerShell window (no admin rights needed):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

When prompted, type Y and press Enter to confirm the change. This policy:

  • Allows locally created scripts to run without signatures
  • Requires digital signatures for scripts downloaded from the internet
  • Only affects the current user account
  • Persists across PowerShell sessions and reboots

Verification: Run Get-ExecutionPolicy -Scope CurrentUser to confirm it shows "RemoteSigned". Test by creating a simple script:

echo 'Write-Host "Test successful!"' > test.ps1
.\test.ps1

The script should execute without errors.

Pro tip: CurrentUser scope is ideal for developers and power users who need script execution without affecting other users or requiring admin privileges.
04

Configure System-Wide RemoteSigned Policy

For system administrators who need to enable script execution for all users, set the LocalMachine scope. This requires Administrator privileges.

Open PowerShell as Administrator and run:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

Confirm with Y when prompted. This change affects all users on the system and persists in the Windows registry at HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.

For organizations using both Windows PowerShell 5.1 and PowerShell 7.x, set policies for both:

# For Windows PowerShell 5.1
powershell.exe -Command "Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine"

# For PowerShell 7.x
pwsh.exe -Command "Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine"

Verification: Run Get-ExecutionPolicy -List to confirm LocalMachine shows "RemoteSigned". Test with a different user account to ensure the policy applies system-wide.

Warning: System-wide changes affect security for all users. Consider using Group Policy in domain environments instead of direct registry modifications.
05

Unblock Downloaded Scripts

Even with RemoteSigned policy, scripts downloaded from the internet may still be blocked due to Windows security zones. These files have an alternate data stream that marks them as potentially unsafe.

To unblock a specific script file:

Unblock-File -Path .\downloaded-script.ps1

For multiple files in a directory:

Get-ChildItem -Path .\Scripts\ -Recurse | Unblock-File

You can also check if a file is blocked before unblocking:

Get-Item .\script.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

If this returns data, the file is marked as downloaded and needs unblocking.

Verification: After unblocking, the Zone.Identifier check should return no results. Try running the previously blocked script - it should execute without the "cannot be loaded because running scripts is disabled" error.

Pro tip: Right-click the script file in Windows Explorer and check "Unblock" in Properties as an alternative to the PowerShell command.
06

Handle Group Policy Restrictions

In corporate environments, Group Policy may override local execution policy settings. If MachinePolicy or UserPolicy show non-"Undefined" values, you'll need administrative intervention.

Check for Group Policy control:

Get-ExecutionPolicy -List | Where-Object {$_.Scope -match "Policy" -and $_.ExecutionPolicy -ne "Undefined"}

If Group Policy is controlling execution policies, you have these options:

  1. Contact your system administrator to modify the Group Policy setting
  2. Use Process scope bypass for temporary needs: Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
  3. Request policy exception for your user account or computer

For administrators managing Group Policy:

  1. Open gpedit.msc (Local Group Policy Editor) or Group Policy Management Console
  2. Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell
  3. Enable Turn on Script Execution
  4. Select Allow local scripts and remote signed scripts (equivalent to RemoteSigned)

Verification: After Group Policy changes, run gpupdate /force and restart PowerShell. Check Get-ExecutionPolicy -List to confirm the policy change took effect.

Warning: Group Policy changes affect multiple computers in the domain. Test policy changes in a controlled environment before domain-wide deployment.
07

Implement Security Best Practices

While enabling script execution, maintain security by following PowerShell best practices. Never use overly permissive policies like Unrestricted or Bypass for permanent settings.

Recommended policy hierarchy:

PolicySecurity LevelUse Case
RestrictedHighestDefault - no scripts allowed
AllSignedHighAll scripts must be digitally signed
RemoteSignedMediumLocal scripts OK, remote scripts need signatures
UnrestrictedLowAll scripts allowed (not recommended)
BypassNoneTemporary use only

For production environments, consider signing your scripts:

# Get code signing certificate (requires certificate authority)
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert

# Sign a script
Set-AuthenticodeSignature -FilePath .\script.ps1 -Certificate $cert

Monitor execution policy changes with this registry monitoring script:

# Check execution policy registry keys
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" -Name ExecutionPolicy -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" -Name ExecutionPolicy -ErrorAction SilentlyContinue

Verification: Regularly audit your execution policies with Get-ExecutionPolicy -List and ensure they align with your security requirements.

Pro tip: Create a PowerShell profile script that logs script execution for audit purposes: $profile shows your profile location.
08

Troubleshoot Persistent Issues

If the error persists after changing execution policies, several factors might be interfering. Here's a systematic troubleshooting approach.

Check for conflicting policies:

# Detailed policy analysis
foreach ($scope in @('MachinePolicy','UserPolicy','Process','CurrentUser','LocalMachine')) {
    $policy = Get-ExecutionPolicy -Scope $scope
    Write-Host "$scope`: $policy"
}

Verify PowerShell version and edition:

$PSVersionTable

PowerShell 5.1 (Windows PowerShell) and PowerShell 7.x maintain separate execution policies. If you're using PowerShell 7.x, ensure you've set policies for the correct version:

# Check which PowerShell you're running
if ($PSVersionTable.PSVersion.Major -ge 7) {
    Write-Host "Running PowerShell 7.x (pwsh.exe)"
} else {
    Write-Host "Running Windows PowerShell 5.1 (powershell.exe)"
}

Clear PowerShell cache and restart:

# Clear PowerShell module cache
Remove-Item -Path "$env:LOCALAPPDATA\Microsoft\Windows\PowerShell\ModuleAnalysisCache" -Force -ErrorAction SilentlyContinue

Then restart PowerShell completely (close all windows and reopen).

Test with a minimal script:

# Create and test simple script
'Write-Host "Execution policy test successful"' | Out-File -FilePath test-policy.ps1 -Encoding UTF8
.\test-policy.ps1

Verification: The test script should run without errors. If it still fails, check Windows Event Logs under Applications and Services Logs > Microsoft > Windows > PowerShell > Operational for detailed error information.

Warning: If none of these steps work, your system may have additional security software or policies blocking PowerShell execution. Contact your IT administrator for enterprise environments.

Frequently Asked Questions

What is the difference between PowerShell execution policy scopes?+
PowerShell uses five execution policy scopes in priority order: MachinePolicy (Group Policy for computer), UserPolicy (Group Policy for user), Process (current session only), CurrentUser (registry setting for current user), and LocalMachine (registry setting for all users). Higher priority scopes override lower ones, so Group Policy settings always take precedence over local registry changes.
Is it safe to set PowerShell execution policy to RemoteSigned?+
Yes, RemoteSigned is the recommended policy for most users as it provides a good balance of security and functionality. It allows locally created scripts to run without signatures while requiring digital signatures for scripts downloaded from the internet. This prevents most malware scenarios while enabling legitimate automation and development work.
Why does my PowerShell execution policy keep reverting to Restricted?+
This typically happens when Group Policy is controlling your execution policy settings. Check 'Get-ExecutionPolicy -List' for MachinePolicy or UserPolicy entries that aren't 'Undefined'. Group Policy settings override local changes, so you'll need administrator intervention to modify the Group Policy or use temporary workarounds like Process scope bypass.
Do I need to set execution policy separately for PowerShell 5.1 and PowerShell 7?+
Yes, Windows PowerShell 5.1 (powershell.exe) and PowerShell 7.x (pwsh.exe) maintain separate execution policy settings. If you use both versions, you need to configure policies for each one independently. Use the appropriate executable when setting policies: powershell.exe for 5.1 and pwsh.exe for 7.x.
How do I unblock PowerShell scripts downloaded from the internet?+
Use the 'Unblock-File' cmdlet to remove the Zone.Identifier alternate data stream that Windows adds to downloaded files. Run 'Unblock-File -Path .\script.ps1' for individual files or 'Get-ChildItem -Recurse | Unblock-File' for entire directories. You can also right-click the file in Windows Explorer and check 'Unblock' in the Properties dialog.

Discussion

Share your thoughts and insights

Sign in to join the discussion