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

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 -AutoSize
    
    Set-ExecutionPolicy AllSigned
    
    Set-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.ps1
    
    Get-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.