One of the more misunderstood PowerShell features is the script execution policy. PowerShell will gladly run any interactive command, something typed at a PowerShell prompt, that you have permissions and privileges to execute.

Jeffery Hicks

Jeffery Hicks is a multi-year Microsoft MVP in Windows PowerShell, Microsoft Certified Professional and an IT veteran with 25 years of experience specializing in automation. He works today as an author, trainer and consultant.

But what PowerShell won’t do is blindly execute a PowerShell script. The PowerShell execution policy is not a security boundary but is primarily intended to prevent the unintended or accidental execution of a PowerShell script.

Way back in the day, organizations were bombarded with malicious VBScript email attachments that users blindly launched, wreaking all sorts of havoc. Microsoft does not want to see a return to those days so by default, PowerShell will not execute or run any PowerShell script. This includes not only .ps1 script files, but also files with .psd1, .psm1 and .ps1xml file extensions.

There are some subtle variations but by and large, PowerShell execution policy is set per machine for all users. The execution policy is stored in the registry and only needs to be set once. To configure your computer you will use the Set-ExecutionPolicy cmdlet. This command must be run in an elevated PowerShell session with administrator credentials. The primary policy choices are:

  • Restricted: This is the default. PowerShell will not run any script, including PowerShell profiles.
  • RemoteSigned: PowerShell will run any script that you create locally. But any script that has been detected as coming from the Internet, such as via Internet Explorer, Microsoft Outlook, Mozilla Firefox or Google Chrome must be digitally signed with a code signing certificate that is trusted by the computer.
  • AllSigned: PowerShell will not run any script unless it has been digitally signed with a trusted code signing certificate.
  • Unrestricted: PowerShell will make no attempts to hinder script execution and will run any script. If the script comes from an untrusted source, like the Internet, you will be prompted once to execute it.

There is also a Bypass policy, which I don’t recommend for daily use. This policy will run any script without question or prompting. The assumption is that you have taken steps outside of PowerShell to verify the safety and integrity of the script.

To modify the policy, run Set-Executionpolicy and the setting you want to use.

PowerShell Execution Policy

PowerShell Execution Policy

As you can see in the screenshot you will be prompted to confirm the change. You can skip the confirmation by using –Force.

The change is immediate and does not require a reboot. Use the Get-ExecutionPolicy cmdlet to view the current policy.

At a minimum I recommend using a RemoteSigned policy. This is an effective balance between ease of use and security. Although you might not need a policy at all. Remember, this only applies to executing scripts. If you are remotely managing your servers from your desktop, you can leave the servers with the default Restricted policy and set a policy for your desktop. I am not a big fan of unrestricted because I think it leads to lazy behavior which could come back and bite you. Not that I think you will download an intentionally malicious PowerShell script, but that you might inadvertently run a script that will have a detrimental effect in your environment.

Ideally, you should strive for an all signed policy. If you have an Active Directory PKI you can request a code signing certificate which will be trusted by all domain members. When the script is digitally signed, if it is changed in any way, even by one character, the signature will “break” and PowerShell won’t run the script. I’m not especially concerned about malicious changes to a script. But if the script has been corrupted or changed in anyway I want to know before I start it and not after it has partially completed before failing so misbehaving. If PowerShell refuses to run a signed script that serves as a major warning for me to check script integrity.

You also need to be aware that a PowerShell execution policy doesn’t prevent someone from doing something stupid. Even with a restricted policy someone can open the script file in Notepad, and copy and paste the contents into a PowerShell session. If they have the necessary tools, permissions and privileges PowerShell will happily carry out the commands. You could still get burned but only because someone circumvented PowerShell’s script security features.

PowerShell’s execution policy is not especially difficult but it will take some planning on your part to develop an effective policy for your enterprise.

In my next post I will show you how to set PowerShell execution policy with Group Policy.

Win the monthly 4sysops member prize for IT pros


Related Posts

  1. Babun 4 years ago

    I was just pondering about this today and I rather understood that executionpolicy is not to be taken as a security barrier per se, but more as to avoid "oops" moments.

    I usually don't need a lot of powershell, but i set up some small scripts now and then. I tried to run some diy powershell scripts from task scheduler and noted that you can simply call powershell with the -executionpolicy parameter to override this "universal" setting. Kind of makes the whole setting a bit moot as a universal parameter? Or does it? I am still a bit puzzled, but as I don't know all the details this seemed to achieve what i wanted without touching the system-wide setting.


  2. Author
    Jeff Hicks 4 years ago

    The execution policy is not a security boundary. It is merely designed to avoid unintentionally running scripts. Yes, you can run PowerShell.exe and specify a different execution policy. Although I'm not sure if you can if you are using an execution policy set via GPO. If some one ( or some app) can run powershell.exe without your permission, then the lack of an execution policy is moot. And remember, this only applies to a script. You can still run a scriptblock interactively and the execution policy is irrelevant.


Leave a reply

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



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account