A new way of looking at a familiar face
| Executive Summary:|
Microsoft Exchange Server 2007 has new management tools that replace the familiar Exchange System Manager. To manage Exchange Server 2007, you need to learn how to use Exchange Management Console and Exchange Management Shell.
Why Not Just Use ESM?
The ESM window in Figure 1 shows two Exchange servers: Tazmania (an Exchange 2003 server) and Mirage (an Exchange 2007 server). Because ESM can display both, you might wonder why you shouldn’t use ESM to manage both versions of Exchange. This seemingly simple question actually has a fairly complicated answer—I could probably write an entire article on the subject. I don't have room to do that here, so I’ll keep the explanation short.
With Exchange Server 2003, Microsoft had to introduce new features while making Exchange Server 2003 compatible with earlier versions of Exchange. Some of the new features simply couldn't be made backward-compatible, though, so Microsoft adopted the concept of native mode. The basic idea was that Exchange 2003 could coexist with legacy Exchange versions, but if it did, not all its features could be used. After all legacy Exchange servers had been decommissioned or upgraded, the administrator could set Exchange 2003 to run in native mode and take advantage of all its new features.
For some reason, Microsoft didn’t use that approach with Exchange 2007, which doesn’t have a native mode. The good news is that you can take advantage of most of Exchange 2007’s new features even if your organization still has some Exchange 2003 servers. The bad news is that the lack of a native mode creates a bit of a management dilemma because prior to SP2, the Exchange 2003 management tools are unaware of the new features of Exchange 2007.
You can use ESM to view the settings on Exchange 2007 servers, but you should use the Exchange 2007 management tools to manage those servers. For example, notice that the Exchange 2007 and Exchange 2003 servers in Figure 1 are in two different administrative groups. Microsoft did away with administrative groups in Exchange 2007; however, because administrative groups were an essential part of Exchange 2003, Microsoft created a special administrative group for Exchange 2007 servers to make them backward-compatible with Exchange 2003. That’s why the administrative group containing the server Mirage has a funky name. Once you get rid of all of the legacy Exchange servers in the organization, the administrative groups go away.
As with Exchange 2003 and Exchange 2000, Exchange 2007 extends the Active Directory (AD) schema as a part of the installation process. Part of this schema extension involves adding new attributes to some object types, such as mailboxes. When you create a mailbox on an Exchange 2007 server, Exchange expects that mailbox to have certain attributes set. If you use ESM to create a mailbox on an Exchange 2007 server, some of the necessary attributes will be missing because ESM is unaware of their existence. Missing attributes can lead to a variety of problems, such as users being unable to open their mailboxes through Outlook Web Access (OWA). However, if you make a mistake, you can always update the mailbox with Exchange 2007 to make sure that the necessary attributes are in place.
Using Exchange 2007 management tools to manage Exchange 2007 servers and Exchange 2003 tools to manage Exchange 2003 servers is pretty much just common sense. But what happens if you need to manage some aspect of your Exchange organization that is not server specific? If you need to perform a management task at the organization level (as opposed to the server level), you should always use the Exchange 2007 management tools.
Creating a Mailbox
Exchange management tasks often involve mailboxes. In Exchange 2003 you had to use the Microsoft Management Console Active Directory Users and Computers (ADUC) snap-in to create a user account. If ESM was installed on the machine on which you were running the snap-in, you could create a mailbox at the same time that you created the user. Otherwise, you had to use ESM to mail-enable the user after the account was created. If the Exchange management tools are installed on a server that has ADUC installed, then ADUC is extended to include Exchange functionality.
In Exchange 2007, you still have the option of creating the mailbox when you create the user account or mail-enabling the user account later, but both tasks are done a bit differently. Microsoft decided that Exchange should exert control over its own objects so that they could create the supporting business logic in PowerShell to do all the work—they couldn’t do this when some components (like AD) don’t yet support PowerShell.
When you create a mail-enabled user from scratch in Exchange 2007, you shouldn't use the ADUC snap-in because the mailbox will lack some attributes, as I explained earlier. Instead, you can create the user account and the mailbox directly through EMC or EMS.
To create a mail-enabled user through EMC, open EMC and navigate to Recipient Configuration\Mailbox. The console displays every mailbox in the Exchange organization. Before you continue, take a look at the Recipient Type Details column. As Figure 2 shows, Exchange 2007 doesn't take a one-size-fits-all approach to mailboxes. You can create either a user mailbox or a resource mailbox. User mailboxes are essentially the same as the mailboxes that you created in Exchange 2003. Resource mailboxes are designed for scheduling resources and come in two flavors: room mailboxes and equipment mailboxes. When you click the New Mailbox link in the Actions pane, the screen in Figure 3 appears and lets you choose the type of mailbox you want to create.
Although user and resource mailboxes are the most common types of mailboxes, you should be aware of two other types. As Figure 3 shows, you can also create a linked mailbox. A linked mailbox is accessible to external users outside the forest. Because there isn’t really an Exchange 2003 equivalent to a linked mailbox, I don't go into detail about them here.
Another type of Exchange 2007 mailbox that's much more important to Exchange 2003 administrators is the legacy mailbox. A legacy mailbox resides on a server that's running an older version of Exchange. EMC shows all Exchange 2003 mailboxes as legacy mailboxes, as you can see in Figure 2. Just as you can view Exchange 2007 mailboxes through ESM, you can view and edit Exchange 2003 mailboxes through EMC. But because mixing Exchange versions and management tools can cause problems, you should resist the temptation to manage Exchange 2003 mailboxes through EMC.
To create a user mailbox, select the User Mailbox option in the window shown in Figure 3 and click Next. In the next window, you can choose to create a mailbox for an existing user or a new user. For an existing user, choose the Existing User option and click Browse to locate the user account for which you want to create a mailbox. For a new user, select the New User option and click Next. In both cases, the next screen you see will be similar to the Active Directory Users and Computers snap-in that you used to set up a new user in Exchange 2003. Enter the pertinent information and click Next.
In the Mailbox Settings screen, which Figure 4 shows, you select the server, storage group, and mailbox database that will hold the new mailbox. Just beneath the Mailbox database drop-down list is an option to choose a managed-folder mailbox policy. New to Exchange 2007, managed-folder mailbox policies let you create groups of managed folders that you can then deploy together to users' mailboxes. Of course, setting a managed-folder mailbox policy is optional. For more information on record management, see "Meet Email-Retention Needs with Exchange 2007," February 2007, InstantDoc ID 94607.
The last option on this screen lets you apply an Exchange ActiveSync policy to the mailbox. Exchange ActiveSync policies were introduced in Exchange Server 2003 SP1. The biggest difference between Exchange ActiveSync policies in Exchange 2003 and Exchange 2007 is that in Exchange 2003, ActiveSync policies were global in scope. Exchange 2003 let you create only one ActiveSync policy, and that policy applied to all your mobile users. Exchange 2007 lets you create multiple ActiveSync policies and apply them to mailboxes as needed.
Click Next and the console will display a summary of the options you've chosen. When all the options are correct, click New to create the new user account and mailbox. When the process completes, you'll see a confirmation screen like that shown in Figure 5.
Exchange Management Shell
As we've seen, EMC is a GUI tool. In contrast, EMS is a command-line environment that lets you script administrative actions. What makes EMS so interesting is that EMC was built on top of it, so that anything that can be done through EMC can also be done through EMS. Even Exchange 2007’s Setup was built on top of PowerShell, which means that it is possible to script Exchange 2007 deployments.
As you might have guessed, some of the commands required to perform administrative tasks are rather long and complex. For example, when we created a new mail-enabled user through EMC, we had to supply quite a bit of information, all of which would have to be included in the command if you performed the task using EMS. Fortunately, the folks in Redmond realized that there was going to be a pretty steep learning curve associated with EMS, so they gave us a bit of help.
In Figure 5, you can see several lines of text in the middle of the confirmation window. This text shows the command you'd use in EMS to perform the task you just completed. You might be thinking that having the command’s text displayed within the GUI is nice but wonder about its practicality. After all, the text in Figure 5 shows the command for creating a user named User10. Now that I’ve got a User10, I don’t need another one. Sure, I could modify the command and create a User11, but it’s much easier to just point and click my way through the GUI than to modify a command for each new user.
Even if you hate command-line environments, there are at least two good reasons why you don’t want to completely shun EMS. First, it's handy for performing repetitive tasks. Yes, it would be a pain to modify the command shown in Figure 5 just to create a user account, but what if I need to create a thousand user accounts? In that case, using EMS to create a script would be much more efficient.
The other reason you need to learn about EMS is that you can use it to do many things that you can't do through the GUI. When Exchange 2007 was released, the GUI wasn’t completely finished. The development staff ran out of time and ended up having to omit several features from the GUI. For example, EMC provides almost no capabilities for managing public folders. If you want to perform public folder management tasks, you have to use EMS.
In all fairness, Microsoft has added a few important capabilities (e.g., the ability to manage public folders) to the GUI in Exchange 2007 SP1. But you never know when you'll have to work on a server that doesn't have SP1. Furthermore, some of the more advanced management functions are available only in EMS. This is by design—the developers in Redmond decided that some functions are just too potentially destructive to include them in the GUI, where inexperienced administrators might accidentally invoke them without fully understanding the impact of their actions. Options for performing irregular or infrequent tasks were also removed from the GUI in order to preserve its ease of use, but are readily available in EMS.
Vive la Différence
As you can see, Exchange 2007 is vastly different from Exchange 2003. I've given you some insight as to what some of these differences are from a management perspective and showed you how to perform a common task in Exchange 2007. In the next article in this series, I'll continue the discussion by showing you how to perform more common tasks in this new environment