Introduction

Thanks for buying the Exchange Server 2010 Portable Command Guide. This book joins the other books in the Portable Command Guide series. Before you delve into this book and start typing cmdlets, I would like to give credit to Scott Empson, who created the first book in the series, as well as Darril Gibson, who brought the series from its Cisco roots over to include the Microsoft product line.

Like the other books in this series, this book doesn’t attempt to teach every concept or explain every detail. It is assumed that you already understand the basic concepts.

Instead, the goal is to provide numerous examples of tasks that can be performed in Exchange Management Shell that allow you to view the syntax of cmdlets as well as to provide information to help you remember how to customize cmdlets for other purposes not directly addressed in this book. Hopefully, you will find the compact size of the Portable Command Guide to be convenient, so you are able to keep the book with you.

A number of books have been published on Windows PowerShell, but very few of these are dedicated to Exchange Server 2010. I am an Exchange administrator. I am not a developer. Yet, I have found an increasing need to improve my development skills in order to be an effective administrator—first with Exchange Server 2007, then with Windows Server 2008, and now with Exchange Server 2010. Fortunately, with Windows PowerShell and Exchange Management Shell, I can do so without having to learn a complicated language and extensive developmental concepts—something I really have no desire to do as an administrator. With just a simple verb-noun combination, I can achieve fantastic things in the Exchange organization and still be able to sleep at night without pieces of code swirling around in my head as I dream.

Many PowerShell books are written for developers by developers. I have long been searching for a book written for administrators by an administrator. So, I was quite excited when I was approached with the opportunity to write just such a book for Exchange Server 2010. This book is designed to be several things wrapped into one:

• First, it is designed to be a quick reference guide for all those little cmdlet “gems” you just know are out there, but can never seem to find when you need them. (For example, you need a quick-yet-customizable cmdlet to produce only the relevant information for certain mailboxes that exist in your organization.)

• Second, as you examine the five Exchange Server 2010 roles, this book provides a fairly complete list of the common cmdlets used to manage and work with those roles. I will attempt to analyze the syntax to make it more understandable for you and point out the common options available for those cmdlets.

• Third, if you plan to take one or both of the Exchange Server 2010 Microsoft certification exams (70-662 and 70-663), you will likely want a study guide with the relevant cmdlets you might expect to see on those exams, along with a brief description of the cmdlets and the possible options for their use.

If you’re like I was a few years ago, you might be asking yourself, “Why the command line again?”

This is a good question to ask. It’s very relevant, too, because quite a few Exchange 2003 administrators are now making the leap to Exchange Server 2010 and to Windows PowerShell.

There are several reasons to use a command-line utility. Let’s examine just one scenario to illustrate how the command-line interface (and specifically Exchange Management Shell) can help us do something that might have been tedious, difficult, or simply impossible to do in Exchange Management Console.

Our company, a very large organization, has just acquired a small company that has 33 users. We need the 33 new mailboxes to receive a specific policy. However, there are 33,000 mailboxes in the organization, and the new users are not organized by subsidiaries. This means that some users are in the Managers OU in Active Directory and others are in regional OUs. Therefore, the 33 mailboxes do not have any attribute in common that is displayed in Exchange Management Console. However, because a Company attribute is designated in the AD, if we used it to represent the subsidiaries, we can leverage that attribute in Exchange Management Shell, as shown next.

PS C:\Users\Administrator>Get-User -Filter {Company -eq "RomacSign"}
| Enable-Mailbox "AssemblyDB"

I know. We’ve not even looked at the makeup of a cmdlet yet and I throw that at you! However, think of it this way: In that one short line of typed code, we have created 33 mailboxes for the new users who have been recently migrated into our Active Directory, and we have done so quite easily and economically. Without Exchange Management Shell, we would have had to find the 33 users who needed mailboxes (which could be quite tedious) and then manually apply the change. Within a short time, the preceding cmdlet will not only make sense to you, but you will be writing ones much like it with little effort.

So, dive right in and start working with Exchange Management Shell, and very soon you will be amazed with all the tasks that are not only possible, but that are achievable in just a short period of time.

One other point I’d like to make is that many of the examples in the book have values for parameters. These match the design documented in the appendix. To help you distinguish what part of the command you have to enter exactly as shown, and what part of the command is a parameter you need to provide, the parameters are underlined in the book. For example, in the previous command RomacSign and AssemblyDB are both underlined to let you know they are parameters that you’ll need to change to match your organization.