Using the Shell to Manage Exchange 2007 - 05 Jun 2007

As you probably know by now, Exchange Server 2007 has a new management system based on Windows PowerShell. In "Windows PowerShell Transforms Exchange Server 2007 Management," April, 2007, I wrote about the basics of managing Exchange 2007 by using the Exchange Management Console and PowerShell cmdlets through Exchange Management Shell. Although Microsoft intends to add more management options to the GUI with Exchange 2007 SP1, currently many things can be accomplished only through shell commands. Let's take a look at what you can accomplish in your Exchange environment by using the shell.

The Console vs. the Shell
Microsoft built Exchange Management Console on top of the same code used by the set of commands available through Windows PowerShell, which means that anything you can accomplish through the console can also be done with a shell command. Anytime you do something through an Exchange Management Console wizard, you’ll be shown the shell commands that are generated to actually perform the operation. You can copy the commands for reuse, and they'll perhaps give you a flying start at writing a script. For example, if you create a new mailbox through the console, the code generated might look like that in Listing 1.

Only the most commonly used management options are incorporated in the Exchange Management Console GUI; anything deemed to be a one-off command or something that's done infrequently is left to the shell. Consequently, some options that appeared in Exchange System Manager (ESM) in previous versions of Exchange aren't available from Exchange Management Console. For example, you can’t set diagnostics through the console; you must use the Set-EventLogLevel cmdlet, as in

Set-EventLogLevel -id 'MSExchangeTransportCategorizer' -Level High 

You also can't manage public folders from the console: You either have to keep an Exchange Server 2003 server around so you can manage public folders through ESM or use the shell commands available. Microsoft plans to add options for managing public folders to the GUI in Exchange 2007 SP1.

Almost all message-routing management is now done in the shell, too. Of course, Microsoft has dramatically simplified routing in Exchange 2007 by eliminating the routing group construct used in Exchange 2003 and Exchange 2000 Server and the notion of link state routing updates. Instead, Exchange 2007 depends on point-to-point SMTP connections to route messages whenever possible. If Exchange needs to know about topology in order to route to a connector or if a destination server is unavailable, Exchange uses the Active Directory (AD) site topology and site links to determine the most effective route.

Manipulating Mailboxes
Management programs for previous versions of Exchange let administrators examine the set of mailboxes on a server and the size in megabytes of each mailbox. In Exchange 2007, you can use Exchange Management Console to list the mailboxes on a server (you need to apply an easy-to-create filter to do so), but you can't see what percentage of its quota a mailbox is using, the number of items it contains, or the number of deleted items.

The elimination of these options from the Exchange 2007 GUI illustrates a philosophical difference between ESM and Exchange Management Console. ESM always restricts the view of mailboxes to a particular database, so performance is predictable. However, Exchange Management Console views all mailboxes in the organization unless you set a different scope, such as all mailboxes on a specific server. Because information such as the number of items in a mailbox and the number of deleted items must be extracted from the mailbox store, retrieving that data for inclusion in the console would require opening multiple databases, which is a recipe for less-than-sparkling performance.

You can click a mailbox in Exchange Management Console to view its Properties dialog box, which includes the number of items in the mailbox and the size of the mailbox. However, if you want to retrieve statistics for more than a single mailbox, you must use the Get-MailboxStatistics cmdlet. Figure 1 shows sample output from this command. The output definitely isn't as pretty as that from a well-designed GUI, but think of it as raw data waiting to be manipulated.

There are many variations you can use with Get-MailboxStatistics, such as looking at mailboxes on a server or in just a single database, but let’s demonstrate the true power of PowerShell by incorporating several commands into a script to extract data about mailboxes from a filtered set of Exchange servers, then format the output. Listing 2 shows the script.

Confused? Well, the commands in Listing 2 do the following:

Figure 2 shows output generated by our script. If you want to see the full set of properties you can select with Get-MailboxStatistics, try this command:

Get-MailboxStatistics | Format-List 

Generating a text file perhaps isn't too interesting, but you can also output data in HTML or comma-separated value (CSV) format, which are somewhat more pleasing. If you want graphic output, you can use third-party add-ons to PowerShell. Figure 3 shows output I created with the graphics gallery available with PowerGadgets. In this case, I piped the output from Get-MailboxStatistics into one of PowerGadget's PowerShell cmdlets to create the graph. PowerGadgets is an example of the great extensibility that PowerShell offers. I imagine there will be many more third parties writing specialized tools to extend the capabilities of PowerShell.

A New Era for Exchange Administrators
These examples only scratch the surface of what’s possible with PowerShell. The management system for Exchange 2007 marks a new era for email administration, giving us a scripting language for Exchange that's extremely powerful and flexible. Sure, it will take you time to master PowerShell, but take it from me—after you come to appreciate its potential, your first inclination will be to go for the shell instead of the GUI any time you need to manage your Exchange organization.