Обход и политика выполнения сценария power shell

Обход и политика выполнения сценария power shell

This guide focuses on PowerShell execution policies, explaining their importance, operation, management, impact on system security, and best practices. It seeks to provide an understanding of how these execution policies support effective script execution, and optimize system security in Windows environments.

This is also a good introduction to the idea of the verb-noun syntax that PowerShell utilizes. For example, we are going to make use of cmdlets called Get-ExecutionPolicy and Set-ExecutionPolicy. The Get and Set verbs are very common across all facets of cmdlets available in PowerShell. Wrap your mind around this verb-noun syntax and you will be well on your way to figuring out PowerShell on your machines.

How can I change the policy that will allow me to run the PowerShell script on my machine?
PowerShell screen

I have tried checking the solution described there:

How do you successfully change execution policy and enable execution of PowerShell scripts

but all the time I am getting that error on the attached screen

  • … -ne ‘AllSigned’) { Set-ExecutionPolicy -Scope Process Bypass }; & ‘C …
  •  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException
    • FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand

How do you successfully change execution policy and enable execution of PowerShell scripts

HKEY_LOCAL_MACHINE -> SOFTWARE -> Policies -> Microsoft -> Windows -> Powershell
changed to “ByPass”

  • To change the PowerShell execution policy, open PowerShell (admin) and run the “Set-ExecutionPolicy RemoteSigned” command to set execution to allow scripts. The “Set-ExecutionPolicy AllSigned” command allows scripts from trusted publishers. Or the “Set-ExecutionPolicy Unrestricted” command allows scripts without restrictions.
  • You can also run the “Set-ExecutionPolicy Restricted” to undo the changes and prevent scripts from running.
  • Finally, you can allow PowerShell scripts by changing the policy from the Windows 11 and 10 Settings app.

On Windows 11 (or 10), by default, when you try to run a script on PowerShell, it will fail with the “cannot be loaded because running scripts is disabled on this system” error message. This is because PowerShell has an “execution policy” security feature that controls how to load configuration files and run scripts to prevent malicious code from running on the system.

This guide will teach you how to change the execution policy to run scripts successfully on PowerShell on Windows 11 or 10.


That recommendation can be found in several MSFT docs I’ve read over the years, and a large number of presentations I’ve watched at security conferences I’ve attended.

Execution Policy in PoSH is “not” a security boundary or even control. At best it’s intent is to be an “are you sure?” prompt for untrusted code.




u/FLAFE1995 avatar


Execution Policy in PoSH is “not” a security boundary or even control. At best it’s intent is to be an “are you sure?” prompt for untrusted code.

Truest true has never been trued before. Truth.







u/nascentt avatar





Third-party code signing certificates are expensive, and with a recent change issued by the CA/Browser Forum, they must be installed on a HSM or smart card, increasing complexity of deployment & maintenance.

This is all worth it if you need code integrity to prevent tampering, AND have more things to sign than just some scripts, but is absolutely not worth it merely to run PowerShell scripts without changing Execution Policy.

And don’t assume everyone runs an AD DS CA; we deliberately don’t, nor do we run AD DS anymore, or have “on-premise” infrastructure.




Ive found ways around this issue by wrapping the contents of what was a scripts into a function, then calling that function in Invoke-Command.




Absolutely – & MSFT point out many ways of sidestepping this setting, and that this is because they never designed it as a security control.




u/MSgtGunny avatar


Preferably you would have a cert that is from a trusted ca in your environment and you would actually sign the script before deploying. If not, I would change it only for the session. Fallback, set it back to default after the install is run.




u/williamt31 avatar


Ideally you want to sign your code and ensure your environment is protected. That being said, I’ve used duck tape a few times by doing this in a .bat/.cmd file:

Powershell -NoProfile -ExecutionPolicy Bypass -File "%~dp0Script-Name.ps1"




You’re already using

PowerShell.exe -ExecutionPolicy Bypass -File .runme.ps1

So you’re already skipping the execution policy with this one

How do you know your script is not working?

How are you validating it ran?

How are you even running your command above?

Same question again but when you were running it before as part of the larger script?

Where is your software located? (I.e. double hop)?

What does your logging say?

Does the software setup even run without desktop?

Are you doing a silent install (vs just an unattended install)?

There are many many reasons for this to fail, you need to narrow down why, currently it seem you might just assuming execution policy is the issue




