Seeing “can not be loaded because running scripts is disabled on this system” typically indicates your PowerShell execution policy is blocking the script. This error pops up when you try to run a PowerShell script file (.ps1) and the system’s security settings prevent it. It’s a common frustration for IT admins, developers, and anyone automating tasks on Windows.
The good news is this error is easy to fix. You don’t need to be a scripting expert. In this guide, I’ll show you exactly what causes this message and how to resolve it step by step. We’ll cover multiple methods, from simple one-liners to permanent policy changes.
What Does “Can Not Be Loaded Because Running Scripts Is Disabled On This System” Mean?
PowerShell has a security feature called the execution policy. It controls what scripts can run on your computer. By default, Windows sets this policy to “Restricted” on most systems. This means no scripts are allowed to run at all. When you try to execute a .ps1 file, PowerShell checks this policy first. If it’s set to block scripts, you get the error message.
This is not a bug or a virus. It’s a safety measure. Microsoft designed it to prevent malicious scripts from running automatically. But it can be annoying when you need to run a legitimate script for work or personal projects.
Common Scenarios Where This Error Appears
You might see this error in several situations. Here are the most common ones:
- Running a PowerShell script from the command line
- Executing a script in Windows PowerShell ISE
- Using a script in a scheduled task
- Running a script from a network drive or downloaded file
- Automating tasks with scripts in DevOps pipelines
Each of these scenarios triggers the same underlying issue: the execution policy is too strict for what you’re trying to do.
How To Fix “Can Not Be Loaded Because Running Scripts Is Disabled On This System”
There are several ways to resolve this error. I’ll walk you through each method from simplest to most comprehensive. Choose the one that fits your needs and security requirements.
Method 1: Run PowerShell As Administrator
Sometimes the error appears simply because you don’t have enough permissions. Running PowerShell as an administrator can bypass some restrictions. Here’s how:
- Click the Start button and type “PowerShell”
- Right-click on “Windows PowerShell” and select “Run as administrator”
- If prompted by User Account Control, click “Yes”
- Try running your script again
This method works if the issue is permission-related. If the error persists, move to the next method.
Method 2: Check Your Current Execution Policy
Before changing anything, it’s smart to see what policy is currently set. Open PowerShell as administrator and run this command:
Get-ExecutionPolicy
This will return one of these values:
- Restricted – No scripts allowed (default on most systems)
- AllSigned – Only scripts signed by a trusted publisher
- RemoteSigned – Downloaded scripts must be signed, local scripts can run
- Unrestricted – All scripts can run (not recommended)
- Bypass – Nothing is blocked (least secure)
- Undefined – No policy set, uses default
If you see “Restricted,” that’s why you’re getting the error. Let’s fix it.
Method 3: Change Execution Policy Temporarily
You can change the policy just for your current PowerShell session. This is the safest option because the change doesn’t persist after you close the window. Run this command as administrator:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
The “-Scope Process” part means the change only applies to the current session. After you close PowerShell, the policy reverts to its original setting. Try running your script again in the same window.
This method is ideal for one-time script executions. If you need to run scripts regularly, consider a more permanent solution.
Method 4: Change Execution Policy For Current User
To make the change last for your user account only, use the “CurrentUser” scope. This doesn’t affect other users on the same computer. Run this command as administrator:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Now your user account can run local scripts and signed remote scripts. This is a good balance between security and convenience. You won’t see the error for your own scripts anymore.
Method 5: Change Execution Policy For All Users
If you need to run scripts across multiple user accounts on the same machine, change the policy at the machine level. This requires administrator privileges. Run:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
This applies to all users on the computer. Be careful with this option. It lowers security for everyone. Only use it if you fully trust all scripts that will run on the system.
Method 6: Use The Bypass Policy
For maximum flexibility, you can bypass the execution policy entirely. This doesn’t change the policy permanently. It just tells PowerShell to ignore it for that specific command. Run your script like this:
powershell -ExecutionPolicy Bypass -File "C:\Path\To\YourScript.ps1"
Replace the file path with your actual script location. This method is great for running scripts from a batch file or scheduled task without altering system settings.
Method 7: Unblock The Script File
Sometimes the error occurs because the script was downloaded from the internet. Windows marks downloaded files as “blocked.” You can unblock the file easily:
- Right-click the .ps1 file and select “Properties”
- At the bottom of the General tab, check the “Unblock” box
- Click “Apply” and then “OK”
Alternatively, use PowerShell to unblock it:
Unblock-File -Path "C:\Path\To\YourScript.ps1"
After unblocking, try running the script again. This method often resolves the issue without changing the execution policy.
Understanding Execution Policy Scopes
PowerShell execution policies have different scopes. Knowing them helps you choose the right fix. Here’s a breakdown:
- MachinePolicy – Set by Group Policy for all users
- UserPolicy – Set by Group Policy for current user
- Process – Applies only to current session
- CurrentUser – Applies to current user permanently
- LocalMachine – Applies to all users on the computer
Policies set by Group Policy (MachinePolicy and UserPolicy) override other scopes. If your organization has strict policies, you might not be able to change them without IT help.
How To See All Policy Scopes At Once
Run this command to view every scope and its current setting:
Get-ExecutionPolicy -List
This shows you the effective policy and where it’s defined. If you see “Undefined” for most scopes, the default “Restricted” applies.
Preventing The Error In The Future
Once you’ve fixed the error, you can take steps to avoid it in the future. Here are some best practices:
- Always sign your scripts with a code signing certificate
- Store scripts in trusted locations
- Use the “RemoteSigned” policy for a good security balance
- Test scripts in a safe environment first
- Document any policy changes for your team
These practices help maintain security while allowing you to work efficiently.
Troubleshooting Persistent Issues
Sometimes the error persists even after changing the policy. Here are some things to check:
Group Policy Overrides
If your computer is part of a domain, Group Policy might enforce a specific execution policy. You can’t override this with Set-ExecutionPolicy. Contact your IT department if you need an exception.
Antivirus Software
Some antivirus programs block PowerShell scripts as a security measure. Check your antivirus settings and add exceptions for trusted scripts or PowerShell itself.
Corrupted PowerShell Profile
A corrupted profile can cause unexpected behavior. Rename or delete your profile file to test:
Rename-Item $Profile $Profile.bak
Then restart PowerShell. If the error goes away, your profile was the issue.
32-Bit Vs 64-Bit PowerShell
If you’re running a 32-bit version of PowerShell on a 64-bit system, the execution policy might be different. Make sure you’re using the correct version for your script.
Working With PowerShell Execution Policies Safely
Changing the execution policy lowers your system’s security. Always consider the risks before making changes. Here are some safety tips:
- Never set the policy to “Unrestricted” on production systems
- Use the “RemoteSigned” policy as a default
- Only run scripts from sources you trust
- Review script content before executing
- Use the “Bypass” flag for one-off scripts instead of permanent changes
Security and convenience are a trade-off. Find the balance that works for your environment.
Frequently Asked Questions
Why Do I See “Can Not Be Loaded Because Running Scripts Is Disabled On This System” Even After Changing The Policy?
This usually happens when Group Policy overrides your changes. Check the “Get-ExecutionPolicy -List” output to see if MachinePolicy or UserPolicy is set. If so, you need to contact your system administrator.
Is It Safe To Set Execution Policy To Bypass Permanently?
No, it’s not recommended. Bypass allows any script to run without any checks. This creates a significant security risk. Use it only temporarily for specific tasks.
Can I Run A Single Script Without Changing The Policy?
Yes, use the “-ExecutionPolicy Bypass” flag when launching PowerShell. For example: “powershell -ExecutionPolicy Bypass -File script.ps1”. This overrides the policy for that one execution.
What’s The Difference Between RemoteSigned And AllSigned?
RemoteSigned allows local scripts to run without signing, but requires downloaded scripts to be signed by a trusted publisher. AllSigned requires all scripts, including local ones, to be signed. RemoteSigned is more practical for most users.
Does Changing Execution Policy Affect All Versions Of PowerShell?
Yes, the execution policy applies to Windows PowerShell 5.1 and earlier. PowerShell 7 (Core) has its own execution policy that can be set independently. You may need to change both if you use multiple versions.
Final Thoughts On The Error
The “can not be loaded because running scripts is disabled on this system” error is a common roadblock for PowerShell users. It’s not a sign of a broken system. It’s just a security feature doing its job. With the methods I’ve outlined, you can quickly get past it and continue your work.
Remember to always prioritize security. Use the least permissive policy that still lets you do your job. The “RemoteSigned” policy is a solid default for most environments. For one-off scripts, the “Bypass” flag is your friend.
If you’re still stuck after trying these solutions, double-check your Group Policy settings and antivirus software. Sometimes the simplest fix is the one you overlooked. Keep experimenting, and you’ll find the right approach for your situation.
I hope this guide helped you understand and fix the error. PowerShell is a powerful tool, and now you know how to handle its security features like a pro.