igor - Fotolia
Set PowerShell execution policy based on your needs
Scripts to automate workflows and other procedures can be a boon to the IT staff, but there may be situations where it makes sense to adjust the PowerShell execution policy.
When someone new to PowerShell begins to tinker around with cmdlets, everything works fine. Commands run; output appears. However, once they take those skills to the next level and attempt to execute a script, the easy PowerShell path runs up against a wall of red text.
If you've seen the error message in Figure 1, you've been hit by the PowerShell execution policy. On Windows 8.1, Server 2012 and all versions below, the execution policy is set to Restricted -- no scripts can be executed on that computer. Later versions of Windows have a relaxed execution policy but, by default, still do not allow unfettered script execution.
The PowerShell execution policy provides a security gate. It restricts certain scripts from running on your computer. Execution policies only limit script execution and not command execution. An admin can run any command on a machine that has a restricted execution policy. While the PowerShell execution policy has a job to do, not every user on every machine needs to stay behind a solid security gate.
Five ways to say restrict usage
The PowerShell execution policy comes in five flavors, indicating the amount of restrictions that it places on the user: Restricted, AllSigned, RemoteSigned, Unrestricted and Bypass.
The Restricted execution policy prevents all scripts from running. Reset the execution policy to AllSigned to allow scripts to run only if they are individually cryptographically signed with a certificate. Restricted and AllSigned are both all-or-nothing states.
Take things down a notch, and change the policy to RemoteSigned. A RemoteSigned PowerShell execution policy forces all scripts downloaded from the internet to be signed by a certificate.
The Unrestricted policy simply turns off PowerShell execution limits, asking for permission whenever it runs a script downloaded from the internet. Bypass arguably is not an execution policy at all, blocking nothing.
Build appropriate barriers
Determine the current execution policy or policies with Get-ExecutionPolicy.
Run the command without parameters to see the execution policy for the current session. Or use the Scope parameter to determine if a different execution policy is set at a different scope (see Figure 2).
Set PowerShell execution policy
An administrator can set the PowerShell execution policy for a local session or any other scope on the machine via the command Set-ExecutionPolicy. Define the execution policy in question using the ExecutionPolicy parameter and expect a prompt that warns that a change in the execution policy might expose the system to unforeseen risks.
Run Set-ExecutionPolicy with no other parameters to set the LocalMachine scope. To change scope beyond the local machine, use the Scope parameter.
While Get-ExecutionPolicy and Set-ExecutionPolicy commands easily modify controls for a local machine, the process doesn't scale to modify the execution policy on hundreds of devices at once. If these machines are part of an Active Directory domain, the administrator can set an execution policy level via a group policy object (GPO). In the Group Policy Management Console, an administrator can create a new GPO, go to Computer Configuration, and browse to Administrative Templates\Windows Components\Windows PowerShell. To set execution policy here via GPO, use the Turn on Script Execution item (Figure 3).
Most administrators set PowerShell execution policies at RemoteSigned: a happy medium between security and convenience. This ensures that local scripts run, while all scripts created from remote sources can run if signed.
Join the conversation
2 comments