Managing Exchange 2007 in a Mixed Environment

Executive Summary: Microsoft supports long-term coexistence of Exchange Server 2007 with Exchange 2003 and Exchange 2000, but the new management tools and different features create management challenges. For performing actions against the whole Exchange organization or against Exchange 2007 servers, you'll need to use the Exchange 2007 management tools. Exchange 2007 formalized and expanded server roles, which you'll need to keep in mind when designing your infrastructure. Routing groups and administrative groups have been discontinued in Exchange 2007, but Setup creates default groups for your Exchange 2007 servers in coexistence scenarios.

Administrators who have recently deployed or are planning to deploy Microsoft Exchange Server 2007 into an existing Exchange Server environment often find it tricky to deal with some of the various coexistence issues that come into play. Exchange 2007 is very different from Exchange 2003 and Exchange 2000. Some of the most common coexistence problems stem from the new management tools and from some of the Exchange 2003 features that have been discontinued. In this article, I'll discuss some of the more common coexistence issues and tell you what you need to know about working around them.

First, I want to dispel a rumor that I've heard quite a bit. Supposedly, some Microsoft customer service representatives have told customers that Microsoft supports mixed Exchange environments only when the various versions of Exchange need to coexist for a short time as part of migrating the entire organization to Exchange 2007. I don't know where this rumor started, but I can tell you with absolute certainty that Microsoft does support long-term coexistence of Exchange 2007 with Exchange 2003 and Exchange 2000. For more information, see the Microsoft article "Coexisting with Exchange Server 2003 and Exchange 2000 Server."

Exchange Management Tools
As you probably know, Exchange 2007 uses a completely different set of management tools than its predecessors. Exchange System Manager (ESM) has been replaced by Exchange Management Console (EMC) and Exchange Management Shell (EMS). EMC is the graphical tool for managing Exchange 2007, and EMS is a command-line tool based on Windows PowerShell.

The biggest problem with managing mixed environments, then, is knowing when to use which tool. Both sets of tools are capable of performing some of the same tasks. If an organization has been running Exchange 2003 for a while, it's reasonable to think that administrators are going to be comfortable using ESM and might prefer to use it to perform many of the day-to-day management tasks until they gain familiarity with the Exchange 2007 tools. As you've probably already guessed, though, this can be problematic.

I'm not going to tell you that you should never use ESM after you install Exchange 2007; that just isn't the case. If Microsoft didn't want you to use ESM in coexistence scenarios, I'm sure they would have done something to disable it. However, it's important for you to know what you should use ESM for. EMC and EMS aren't 100 percent backward compatible with previous versions of Exchange. For instance, if you need to create, delete, or modify a routing group, you have to use ESM; EMC and ESM don't contain a mechanism for working with routing groups.

In some situations, it's easier to use ESM to perform a task than it is to use EMC. For example, in the RTM release of Exchange 2007, EMC was a bit lacking when it came to working with public folders. Public folder management capabilities were added to EMC in SP1, but if you're still using Exchange 2007 RTM, you'll probably find it easier to manage public folders through ESM. Generally speaking, if you're performing an operation against an Exchange 2003 server, you should use ESM; if you're working on an Exchange 2007 server, you should use EMC or EMS. Things aren't always quite so simple, though.

Occasionally, you might need to perform an operation against the Exchange organization as a whole rather than working with a specific server. If that's the case, you should use the Exchange 2007 management tools. When you install Exchange 2007, Setup modifies the Active Directory (AD) schema. Because Exchange 2007 uses AD objects and attributes that Exchange 2003 is unaware of, it's critical that you use Exchange 2007 management tools for making any organization-level changes.

In most cases, if you're performing an operation that involves multiple versions of Exchange, you'll need to use the Exchange 2007 management tools. A perfect example of this is the task of moving mailboxes between Exchange 2003 and Exchange 2007 Mailbox servers. Any time you move mailboxes to or from an Exchange 2007 server, you must use the Exchange 2007 management tools.

Server Roles
Although server roles exist in Exchange 2003, they're fairly informal—front-end server, back-end server, mailbox server. In Exchange 2007, Microsoft formalized the various Exchange roles and created some new ones. This lets you increase security and performance by installing only the specific components you need on a particular server, rather than installing the entire Exchange code base.