How to do it…

  1. Right-click on the PowerShell icon and choose Run as administrator:

    Figure 1.29 – Running PowerShell as adminstrator

  2. Type Get-ExecutionPolicy and press Enter in order to see the current settings for the PowerShell execution policy:

    Figure 1.30 – Running Get-ExecutionPolicy

    Figure 1.30 – Running Get-ExecutionPolicy

  3. You can see that the current execution policy is set to RemoteSigned. Here is a short description of the different options for the policy:

    Remote Signed: This is the default setting in Server 2019 and allows PowerShell scripts that are locally created to run. If you try running remote scripts (for example, downloaded from the internet), they must be signed by a trusted publisher in order to execute successfully.

    All Signed: With this setting, all scripts will only be allowed to run if they are signed by a trusted publisher.

    Restricted: With this setting, PowerShell is locked down so that scripts will not run.

    Unrestricted: This setting will allow PowerShell to run scripts with or without signing.

  4. For the purposes of our recipe and to make sure the scripts will run for us as we progress through these recipes, let’s set our execution policy to unrestricted. Go ahead and use this command:
    Set-ExecutionPolicy Unrestricted

Figure 1.31 – Output of Set-ExecutionPolicy

Figure 1.31 – Output of Set-ExecutionPolicy

:/>  Windows desktop folder

Common issues and solutions

Setting PowerShell execution policies can often lead to challenges impacting script and system operations. Some common issues include:

  • Access Denied:
  • Blocked scripts:
  • Untrusted scripts:
  • Elevate privileges:
  • Script signing: When using policies like ‘AllSigned,’ ensure that scripts are properly signed using valid digital signatures. This prevents false “Access Denied” errors.
  • Trust publishers: For ‘AllSigned’ and ‘RemoteSigned’ policies, establish trust with publishers by importing their certificates into the Certificate store.
  • Unblock files:
  • Check for scope issues: Be mindful of the execution policy scope. If encountering issues, ensure that the policy is set at the appropriate scope level.
  • Check for group policy restrictions: In domain environments, Group Policies may enforce specific execution policies. Verify the Group Policy settings that apply to the system, as well as its location.
  • Use PowerShell remoting
  • Check security software: Some security software may interfere with script execution. Temporarily disable or adjust settings to troubleshoot.
  • Check for conflicts: Be aware of potential conflicts between local and Group Policy settings. Ensure consistency in execution policy enforcement.

Managing PowerShell execution policies

  • MachinePolicy:
  • UserPolicy:
  • Process:
  • CurrentUser:
  • LocalMachine:

Getting ready

We will be working within a PowerShell prompt on our Windows Server 2019 server.

Manage Powershell execution policy with Group Policy

Using the option Turn on Script Execution is a great way to manage execution policy on computers in your organization if Group Policy is an option. Turning on this option and applying it to computers is the same as setting Restricted execution policy locally.

Set PowerShell execution policy with Group Policy
Figure 8 – Set PowerShell execution policy with Group Policy (Image Credit: Petri/Bill Kindle)

By Default, the state is set to Not Configured. You can begin to change it by double-clicking the setting:

Turn on script execution
Figure 9 – Turn on script execution (Image Credit: Petri/Bill Kindle)

To change the policy to something more secure such as AllSigned or RemoteSigned, simply select Enabled and then choose either Allow only signed scripts (AllSigned), or Allow local scripts and remote signed scripts (RemoteSigned):

Set the execution policy using PowerShell
Figure 10 – Set the execution policy using PowerShell (Image Credit: Petri/Bill Kindle)

Once you are satisfied with your change, click OK to exit the configuration and close the Group Policy Management Editor. All that’s left is to place the policy in the correct Active Directory OU or site to begin applying to your endpoints.    

Using Set-ExecutionPolicy to manage PowerShell execution policy

How to list execution policies

# List All Execution Policies applied to All Scopes
Get-ExecutionPolicy -List
Get-ExecutionPolicy
Figure 5 – Get-ExecutionPolicy (Image Credit: Petri/Bill Kindle)

How to check current policy

Use Get-ExecutionPolicy. For specific scope details, use the -Scope parameter.

# Example: How to get current Exeuction Policy for Current User
Get-ExecutionPolicy -Scope CurrentUser
Get-ExecutionPolicy with scope
Figure 6 – Get-ExecutionPolicy with scope (Image Credit: Petri/Bill Kindle)

