OUTBOX: Introduction to Exchange Powershell Automation Part 1

  • Comments 3

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

 

http://msdn2.microsoft.com/en-us/library/ms714658.aspx

 

Windows Powershell Getting Started Guide

 

http://msdn2.microsoft.com/en-us/library/aa973757.aspx

 

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

 

http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/925ad66f-2f05-4269-9923-c353d9c19312.mspx?mfr=true

http://technet.microsoft.com/en-us/library/bb123778.aspx

Exchange 2007 Cmdlet List

 

http://technet.microsoft.com/en-us/library/bb123703.aspx

 

Exchange Management Shell Quick Reference

 

http://www.microsoft.com/downloads/details.aspx?FamilyId=01A441B9-4099-4C0F-B8E0-0831D4A2CA86&displaylang=en

 

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

 

http://msdn2.microsoft.com/en-us/library/ms714469.aspx

 

Powershell Managed Reference

 

http://msdn2.microsoft.com/en-us/library/aa717491.aspx

 

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

 

http://www.viveksharma.com/techlog/2006/07/27/sample-code-calling-exchange-cmdlets-from-net-code

http://www.viveksharma.com/TECHLOG/archive/2006/07/27/sample-code-calling-exchange-cmdlets-from-net-code.aspx

 

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.

 

Other References

 

Windows Powershell Team Blog

 

http://blogs.msdn.com/powershell/

 

Exchange 2007 Powershell Scriptacular Demo Pack

 

http://www.viveksharma.com/techlog/2006/12/21/announcing-the-exchange-2007-powershell-scriptacular-demo-pack/

 

ExchangeNinjas: Powershell Scripts

 

http://www.exchangeninjas.com/PSSCategories

 

Updated 1/22/2009 – Fixed a broken link.

  • Trying to call Powershell from .net ? Following are few good articles to read, from my colleague Matt

  • Mentre stavo per realizzare l'ennesima applicazione web che interagiva con Exchange attraverso la libreria

  • I've put together a list of articles which cover common questions on PowerShell automation. These links

Page 1 of 1 (3 items)