Power(Shell)full Stuff

Windows PowerShell was introduced a few years back, but is still trying to find its way in the big, bright world of Windows even today.  This command-line interface allows users of all versions of Windows from XP SP2 on up to navigate through day-to-day operations without walking through layers of GUI interaction to get there.  While somewhat slow to take off in the mainstream Windows admin world, for Exchange Server (2007 and up) it has become an essential part of the Exchange Engineer’s toolkit.

With Exchange 2007, Microsoft removed a great deal of the control functionality from the Exchange Management Console (EMC) in favor of the extensions that Exchange makes to PowerShell, creating the Exchange Management Shell (EMS).  At first blush, this seems to be taking one giant leap backwards in terms of command and control on a Windows Server (DOS, anyone?) but once you dive a little deeper, there are a lot of advantages to be found.

Let’s start with speed.  EMC is slow, very slow.  Waiting for each command to finish loading up in the GUI just to figure out the piece of information you need is painful, to say the least.  The main reason for this is that the EMC doesn’t really do anything itself, it just displays the output of various PowerShell commands in a graphical format.  So each time you ask the EMC to do anything at all, what you’re really doing is waiting for it to create the corresponding PowerShell commands, evoke and run them, and then take the results and spit them back out on the screen for you.  For more complex tasks that are going to take some time anyway (like multi-mailbox move operations), this isn’t such a bad thing to deal with.  The GUI components make that job easier, and don’t add a huge amount of time to the overall process.  But for other operations, like getting a listing of all Storage Groups assigned to a particular server, the overhead in delays for getting the info and formatting it into the MMC3 GUI interface can mean the processes takes several times longer to perform in the EMC than it would at the command line.

Secondly, some techniques could never be performed inside of a GUI in any version of Exchange.  Database consistency checking and error correction were always done from the command line, and therefore it was logical to build those routines into PowerShell and the EMS as the newer versions of Exchange evolved.  By leveraging the way cmdlets (PowerShell code snippets) worked, much more complex database control and corrective action sequences could be piped through a single set of commands.  This lets administrators do more with fewer keystrokes, and opens up a whole new world to 3rd-Party software platforms who found that batch files just couldn’t cut it for what they needed to do.

Finally, the same way that cmdlets can expand what can be done within the framework of a script for things that were always command-line based; they can also allow administrators to automated a lot of their day-to-day work as well.  Prior to Exchange 2007, setting up users and mailboxes was a rather straight-forward process, but required that you interact with a series of GUI’s to get it done.  This took up extra time, and also introduced another level of potential errors every time you opened up another GUI.  Granted, this did not tend to lead to a lot of issues for experienced administrators, but even the most seasoned pro is going to slip up if they have to click in the same spot, over and over, several dozen times a week.  PowerShell allows for the creation of complex scripts that can leverage cmdlets, VB and C# commands and other attributes bound into single executable files.  This means that a set of operations can be crafted, tested and saved, then run over and over as required.  Less moving parts means less chance for errors, and portability means that a more experienced administrator can craft scripts for folks who may need to run repetitive tasks but not have the skills to work with cmdlets yet.  Entire online communities have sprung up to facilitate cooperative efforts on PowerShell scripts and to share what worked and what didn’t for various Exchange-related tasks.

Speed, efficiency and community interaction are just three components of what PowerShell can do to assist the average Exchange Engineer or Administrator.  Since the trend toward leveraging PowerShell and the EMS continues into Exchange 2010 (scheduled for release later this year), getting on-board with PowerShell tools now will build a knowledge-base that will grow with you as you continue to leverage new and better Exchange platforms.