Knowing the existing policy in effect can help in troubleshooting scripts that are not running or producing the expected results.

How to change execution policy using Set-ExecutionPolicy

On Windows, you might occasionally need to adjust policies. The below example would allow a script to run only in the current PowerShell session. When you close the session and reopen a new one, the policy no longer applies. Using Set-ExecutionPolicy allows you to be explicit in how scopes are affected by policy.

# Example: Temporarily bypassing the policy for a session.
Set-ExecutionPolicy ByPass -Scope Process

If a policy is defined at a more specific scope above the scope you are adjusting, you may see an error message like the one below:

Using PowerShell Set-ExecutionPolicy
Figure 7 – Using PowerShell Set-ExecutionPolicy (Image Credit: Petri/Bill Kindle)

PowerShell execution policy best practices

  • Production environment: In a production environment, it is prudent to adopt a more restrictive policy like ‘AllSigned’ or ‘RemoteSigned.’ This ensures that scripts are signed and authenticated before execution and reduces the risk of unauthorized or malicious code.
  • Development environment: In a development environment, a more flexible policy like ‘Bypass’ or ‘Unrestricted’ may be used to facilitate testing and troubleshooting. However, these policies should not be carried over to production environments.

How to safely manage and change policies

Best practices for managing and altering PowerShell execution policies include:

  • Document execution policies:
  • Mandate script signing:
  • Select the least permissive scope:
  • Review policies: Regularly review and audit execution policies across the environment. Ensure that policies remain aligned with security requirements and organizational guidelines.

The ProblemJump To Solution

When I attempt to run a PowerShell script (for example, MyScript.ps1), I get the error:

Click to Copy

MyScript.ps1 cannot be loaded because the execution of scripts is disabled on this system.

How do I enable script execution?

What are PowerShell execution policies?

  • AllSigned: With this policy, all scripts, including those created locally, must be digitally signed by a trusted publisher to execute. This approach ensures that only authorized scripts are permitted to run, but does run the risk of running any malicious scripts that have been signed.
  • Bypass: This policy permits the execution of any script without restriction. This policy should be used with extreme caution, if at all, as it can potentially expose systems to security risks by permitting the execution of unsigned and unverified scripts.
  • Default: With this type of policy, the default execution is set. Default sets the execution policy as restricted for Windows clients, and RemoteSigned for Windows servers. Both types of execution policies are explained below.
  • RemoteSigned: This policy requires that scripts downloaded from the internet be digitally signed for execution and be permitted. Locally created scripts can be executed without digital signature. This policy is considered by many to provide a pragmatic balance between usability and security.
  • Restricted:
  • Undefined:
  • Unrestricted: This policy grants unrestricted script execution, enabling both local and internet-sourced scripts to run without any restrictions. While convenient for development and testing, it should not be used in production environments owing to the significant security risks it represents.
:/>  «Включить веб-сайт в список сайтов с ограниченным доступом Chrome и в безопасные зоны Internet Explorer и переключиться в режим совместимости для доступа»

In the subsequent sections, we will explore the management, best practices, and implications of PowerShell execution policies.

Change execution policy on Windows 11 from PowerShell

To change the PowerShell execution policy on Windows 11 (or 10), use these steps:

  1. Open Start on Windows 11.

  2. Get-ExecutionPolicy
  3. Get-ExecutionPolicy -List
  4. Set-ExecutionPolicy RemoteSigned
  5. Set-ExecutionPolicy Restricted

    PowerShell change execution policy

Once you complete the steps, you can execute the script again, and it should now run successfully on Windows 11. If you no longer want to allow scripts to run on your computer, you can run the optional command mentioned in the steps.

https://youtube.com/watch?v=PXwltlq6YhU%3Fversion%3D3%26rel%3D1%26showsearch%3D0%26showinfo%3D1%26iv_load_policy%3D1%26fs%3D1%26hl%3Den-US%26autohide%3D2%26wmode%3Dtransparent

On Windows 11, you can choose from four different execution policies to allow or deny scripts:

  • Restricted — blocks any script file from running.
  • RemoteSigned — allows scripts to be created on the computer. However, scripts created on another device won’t run without a trusted signature.
  • AllSigned — allows all scripts to run. However, only if a trusted publisher has included a signature.
  • Unrestricted — runs any script without restrictions.

