PowerShell ExecutionPolicy

PowerShell ExecutionPolicy

Windows PowerShell ExecutionPolicy let you determine the conditions under which Windows PowerShell loads configuration files and runs scripts.

You can set an execution policy for the local computer, for the current user, or for a particular session. You can also use a Group Policy setting to set execution policy for computers and users.

Execution policies for the local computer and current user are stored in the registry. You do not need to set execution policies in your Windows PowerShell profile. The execution policy for a particular session is stored only in memory and is lost when the session is closed.

The execution policy is not a security system that restricts user actions. For example, users can easily circumvent a policy by typing the script contents at the command line when they cannot run a script. Instead, the execution policy helps users to set basic rules and prevents them from violating them unintentionally.

Check Current ExecutionPolicy

To check the current ExecutionPolicy on system, use Get-ExecutionPolicy cmdlet as shown below:

PS C:\Users\Surender\Documents> Get-ExecutionPolicy

This is default execution policy in Windows 8, Windows Server 2012 and Windows 8.1.

Modify ExecutionPolicy

To change the Windows PowerShell execution policy on your computer, use the Set-ExecutionPolicy cmdlet. To run this cmdlet, you must have administrator privileges on computer. The syntax of command is as shown below:

Set-ExecutionPolicy <ExecutionPolicy> [-Scope] [-Force]


<ExecutionPolicy> specifies the new execution policy. Valid values are:

  • Restricted: Does not load configuration files or run scripts. “Restricted” is the default execution policy. Prevents running of all script files, including formatting and configuration files (.ps1xml), module script files (.psm1), and Windows PowerShell profiles (.ps1).
  • AllSigned: Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.
  • RemoteSigned: Requires that all scripts and configuration files downloaded from the Internet be signed by a trusted publisher.
  • Unrestricted: Loads all configuration files and runs all scripts. If you run an unsigned script that was downloaded from the Internet, you are prompted for permission before it runs.
  • Bypass: Nothing is blocked and there are no warnings or prompts.
  • Undefined: Removes the currently assigned execution policy from the current scope. This parameter will not remove an execution policy that is set in a Group Policy scope.

-Scope specifies the scope of the execution policy. This is an optional parameter, if omitted the ExecutionPolicy is set by default for local machine. However, you can use other valid values for scope parameter. The valid values are:

  • Process: The execution policy affects only the current Windows PowerShell process or session.
  • CurrentUser: The execution policy affects only the current user.
  • LocalMachine: The execution policy affects all users of the computer.

-Force is also an optional parameter which suppresses all prompts or Warnings. By default, Set-ExecutionPolicy displays a warning whenever you change the execution policy.

However there are other optional parameters which can be used with Set-ExecutionPolicy cmdlet, but they are not usually used. You can see complete list of parameters and description using Get-Help command.

PS C:\Users\Surender\Documents> Get-Gelp Set-ExecutionPolicy -Detailed


    Set-ExecutionPolicy [-ExecutionPolicy] <ExecutionPolicy> {Unrestricted | RemoteSigned | AllSigned | Restricted |
    Default | Bypass | Undefined} [[-Scope] <ExecutionPolicyScope> {Process | CurrentUser | LocalMachine | UserPolicy
    | MachinePolicy}] [-Force] [-WhatIf] [-Confirm]  [<CommonParameters>]


    -ExecutionPolicy <ExecutionPolicy>


    -Scope <ExecutionPolicyScope>


        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (http://go.microsoft.com/fwlink/?LinkID=113216).


    Get-Help cannot find the Help files for this cmdlet on this computer. It is displaying only partial help.
        -- To download and install Help files for the module that includes this cmdlet, use Update-Help.
        -- To view the Help topic for this cmdlet online, type: "Get-Help Set-ExecutionPolicy -Online" or
           go to http://go.microsoft.com/fwlink/?LinkID=113394.

The change done using Set-ExecutionPolicy cmdlet is effective immediately; you do not need to restart Windows PowerShell.

If you set the execution policy for the local computer (the default) or the current user, the change is saved in the registry and remains effective until you change it again. If you set the execution policy for the current process, it is not saved in the registry. It is retained until the current process and any child processes are closed.

Set the ExecutionPolicy via Group Policy

If you often need to change the execution policy on computers in your Active Directory domain to allow unsigned scripts, you may want to apply this setting centrally via a Group Policy Object (GPO). The Set-ExecutionPolicy command will allow you to pass the policy values for PowerShell’s operation level. For scripts you write yourself, in most situations, administrators choose the Unrestricted policy.

The Group Policy configuration in Windows Server 2008 and Windows Server 2012 R2 allows a GPO to be set to configure the PowerShell operation level centrally. Within Group Policy, navigate to Computer Configuration | Administrative Templates | Windows Components | Windows PowerShell and configure the Turn On Script Execution setting as shown in Figure below:

Set ExecutionPolicy via GPO

Set ExecutionPolicy via GPO

The Disabled option will prevent PowerShell scripts from being run and enforced via a GPO.  If the GPO value is set, the computer accounts do not have the ability to change their local execution policy. The below Figure shows this behavior, even run as a Domain Administrator.

Set-ExecutionPolicy Command Run Locally Failed due to GPO Setting

Set-ExecutionPolicy Command Run Locally Failed due to GPO Setting

There are a number of considerations for this type of configuration around script security. The best practice will depend on the security policy of the systems involved. Applying the setting that enables PowerShell scripts to a GPO that corresponds to relevant systems is a practice that would fit most situations.


Leave a Comment