Script.ps1 Cannot Be Loaded Because Running Scripts Is Disabled on This System

Script cannot be loaded because running scripts is disabled on this system

When you try to run a PowerShell script the following error message is sometimes shown:

.\Script.ps1 : File C:\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.
At line:1 char:1
+ .\Script.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

This error message is caused by the configuration of the PowerShell Execution Policy.

Warning: The restrictions are in place to protect you from unintentionally running scripts that may damage your system.

The solution to getting rid of this error message and running your script is simple. But you need to consider the scope before deciding how to fix it:

  • Do you only want this particular script to run (here and now)? – or
  • Do you want to be able to run all scripts all the time?

(these are the two most common options used to solve this problem but more exist!)

If you’re only looking to run the script this one time, use the following command to allow it to run in the current PowerShell session:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

In the above command, the scope is set to ‘Process’. This means that the new execution policy is only valid in the current process. The old restrictions still apply outside of this specific PowerShell session.

Alternatively, if you want to be able to run scripts freely on your system going forward, use the following command:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

When the scope is set to ‘User’, the new PowerShell execution policy is persisted in the registry and will stick across PowerShell sessions and system reboots.

See a complete overview of Execution Policies and Execution Policy Scopes below.

How to Manage Microsoft 365 Without PowerShell

Googling PowerShell commands and switching between admin portals can be a huge time sink, especially for routine tasks like triggering Microsoft Entra Connect syncs, managing calendar permissions, or handling hybrid user issues.

That’s why many organizations are turning to EasyEntra to simplify and streamline daily Active Directory and Microsoft 365 management.

With EasyEntra, you can:
✅ Instantly provision and offboard hybrid users.
✅ Manage Entra ID and Exchange Online from a single, ADUC-style interface.
✅ Eliminate the need for PowerShell in first-line support.
✅ Retire your last on-premises Exchange Server for good while improving management of AD mail attributes.

Watch how EasyEntra fuses ease of use with complexity to make user offboarding fast, accessible, and consistent:

👉 Check out the full feature list or download your 30-day trial today:

✅ Installs in 10 seconds.
✅ No infrastructure changes required.
✅ Uses exactly the same security/authentication as AD and the Microsoft 365 admin portals (personal AD credentials + OAuth2)

PowerShell Execution Policies

PowerShell offers more execution policies than just the two mentioned previously.

In total, PowerShell offers seven different execution policies:

1. AllSigned

With the AllSigned execution policy, scripts that are signed by trusted publishers run without any intervention.

Scripts signed by untrusted entities will cause a prompt allowing you to run the script.

2. Bypass

With bypass, nothing is blocked from running, and no prompts appear with warnings.

3. Default

The default policy varies depending on the operating system:

For Windows clients, the default policy indicates Restricted.

For Windows server operating systems, the default policy indicates RemoteSigned.

4. RemoteSigned

With the RemoteSigned execution policy, any script downloaded from the Internet must be signed by a trusted publisher.

Local scripts can run without a digital signature on the script.

5. Restricted

This configuration allows you to run individual PowerShell commands but blocks the running of scripts including modules.

6. Undefined

This setting indicates that no execution policy is configured (for the current scope).

7. Unrestricted

This execution policy allows the running of unsigned scripts but warns the user when running scripts that are not from the local intranet zone.

PowerShell Execution Policy Scopes

The above PowerShell execution policies can be configured in five different scopes.

The scopes take precedence, from top to bottom, in the following order:

1. MachinePolicy

This scope is configured by the computer policy in a Group Policy Object (GPO).

It affects all users on the system.

2. UserPolicy

This scope is configured by the user policy in a Group Policy Object (GPO).

It affects only the users targeted by the GPO.

3. Process

This scope only affects the current process (PowerShell session).

When the current process is closed, the configured execution policy no longer exists.

4. CurrentUser

This setting only affects the current user and is persisted across reboots in the HKEY_CURRENT_USER registry hive.

5. LocalMachine

This setting affects all users on the system and is persisted across reboots in the HKEY_LOCAL_MACHINE registry hive.

How to Check Why Running Scripts Is Disabled

As execution policies can be set on different scope levels you need to review all of them to understand why scripts are being blocked on your system.

Use the following command to list the PowerShell execution policies configured for the various scopes:

Get-ExecutionPolicy -List

The output from the command may look similar to this:

PS C:\> Get-ExecutionPolicy -List

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

Keep in mind the higher scopes take precedence over lower scopes.

Further Reading

To dig further into PowerShell execution policies, look at Microsoft’s official documentation.

How to Manage AD and EXO Mailboxes In One Box

Many admins are frustrated that you need multiple web consoles and PowerShell modules to manage Microsoft 365.

With EasyEntra, all daily Microsoft 365 mailbox operations will become available directly in standard AD user properties. Even the configuration of calendar permissions, which is normally only available via complex PowerShell scripting:

If you’re looking to make your first-line helpdesk work efficiently and confidently, EasyEntra has got you covered.

✅ Reduced training of new Junior IT staff.
✅ No more escalation of (what should be) simple tickets to Senior IT.
✅ Automated onboarding and offboarding of users without complex, ever-changing PowerShell scripts.

Still not convinced EasyEntra is worth giving a spin? This is what our clients have to say:

“One of the best products I’ve used.” – CIO, Mirick Law, United States

“We really love working with EasyEntra.” – Head of IT, IKN GmbH, Germany

“It feels almost like a revolution.” – IT Manager, Arjeplog Kommun, Sweden

Improve the efficiency of your helpdesk today: Download the 30-day trial.