Sleep or Pause to PowerShell Script

Last Updated on August 7, 2025 by Arnav Sharma

The error message you’re seeing, “PowerShell running script is disabled on this system,” typically occurs because PowerShell’s execution policy is set to restrict the running of scripts. The execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. Here’s how you can resolve this issue:

Step 1: Check Current Execution Policy

First, you need to check what your current execution policy is set to. Open PowerShell as an Administrator and run:

Get-ExecutionPolicy

This command will return the current execution policy setting. If it returns Restricted, this is likely what’s causing the script to not run.

Step 2: Change Execution Policy

To enable script execution, you can change the execution policy with the Set-ExecutionPolicy command. There are several policies you can set, but the most common for enabling scripts are:

  • RemoteSigned: Allows scripts to run if they are signed by a trusted publisher or if they are local scripts (not downloaded from the internet).
  • Unrestricted: Allows all scripts to run, which can be riskier as it doesn’t distinguish between local and downloaded scripts.

To change the policy, use the following command in PowerShell run as Administrator:

Set-ExecutionPolicy RemoteSigned

Or 

Set-ExecutionPolicy Unrestricted

It should now return the policy you just set.

Step 4: Run Your Script

Now that the execution policy has been changed, try running your script again. It should execute without the previous error.

Additional Notes

Security Warning: Setting the execution policy to Unrestricted is not recommended unless you fully trust your scripts. RemoteSigned is generally safer.

Policy Scopes: Execution policies can be set at different scopes (LocalMachine, CurrentUser, Process), which might override each other. If scripts still don’t run, you may need to specify the scope:

Set-ExecutionPolicy RemoteSigned -Scope LocalMachine

Bypassing Policy for a Single Session: If you do not want to change the policy permanently, you can bypass it for a single session:

powershell.exe -ExecutionPolicy Bypass -File "pathtoyourscript.ps1"

This command runs your script with a policy of Bypass just for this session.

PowerShell Execution Policies: 

PowerShell uses execution policies to help safeguard your computing environment from potentially malicious scripts. An execution policy is a feature in PowerShell that determines the conditions under which PowerShell loads configuration files and runs scripts. Here is an overview of the different types of execution policies available in PowerShell:

1. Restricted

  • Description: This is the default policy in PowerShell. It does not allow any scripts to run. PowerShell will only allow individual commands.
  • Use Case: Use this setting on systems where you want maximum security and do not need script execution.

2. AllSigned

  • Description: Scripts can run, but only if they have been signed by a trusted publisher. Before running a script for the first time, you are prompted whether you trust the publisher.
  • Use Case: This setting is used in environments where you need a high level of security and only want to execute scripts that are verified by a trusted entity.

3. RemoteSigned

  • Description: Allows scripts to run that are written on the local computer and not downloaded from the Internet. Any script downloaded from the Internet (including those received by email or from a network share) must be signed by a trusted publisher.
  • Use Case: Ideal for a balance between operability and security. Commonly used where some level of script usage is necessary but still maintaining control over externally sourced scripts.

4. Unrestricted

  • Description: This policy allows all PowerShell scripts to run. However, it will warn you before running scripts or configuration files that are downloaded from the Internet.
  • Use Case: Useful in environments where scripts are a fundamental part of daily operations and there’s confidence in the source of all scripts running on the system.

5. Bypass

  • Description: Nothing is blocked and there are no warnings or prompts. This execution policy is designed for configurations where scripts are integral to the application and blocking script execution is not desirable.
  • Use Case: This setting is typically used in automated scenarios, such as scripts that may be part of automated deployment or testing processes where warnings and prompts need to be suppressed.

6. Undefined

  • Description: No execution policy is set in the current scope. If all scopes are set to Undefined, the effective execution policy is Restricted.
  • Use Case: This is used to effectively remove a more specific policy setting that has been configured at a narrower scope. This allows system defaults or higher scope policies to take precedence.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.