I’m glad to see that many of you are picking up Exchange 2007 and starting to write applications against it! Many of the early cases I have been working on regarding Exchange 2007 are related to automating Powershell. To me this makes sense that it would be an early call generator for two reasons: 1) it is vastly different from any other “API” interaction we have had in the past and 2) Powershell is a replacement for CDOEXM and WMI which were removed completely from Exchange 2007’s API set.
There are four main “development” tasks related to Powershell including: creating cmdlets, creating snap-ins, creating Powershell providers, and automating existing cmdlets in providers. My first two introductory posts focus solely on automating the Exchange cmdlets provided by the Exchange Management Shell snap-in.
This first post will serve as a primer to get you thinking about Powershell and understanding the concepts involved in automation. The second post will provide some sample code and more specific discussion of issues related to Powershell automation with Exchange 2007…
Get to know Powershell in general
In order to understand what considerations to take in your application that will automate Powershell, you must have a reference for the architecture and operations behind it. Here is a great place to start…
How Windows PowerShell Works
Windows Powershell Getting Started Guide
Use cmdlets in Exchange Management Shell first
The first steps in automating Powershell are to understand what cmdlet it is you want to automate, the parameters you need to pass it, and the output it is going to give you back. The easiest way to do this is to get all this working in the shell first and then work it into your automation code. Here are some helpful links to get you started using the Exchange Management Shell and the Exchange cmdlets available via the Exchange snap-in…
Using the Exchange Management Shell
Exchange 2007 Cmdlet List
Exchange Management Shell Quick Reference
Understand the automation objects
Now that you know what cmdlets you want to automate and what input and output you expect to work with, the next step is to understand the automation objects. The bulk of these objects are found in the System.Management.Automation namespace. Here are links to the SDK references for Powershell…
Windows Powershell SDK
Powershell Managed Reference
The best way to understand how to use these classes is to just see some code. Vivek Sharma is an Exchange PM focusing on Exchange Powershell; his blog is a great resource. He provides an example of using the System.Management.Automation namespace for invoking cmdlets from .NET code…
Sample Code: Calling Exchange cmdlets from .NET code
There are a couple important things to notice in his sample code…
First, this code was written in the Exchange 2007 Beta timeframe so Powershell was still being referred to as “Monad” so instead of PS (Powershell) objects you see references to MSH (Monad Scripting Host) objects. Most of the time you can just exchange PS for MSH in the object names, my examples will always references the RTM objects with PS in the object names so you won’t have to translate them.
Second, look to what his code has to do as compared to what you now know about Powershell. The System.Management namespace is generic and relates to Windows Powershell, there is nothing specific here to Exchange. Therefore, just like if you were using the shell, you have to load the Exchange snap-in to get access to the Exchange specific cmdlets.
On to Part 2…
This should be a good framework for understanding Powershell and how we will use it to automate the management of Exchange 2007. In Part 2 I will get into more specifics about common issues that we have identified so far and some more sample code.
Windows Powershell Team Blog
Exchange 2007 Powershell Scriptacular Demo Pack
ExchangeNinjas: Powershell Scripts
Updated 1/22/2009 – Fixed a broken link.