You don’t need to change the execution policy if you need to run a script that does not have the required parameters and does not return output. Instead, you can use the PowerShell.exe -File "FILENAME" -ExecutionPolicy Bypass command to bypass the restrictions.

Understanding PowerShell execution policy scopes

Now that you understand the different policies and their use cases, it’s time to look at the different policy scopes to which execution policies can be applied.

Lasts only for a single PowerShell session and any child processes from that session. On closure, $env:PSExecutionPolicyPreference is deleted.

Bolster PowerShell security with execution policy

PowerShell execution policies bolster your security framework, especially when combined with other protective measures. They allow PowerShell’s automation prowess to shine without compromising safety. Nevertheless, don’t lean on them as the sole security pillar. They’re more like gatekeepers, ensuring you act with caution.

How it works…

The PowerShell execution policy is a simple setting and easy to change, but can make a world of difference when it comes to running your first scripts. If configured to be more restrictive than you intend, you will have trouble getting your scripts to run and you may think that you have mistyped something, when in fact the issue is only the policy. On the other hand, in an effort to make your servers as secure as possible, on machines where you don’t need to execute PowerShell scripts, it makes sense to restrict this access. You may also want to read some additional information on the signing of scripts to see whether creating and executing signed scripts would make more sense in your own environment. There are some in-built server functions that rely on a certain level of security with your execution policy. Setting your policy to unrestricted on all your servers could result in some functions not working properly, and you may have to increase that level of security back to remote signed.

What is a PowerShell execution policy?

Execution policies in Windows PowerShell are not all-out security safeguards. Instead, envision them as protective switch covers. Their purpose is to prevent unintended script runs, especially from unverified sources. Let’s first look at and get a good understanding of what each policy can do.

Execution Policies are not intended to be your only security protection when using PowerShell scripts. Cyber security experts and PowerShell pros will tell you that execution policies alone are not foolproof. It’s quite literally the option to remove the guardrails and safety nets. With great power comes great responsibility and all that.

The Solution

To run PowerShell scripts, it may be necessary to change the PowerShell execution policy. The execution policy on most modern Windows systems is set to Restricted by default, preventing the execution of any PowerShell scripts. This is a security measure as PowerShell scripts can have powerful and dangerous functionality.

Click to Copy

To temporarily bypass the execution policy and run scripts in a single PowerShell session, we can specify the flag -ExecutionPolicy Bypass when starting PowerShell from Windows CMD or the Run dialog.

For example, the command below will run MyScript.ps1 without modifying the execution policy:

Click to Copy

powershell -noexit -ExecutionPolicy Bypass -File MyScript.ps1

To enable script execution permanently, we can use PowerShell’s Set-ExecutionPolicy cmdlet.

Click to Copy

This will allow execution of any locally written PowerShell scripts, but will also require that PowerShell scripts downloaded from the internet are digitally signed by a trusted publisher. This is the default setting for Windows Servers.

If this policy is still too restrictive, we can remove all restrictions with this command:

Click to Copy

This will allow any script to be executed. You will still be prompted for permission when executing a script from the internet.

A full list of execution policy options is available here.

Understanding PowerShell execution policies

There are 7 execution policies that Windows PowreShell can apply. Each one provides a very specific set of rules that determine what Windows PowerShell can do when trying to run a script.

:/>  Как проверить чем занято место на диске

All Windows clients are set to the restricted policy, and all Windows servers are set to remote signed by default. It’s important to consider this default setting when you are developing scripts on each Windows OS.

  • Only runs scripts signed by a trusted publisher.
    • If the source isn’t already trusted, you’re prompted before script execution.
    • This policy guards against rash decisions.

In the example below, you can easily set execution policy you want to enforce in your session:

# Example of running a script under AllSigned policy
Set-ExecutionPolicy AllSigned
Set-ExecutionPolicy AllSigned
Figure 1 – Set-ExecutionPolicy AllSigned (Image Credit: Petri/Bill Kindle)

With your policy set to AllSigned:

# This will prompt you if the script isn't trusted.
.\YourScript.ps1
Your PowerShell script isn't trusted
Figure 2 – Your PowerShell script isn’t trusted (Image Credit: Petri/Bill Kindle)

  • Ignores execution policies, offering no warnings or prompts.
    • Caution: Use only when you’re confident about the script’s safety.

In the example below, you are setting the execution policy to be in ByPass mode for the process scope:

