Understanding the new execution policy

Windows PowerShell implements script security to keep unwanted scripts from running in your environment. You have the option of signing your scripts with a digital signature to ensure that scripts that run are from a trusted source.

The policy has five (Unrestricted, RemoteSigned, AllSigned, Restricted, Default, Bypass, and Undefined) different states to be set in five different scopes (MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine).

A short description of the different states and what they can or can't do follows:

• Undefined - There is no execution policy set for the current scope
• Restricted - No script, be it local, remote, or downloaded can be executed
• AllSigned - All script that is run required to be digitally signed
• RemoteSigned - All remote (UNC) or downloaded scripts required to be digitally signed
• Bypass - Nothing is blocked and there are no warnings or prompts
• Unrestricted - All scripts are allowed to be executed

And the following is a description of the different scopes:

• MachinePolicy - The execution policy set by a Group Policy applies to all users
• UserPolicy - The execution policy set by a Group Policy applies to the current user
• Process - The execution policy applies to the current Windows PowerShell process
• CurrentUser - The execution policy applies to the current user
• LocalMachine - The execution policy applies to all users of the computer

Windows PowerShell implements script security to keep unwanted scripts from running in your environment. You have the option of signing your scripts with a digital signature to ensure that scripts that are run are from a trusted source.

It is possible to manage Exchange 2016 through PowerShell remoting on a workstation or server without Exchange Tools installed. In this case, you'll need to make sure your script execution policy is set to either RemoteSigned or Unrestricted. To set the execution policy, use the following command:

Set-ExecutionPolicy RemoteSigned

Make sure you do not change the execution policy to AllSigned on machines where you'll be using the Exchange cmdlets. This will interfere with importing the commands through a remote PowerShell connection, which is required for the Exchange Management Shell cmdlets to run properly.

How to do it...

The following are some examples of cmdlets that can be used for configuring the execution policy:

Get-ExecutionPolicy -List | Format-Table -AutoSizeSet-ExecutionPolicy AllSignedSet-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy ` RemoteSigned

How it works...

The default scope is set to LocalMachine if nothing is specified, which means it will apply to everyone on this machine. If the execution policy is set to Undefined in all scopes, the effective execution policy is Restricted.

We started with listing the current policy settings and then continued with configuring the LocalMachine policy to require scripts to be digitally signed or else they will be prohibited from being executed.

The last cmdlet which was used configured the CurrentUser to RemoteSigned instead of AllSigned, which was configured to the LocalMachine policy.

Once this change is done, the configuration would look like the following screenshot:

This makes it possible to have the execution policy configured to require digital signatures for scripts that are being executed by everyone, except the current logged in user.

If you are uncertain as to which user that is logged on, use the whoami command.

There's more...

Since the default execution policy is configured to RemoteSigned, the effect is that all remote (UNC) or downloaded scripts required to be digitally signed.

It is very common that when a script is downloaded, we need to unblock this file before it can be executed when the policy is set to default settings.

Of course, the recommendation before unblocking any downloaded file is to test it in a test environment so it doesn't harm any production environment or it doesn't contain any malicious code in some way:

Unblock-File -Path C:\Scripts\HarmlessScript.ps1Get-ChildItem C:\DownloadFolder | Unblock-File

The first line unblocks the specified downloaded file, while the second line retrieves all files from a folder called DownloadFolder and then unblocks them. This, in the end, makes it possible to execute these files with the default configuration.

Unblock-File performs the same operation as the Unblock button on the Properties dialog box in File Explorer.

For more detailed information, use the Get-Help about_Execution_Policies cmdlet.

See also

• The Working with the desired state configuration recipe in this chapter
• The Working with script repositories recipe in this chapter
• The Using the Save-Help function recipe in this chapter