Quick Tip – Running Exchange Based PowerShell script files from the command line or a batch file…

I have been asked this quite a bit over the years, and indeed in most of my articles where I provide PS based scripts I tend to re-iterate the process for running or scheduling them. So rather than continue to cover the process over and over again, I thought that I would put together a full post on how you can run scripts within your respective environments.

First things first, understanding Execution Policies

PowerShell was designed to be a more secure scripting platform over its main predecessors within a Windows environment (e.g. VBScript or JScript) – therefore a number of security features were built into it – the most prominent of which was the principles of “Execution Policies”.

In essence Execution Policies set a number of conditions in which scripts and configuration files can be executed from within or using the Shell. Execution Policies can be set at the following levels:

  • Local Machine
  • Currently Logged on User
  • Specific PowerShell session

Group Policy can also be used to determine settings at a user and computer level.

There are a number of levels which Execution Policies can be set at – these are shown below (which is based upon the following information Source: http://technet.microsoft.com/en-us/library/dd347641.aspx):

Level Description Security Rating
This is the Default execution policy.
Permits individual commands, but will not run scripts.
Prevents running of all script files, including formatting and configuration files (.ps1xml), module script files (.psm1), and Windows PowerShell profiles (.ps1).
Scripts can run.
Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.
Prompts you before running scripts from publishers that you have not yet classified as trusted or untrusted.
Risks running signed, but malicious, scripts.
Moderate Risk
RemoteSigned Scripts can run.
Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the Internet (including e-mail and instant messaging programs).
Does not require digital signatures on scripts that you have run and that you have written on the local computer (not downloaded from the Internet).
Risks running unsigned scripts from sources other than the Internet and signed, but malicious, scripts.
Moderate Risk
Unrestricted Unsigned scripts can run. (This risks running malicious scripts.)
Warns the user before running scripts and configuration files that are downloaded from the Internet.
High Risk
Bypass Nothing is blocked and there are no warnings or prompts.
This execution policy is designed for configurations in which a Windows PowerShell script is built in to a larger application or for configurations in which Windows PowerShell is the foundation for a program that has its own security model.
High Risk
Undefined There is no execution policy set in the current scope.
If the execution policy in all scopes is Undefined, the effective execution policy is Restricted, which is the default execution policy.


On my servers I tend to run either “AllSigned” or “RemoteSigned” as those levels are sufficient to give me a good trade off between security and functionality.
You can check your PowerShell Script Execution Policy setting by opening a PowerShell Session on your machine and typing in the following command:

Get-ExecutionPolicy –List | FL

Which will produce some output similar to the following:


Given the above, if you are intending to run scripts that you have downloaded to your Local Machine you will need an Execution Policy of either “AllSigned” or “RemoteSigned” in order to run them.

For example – if you want to change the Execution Policy to “RemoteSigned” (my preferred personal level) – open a PowerShell session (you will need to run PowerShell as an Administrator) – and type the following command:

Set-ExecutionPolicy “RemoteSigned”


You should also note that if you are using “RemoteSigned” as the Execution Policy and you have downloaded a script from the Internet you will be presented with the following error upon script Execution:


You will need to “Unblock” the script in order for it to function (this is because an attempt is made to find a Trusted Publisher for the script on the web and cannot do so, as the script may not be signed) – this is done by selecting the script file using a right click and from the context menu that appears – choose properties, and then from the properties dialog click on the “Unblock” button – see below:


For more information on Set-ExecutionPolicy see the following TechNet article: http://technet.microsoft.com/en-us/library/dd347628.aspx

Executing Exchange PowerShell Script Files from the Command Line

You have a couple of options here:

  1. Executing a script from within an open PowerShell session
  2. Executing a script from a CMD command window

If you wish to run an Exchange PowerShell script from within an existing PowerShell session the easiest way is to do so via the Exchange Management Shell.

Open the Exchange Management Shell and then type in the path to your Exchange based PS script:


If you would like to run a script from the Windows command prompt you can:

Powershell.exe –command “& {<path to script> }”


It is important to note that if you are running Exchange based scripts from the Windows Command prompt by passing them as a parameter to Powershell.exe you should add the following line at the top of each script:

For Exchange 2010:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

For Exchange 2007:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

This will load the relevant Exchange Management Shell commands for your script from the vanilla PowerShell session.

Executing Exchange Scripts from a Batch File

You can execute your scripts by adding the the Powershell.exe command (see above) into a Windows Batch file. The batch File can then be scheduled to run as part of a scheduled task – or configured within Group Policy to execute as a start up script.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.