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.

How to Manage Office 365 Without PowerShell

Googling PowerShell commands can be very time-consuming but is often needed, e.g., to synchronize Azure AD Connect, manage Office 365 calendar permissions, and more.

Organizations and companies across all verticals are now starting to use Easy365Manager to simplify and streamline their daily AD and Office 365 operations.

Easy365Manager is a snap-in to Active Directory Users & Computers that allows you to manage Office 365 licenses and mailboxes and perform Azure AD Connect synchronization directly from AD user properties:

With Easy365Manager, you no longer need PowerShell for your daily management, and you can even retire your on-premises Exchange Server.

Watch this on-demand webinar to fully understand Easy365Manager:

Easy365Manager webinar gif

Read the complete feature list here or download the no-risk 30-day fully-functional trial here.

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.