Set PowerShell Execution Policy with Group Policy

• Author
• Recent Posts

Jeffery Hicks

Jeff Hicks is a long-time Microsoft MVP specializing in PowerShell and automation. He creates PowerShell content for Pluralsight and blogs regularly at https://jdhitsolutions.com/blog. Jeff's latest project is a premium content newsletter at jeffhicks.substack.com Follow him on Twitter as @jeffhicks.

Latest posts by Jeffery Hicks (see all)

• Use PowerShell splatting and PSBoundParameters to pass parameters - Wed, Nov 9 2022
• Using PowerShell with $PSStyle - Mon, Jan 24 2022
• Clean up user profiles with PowerShell - Mon, Jun 9 2014

In a previous article I explained about PowerShell’s execution policy and demonstrated how to set it from an elevated PowerShell session.

PS C:\> Set-ExecutionPolicy RemoteSigned -Force

The default policy is Restricted so if you only need to configure a policy on a handful of machines you could run the command interactively. You could even use a remoting command.

PS C:\> Invoke-Command {Set-ExecutionPolicy RemoteSigned –Force} –computername $computers

But the smarter way is to use a Group Policy object. The primary benefit is that policies applied by a GPO can’t be overwritten, even by an administrator. To configure such a policy open the Group Policy Management Editor and edit or create a new GPO. Mine is called PowerShell Configuration.

Group Policy Management Editor

To configure, navigate under Computer Configuration to Policies\Administrative Templates\Windows Components\Windows PowerShell. You should see a setting called Turn on Script Execution like in figure 2.

Turn on Script Execution

Double-click the setting. You will want to enable it and select an option from the drop down.

Enable PowerShell execution policy

The policy descriptions correspond to AllSigned, RemoteSigned and Unrestricted. I’m going to pick the policy to allow local and remote signed scripts. Click OK to set it. The dialog suggest you need at least Windows 7 but I am pretty sure that even with PowerShell 2 running on older systems you can use this policy. I unfortunately no longer have any such legacy systems to verify that. But this setting will apply to PowerShell 2.0 and later.

I can verify my setting in the Group Policy Editor.

Group Policy Editor

Of course the benefit is that you can apply different settings to different organizational units so servers, user desktops and admin desktops can all have different settings that will be enforced. Remember, this policy is per machine so it will apply to your administrator desktops as well.

Now, when the policy is in place, users (and administrators) can’t override your script execution policy.

PowerShell execution policy overridden

In theory, this should also protect you from any future PowerShell-centric malware that might try alter your script execution policy.

As I mentioned before, this doesn’t prevent someone from copying and pasting the contents of a script into a PowerShell session, but at least they can’t simply run the script.

This policy also doesn’t have any effect on cmdlets, like Invoke-Command, that have a parameter to specify a script path. The machine running Invoke-Command should have a policy to allow script execution. But any remote machines can have restricted execution policies. When you specify a script from your machine, the script itself doesn’t run remotely, only the contents. Think of this as the equivalent of copying and pasting the script commands into a PowerShell session. The end result is that servers can be locked down yet you can still take advantage of PowerShell scripts.

One thing to be aware of is that if you are using a Group Policy to define a PowerShell logon, logoff or computer script, that script will disregard any execution policy set locally or through a GPO. These scripts execute with a Bypass execution policy. The assumption is that you have created the script, know what it does and have taken precautions to secure it.

I encourage you to test these Group Policy settings in a non-production environment so that you can fully understand the implications and how it might affect your PowerShell management practices.