About: Exchange PowerShell Automation

Article
05/18/2015

API Type: Exchange Administration

API Interface: .NET Framework Class Libraries

Business Logic: Managing mailboxes, storage groups, and databases.

Language Support: Any .NET language.

Direct Property Access: N/A

Product Versions: Exchange 2007 and later.

Summary:

Exchange PowerShell was introduced with Exchange 2007 as a replacement of CDOEXM and WMI which were used for Exchange administration. Exchange 2007 did not ship CDOEXM and WMI, which were used by Exchange 2000 and 2003 for administrative tasks. Exchange administrators use these cmdlets manually but they can also be automated by developers using .NET. Automation for Exchange 2007 PowerShell cmdlets required that local PowerShell be used - ie PowerShell 1.0. Exchange 2010 and later require remote PowerShell calls using PowerShell 2.0+.

Exchange PowerShell cmdlets are not meant to work on the content of a mailbox outside of administrative tasks. As an example it cannot be used to read a persons email or calendar content directly. However, the Exchange Managed API (which uses EWS) can be used to access the content of a mailbox and public folders. This can be done by scripting the EWS Managed API or using PowerShell Automation to do both Exchange cmdlet calls and EWS calls. By combining both of these APIs an administrator has some incredible capabilities.

Points of Interest:

Exchange 2007:

The Exchange Powershell cmdlets are new to Exchange 2007 and automation of these cmdlets replaces CDOEX and WMI.
The Exchange Admin-Only Role must be installed on the application server in order to use Exchange cmdlets - they cannot be invoked remotely.
The 64-bit install of Exchange only installs the 64-bit version of Exchange cmdlets - these cmdlets cannot be used from a 32-bit process.
If an application server has both Exchange 2000/2003 and Exchange 2007 components on it for an application that manages both server versions it must use CDOEXM and PowerShell automation in different processes.

Exchange 2010 and later:

Exchange 2010 and later PowerShell Automation needs to be done with Remote PowerShell 2.0+. Local PowerShell calls are not viable and neither is PowerShell 1.0.

Important:

Exchange PowerShell automation requires the correct mixture of PowerShell version and call type (Local vs. Remote). Using the incorrect type is not supported. Exchange 2007 PowerShell Automation needs to be done with Local PowerShell 1.0.
Exchange 2010 and later PowerShell Automation needs to be done with Remote PowerShell 2.0+.
Exchange PowerShell cmdlets need to run with Exchange Administrative permissions.
PowerShell itself needs to run with local machine Administrative permissions.

Basic Troubleshooting:

If a remote Exchange PowerShell call fails then be sure to try the following:

1) Always try the same command in the command shell. If it does not work in the command shell then its not going to work with .NET automation.

2) Check to see if a call to non-Exchange cmdlet works. This is important since Exchange cmdlets require Exchange Administrative permissions.

3) Be sure your code is running with the proper permissions and that account used has Exchange Administrative permission.

4) Be sure that the correct version of PowerShell and call type (Local versus Remote) is being used.

Exchange PowerShell - minus automation:

Exchange 2007 PowerShell (PowerShell 1.0):

Windows PowerShell Scripting
https://technet.microsoft.com/en-us/scriptcenter/powershell.aspx

Exchange 2010 and later PowerShell (PowerShell 2.0+):

Using Windows PowerShell
https://technet.microsoft.com/library/dn425048.aspx

Exchange Management Shell
https://msdn.microsoft.com/en-us/library/office/ff326155(v=exchg.150).aspx