# Example: Temporarily bypassing the policy for a session.
Set-ExecutionPolicy ByPass -Scope Process

  • Allows locally written scripts without a signature.
    • Scripts from the internet need a signature.
    • To unblock unsigned scripts, use Unblock-File. However, do so cautiously.

Let’s try it out assuming you have already set your computer to use the RemoteSigned policy. Download PowerShell/Scripts/play-happy-birthday.ps1 at master · fleschutz/PowerShell · GitHub and save it to a path your computer.

In the example below, assume you are using C:\Temp. When RemoteSigned is enabled, you will see the error below:

Your PowerShell script was blocked
Figure 3 – Your PowerShell script was blocked (Image Credit: Petri/Bill Kindle)
# Example of unblocking a downloaded script
Unblock-File -Path .\play-happy-birthday.ps1
PowerShell Unblock-File
Figure 4 – PowerShell Unblock-File (Image Credit: Petri/Bill Kindle)

You should hear “Happy Birthday” playing on your computer.

There are some benefits with using this mode as the default on servers. Using remote signed helps prevent potentially malicious scripts downloaded from the internet from running on your system unless it is signed by a trusted publisher. It’s also flexible in that you are still allowed to run scripts that you have developed locally.

You also need to know that there are some pitfalls to RemoteSigned. Local scripts as you just learned can be run without being signed. What that means is that you could inadvertently create a harmful script, and if you can, so could a malicious actor that has local access to your machine. Don’t let this policy give you a false sense of security, because execution policies themselves are not meant to be a sole security boundary.

  • Default for client computers.
    • Allows individual commands but blocks scripts.

  • No policy for the current scope.
    • If all scopes are undefined, defaults apply.

  • For non-Windows, it’s the default and unchangeable.
    • On Windows, it runs everything but warns about external or intranet scripts.


Unrestricted might as well be the Wild West policy. Think of unrestricted as bypass without being told to bypass. It’s equally dangerous, and arguably more so because you no longer must specify that you do or do not want the guardrails and safety nets based on the script you are running. Now it’s the wild west, and anything goes.

Change execution policy on Windows 11 from Settings

On Windows 11 and 10, you can also allow scripts to run on PowerShell by changing the configuration of the command console from the Settings app.

From Windows 11

To change the PowerShell execution policy from the Settings app, use these steps:

  1. Click on System.

  2. Click the For developers page.

  3. Click the PowerShell setting.

From Windows 10

To change the PowerShell execution policy from the Settings app, use these steps:

  1. Click on Update & Security.

  2. Click the For developers page.

  3. Click the Apply button.

After you complete the steps, the setting will set the execution policy for PowerShell to “RemoteSigned.” This policy will allow you to run scripts without signing but will require signing for remote scripts.

Update July 12, 2024: This guide has been updated to ensure accuracy and reflect changes to the process.

Aligning with organizational security guidelines

Aligning Windows PowerShell execution policies with organizational security guidelines is vital for maintaining a secure and controlled scripting environment. Organizations often have specific security requirements and policies that dictate how scripts should be executed. By aligning execution policies with these guidelines, organizations can ensure consistency, reduce risks, and enhance overall security posture.

The Importance of regular audits and policy review

Regular audits and policy reviews ensure that execution policies remain effective and up to date. As organizational needs evolve and security threats change, execution policies may need adjustments. 

Conducting periodic reviews allows organizations to:

  • Adapt to a changing threat landscape: The cybersecurity landscape is dynamic. Regular policy reviews help organizations stay ahead of emerging threats and adjust policies accordingly.
  • Evaluate policy effectiveness: Organizations can assess whether the current execution policies are effectively mitigating risks or if adjustments are necessary.
  • Ensure compliance: Compliance requirements may change over time. Regular reviews help ensure that execution policies align with current compliance standards.
  • Identify policy conflicts: In complex environments, policy conflicts or unintended side effects can occur. Regular audits help identify and resolve such issues.
  • Maintain consistency:
  • Mitigate unauthorized scripts: Regular reviews can help identify and address unauthorized or malicious scripts that may exist in production undetected.

With a well-defined and consistently enforced execution policy strategy, organizations can harness the power of PowerShell scripting while maintaining a robust security posture.

A fundamental pillar of system security

PowerShell execution policies go beyond configuration rules and settings; they represent a commitment to consistent and secure IT operations. By adhering to the PowerShell execution policy best practices we’ve introduced, you are well on your way to a secure, efficient, and resilient Windows environment.