Book Image

Microsoft Exchange Server PowerShell Cookbook

Book Image

Microsoft Exchange Server PowerShell Cookbook

Overview of this book

Table of Contents (21 chapters)
Microsoft Exchange Server PowerShell Cookbook Third Edition
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

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 (Undefined, Restricted, AllSigned, RemoteSigned, and Unrestricted) different states to be set in five different scopes (MachinePolicy, UserPolicy, Process, CurrentUser, and LocalMachine).

Here is a short description of the different policies and what they can or can't do:

  • Undefined: There is no execution policy set for the current scope

  • Restricted: No script either local, remote, or downloaded can be executed

  • AllSigned: All scripts that are run require to be digitally signed

  • RemoteSigned: All remote (UNC) or downloaded scripts require to be digitally signed

  • Unrestricted: All scripts are allowed to be executed

Here is a description of the different scopes:

  • MachinePolicy: This execution policy set by a group policy applies to all users

  • UserPolicy: This execution policy set by a group policy applies to the current user

  • Process: This execution policy applies to the current Windows PowerShell process

  • CurrentUser: This execution policy applies to the current user

  • LocalMachine: This execution policy applies to all users of the computer

It is possible to manage Exchange 2013 through PowerShell remoting on a workstation or server without the Exchange Tools installed. In this case, you'll need to make sure that 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 that 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 to configure 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 that 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 that requires scripts to be digitally signed. Otherwise, they will be prohibited from being executed.

The last cmdlet was used to configure 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 configure the execution policy to provide digital signatures for scripts that are executed by everyone, except the currently logged-in user.

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

There's more…

Since the default execution policy is configured to RemoteSigned, all remote (UNC) or downloaded scripts require 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, it's recommended that before you unblock any downloaded file, you need to test it in a test environment so that it doesn't harm any production environment or add 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 makes it possible to execute these files with the default configuration.

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

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

See also

  • Working with Desired State Configuration

  • Working with script repositories

  • Using the Save-Help function