Because Exchange 2003 doesn't offer the same roles as Exchange 2007, it's important to consider how your Exchange 2003 servers are going to interact with the various Exchange 2007 servers on your network. Let's take a look at each of the Exchange 2007 roles and see how those roles behave in a mixed environment.

The Mailbox Server Role
The mailbox server has been the heart and soul of Exchange since the very beginning. Exchange 2007 Mailbox server roles can coexist with Exchange 2003 mailbox servers without problems. The only rule about this coexistence is that any AD site that contains an Exchange 2007 Mailbox server must also contain a Hub Transport server and a Client Access server. Keep in mind that this is an architectural design requirement, so you'll need to ensure that you plan for this before you actually begin deploying servers.

Exchange 2007 is designed so that Hub Transport, Client Access, and Mailbox server roles can coexist on the same server. In organizations with limited budgets, combining these roles is a viable option so long as you meet two conditions. First, you must make sure that your Mailbox server isn't going to be overburdened. If the Mailbox server is running near capacity and you add additional roles to the same server, you're just asking for trouble. Second, you must make sure that the Client Access role isn't performing any functions other than facilitating the Mailbox server. If you're going to use the Client Access role to provide external access to Outlook Web Access (OWA) or to mobile device users, it creates a potential security risk to place it on the same physical server as the Mailbox server role.

The Client Access Server Role
Client Access servers are the Exchange 2007 equivalent of front-end servers. The interesting thing about the Client Access role is that although front-end servers were optional in Exchange 2003, a Client Access server is a requirement in Exchange 2007 deployment.

The Client Access role has no trouble coexisting with Exchange 2003. One caveat to this is that the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server must have Integrated Windows Authentication enabled so that the Client Access server can use Kerberos authentication when communicating with the back-end Exchange 2003 server. If Integrated Windows Authentication isn't enabled, users receive ActiveSync synchronization errors.

You enable Integrated Windows Authentication through the Microsoft Internet Information Services (IIS) Manager console on your Exchange 2003 mailbox server. Navigate through the console tree to your server and expand \Web Sites\Default Web Site\Microsoft-Server-ActiveSync. Now, right-click the Microsoft-Server-ActiveSync folder and choose Properties. When the Microsoft-Server-ActiveSync Properties sheet appears, go to the Directory Security tab and click the Edit button in the Authentication and access control section. Next, select the Integrated Windows authentication check box, then click OK.

To find out if the setting is working correctly, check your application log for event ID1036, which contains the following description: The Proxy Request has failed to authenticate on . Please ensure that Integrated authentication is turned on. The presence of this event ID indicates that Integrated Windows Authentication has not been successfully enabled. If you have worked through the process described above but still receive this event ID, you might need the hotfix described at Microsoft Help and Support.

The Hub Transport Server Role
Another essential Exchange 2007 component for which there's no real Exchange 2003 equivalent is the Hub Transport server role. The closest thing Exchange 2003 has to a Hub Transport role is that it can act as a bridgehead server. Of course, Exchange 2003 organizations don't require a bridgehead server unless the organization consists of multiple sites.

By comparison, Exchange 2007 requires at least one Hub Transport server regardless of the size of the Exchange organization. Microsoft designed Exchange 2007 so that all inbound and outbound messages flow through something called the transport pipeline, which is implemented by the Hub Transport server. Therefore, Exchange 2007 is capable of analyzing each message as it flows through the pipeline and applying any applicable rules.

In a mixed-mode environment, you must ensure that there are routing group connectors between any Exchange 2003 routing groups and the Exchange 2007 routing group. You establish such connections by opening ESM and navigating through the console tree to Administrative Groups\your administrative group\Routing Groups\your routing group\Connectors. Next, right-click the Connectors container and choose New, Routing Group Connector from the shortcut menu.

Furthermore, if you create any additional routing groups that list an Exchange 2007 server as the source or target, you'll have to suppress minor link state updates on all of your Exchange 2003 servers. For information on this procedure, see "Upgrading to Exchange Server 2007."