Partilhar via


OUTBOX: Introduction to Exchange Powershell Automation Part 1

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

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

Windows Powershell Getting Started Guide

https://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

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

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

Exchange 2007 Cmdlet List

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

Exchange Management Shell Quick Reference

https://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

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

Powershell Managed Reference

https://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

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

https://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

https://blogs.msdn.com/powershell/

Exchange 2007 Powershell Scriptacular Demo Pack

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

ExchangeNinjas: Powershell Scripts

https://www.exchangeninjas.com/PSSCategories

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

Comments

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

  • Anonymous
    July 30, 2007
    Mentre stavo per realizzare l'ennesima applicazione web che interagiva con Exchange attraverso la libreria

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