Exchange Management with EMS: Fundamental Concepts

Exchange Server 2007’s heavy reliance on a new scripting toolset through Exchange Management Shell (EMS) divided the Exchange world: Some people like the power and flexibility of writing scripts, and others prefer the ease of use of a GUI. The initial fear that Microsoft would require administrators to use EMS for everyday management tasks has faded some now that Exchange 2007 SP1 has shipped a new version of Exchange Management Console (EMC) with GUI options for tasks previously only accessible from EMS, such as public folder and POP/IMAP management.

Nonetheless, you should investigate EMS to discover the ways it can ease your Exchange management. EMS is an Exchange-oriented scripting shell based on Windows PowerShell. Exchange 2007 is the first Microsoft product to both support and require PowerShell, though others, including the System Center family, have since been announced. You can effectively use EMS and PowerShell for Exchange administration—even if you don’t have any scripting background. With a rudimentary understanding of how Exchange uses PowerShell and the fundamentals of how PowerShell works, you might find that using EMS for common tasks is easier than you think.

How Exchange Uses PowerShell
Exchange 2007 uses PowerShell for many things, some of which are clearly visible to the Exchange administrator, and others aren’t. For example, as their final step, most of the wizards that you launch from within EMC will show you the code they’ll execute after you click Finish. This feature lets you see how the choices you make in the wizard pages create the code to perform the wizard's task. And you can cut and paste the code into a text editor to begin the process of building your own scripts. EMS commands and EMC actions execute the same code, which is part of what makes EMS so useful: You can do everything through EMS that you can do from EMC, plus many additional things that EMC doesn’t support, such as setting per-user parameters for unified messaging.

Exchange 2007 executes several PowerShell scripts as part of its setup. These scripts perform a variety of actions, including setting registry parameters, copying files, and setting up the configuration files used by some Exchange components. You can look at these scripts, which are included on the installation DVD, to get an idea of what they do, although running them yourself (or, worse, modifying and running them) is likely to land you in big trouble because these scripts perform the necessary prerequisites for installing Exchange—change them at your own risk!

Exchange 2007 also comes with a set of scripts that you can (and, in some cases, must) run yourself. These scripts are installed in \Program Files\Microsoft\Exchange Server\Scripts. For example, you can choose to run the Install-AntiSpamAgents.ps1 script to enable a variety of useful filtering agents on your Hub Transport servers; see the Microsoft article “How to Enable Anti-Spam Functionality on a Hub Transport Server” for details about how this script works. Exchange 2007 comes with many other useful scripts, including one for synchronizing Edge Transport servers with Hub Transport servers, plus samples that show how to use various EMS commands.

Installing PowerShell and EMS
You need to understand the distinction between PowerShell itself and EMS: PowerShell is the scripting core; EMS is built on top of PowerShell. You can write PowerShell scripts to handle many Windows administration tasks, including manipulating files and registry keys, managing services, working with the event log, and parsing data in comma-separated value (CSV) or tab-delimited files. However, the basic PowerShell installation doesn’t include any Exchange-specific functionality. The EMS installation adds Exchange commands to the PowerShell base.

Before you can install EMS, you must first install PowerShell. Download the core PowerShell bits from Microsoft's Web site at http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx (unless you’re using Windows Server 2008, in which case you install PowerShell from the install DVD or the Server Manager). Note that there’s a Community Technology Preview (CTP) of PowerShell 2.0, but you can’t use it with Exchange 2007.

You’ll need to have .NET Framework 2.0 installed. You must also install the Exchange Management Tools package, which you do with the Exchange 2007 setup utility. Installing the management tools also installs EMS; there’s no supported way to install only EMS without the tools package on a computer.

How You Can Use EMS
After the necessary components are installed, you can use EMS to perform almost any Exchange-related task. PowerShell was designed to be used both from an interactive command line and as a scripting shell. You can easily build scripts incrementally by executing each individual command as you write it. If you start using PowerShell commands and EMS for regular tasks, you’ll quickly build the skills to create scripts. PowerShell further eases the learning curve because it's customized with aliases that emulate many standard DOS commands. For example, you can type “dir” to get a listing of files instead of using Get-ChildItem, the actual PowerShell command to get a list of files from a directory (or subkeys from a registry key, and lots of other things).

You can even use EMS and PowerShell scripts to take some actions against remote computers. For example, you can query the Windows Management Instrumentation (WMI) providers of remote systems to gather information about those systems, and you can use EMS to interrogate or change settings on multiple Exchange servers. You have the flexibility to create your scripts wherever is most convenient, then run them either from the target machine or against the target from a different machine.

Some EMS Vocabulary
You should know what things are called in PowerShell and EMS. For instance, the individual commands you can run are known as cmdlets (pronounced “commandlets”) or tasks. Unlike command-line environments, such as DOS, that output streams of text, PowerShell cmdlets produce output as a stream of objects. Objects have properties, or attributes, that you can manipulate. For example, each object has a name. Some objects have additional name attributes, such as the display name of a mailbox or the friendly name on a certificate. When you type the cmdlet

get-mailboxserver

EMS returns one object—including all its properties—for each Mailbox server, not just the name of each Mailbox server. EMS displays text, sure, but it’s important to remember that the text representations you see on screen don’t show all the properties of the objects that the command has made available.

The grammar that EMS and PowerShell use is consistent, so it’s fairly easy to determine the syntax for a command you need. Get to know the most common prefixes: Get, Set, Create, Enable, Disable, and Remove are the primary ones (though lesser-known prefixes, such as Test, come in handy, too). In general, you can’t go far wrong by thinking of the kind of object (or noun) you want to work with (e.g., “mailbox,” “distribution group membership”), dropping any spaces from the name, and prefixing the noun with the appropriate action (or verb) you want to perform, as you see in the Get-MailboxServer cmdlet above. If you guess wrong, you’ll get an error message instead of the results you hoped for, but there’s no other penalty for guessing.

The Basic EMS Pattern
You can make your scripting life with EMS easier and more pleasant if you learn one secret: EMS and PowerShell commands are constructed with a simple pattern of operations that you’ll see frequently repeated. Consider a simple example: If you want to change a setting on some of your mailboxes, you can first get all the mailboxes with the Get-Mailbox cmdlet, select only the ones you want to modify, then use the Set-Mailbox cmdlet to make the desired changes. You'll see this pattern has three steps: . . .