Executive Summary: |
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."
The Edge Transport Server Role
The Edge Transport server role is new to Exchange 2007. It sits at the network perimeter and acts as an SMTP proxy, which shields back-end Exchange servers from the Internet, and it also performs a variety of message hygiene tasks prior to those messages being placed into the transport pipeline and ultimately into users' mailboxes.
In their native form, Edge Transport servers are compatible only with other Exchange 2007 servers. Edge Transport servers use a completely different architecture than any other type of Exchange server. Although Exchange is typically dependant on AD, an Edge Transport server isn't even a member of a domain. Instead, it contains an application partition that's populated with a small subset of AD information, which it gets by performing an Edge Synchronization with a Hub Transport server.
Because an Edge Transport server must be able to communicate with a Hub Transport server, it isn't generally well suited to be the only Exchange 2007 server in an Exchange 2003 organization. However, you can make an Edge Transport server work with an Exchange 2003 organization if you're willing to sacrifice recipient lookup, safe list aggregation, and the various domain security features. You can find step-by-step instructions for this type of deployment in the Microsoft article "How to Deploy an Edge Transport Server in an Existing Exchange Server 2003 Organization." Although this technique works, you need to have at least one Exchange 2007 server on the back end to get the full benefit of an Edge Transport server.
The Unified Messaging Server Role
The rules for cross compatibility are pretty cut and dried when it comes to unified messaging (UM). Essentially, UM works only if there's a Client Access server and a Hub Transport server in the same AD site as the UM server. More importantly, UM isn't compatible with Exchange 2003 mailboxes. You can still install a UM server even if you have legacy Exchange servers in your organization, but you won't be able to enable Exchange 2003 mailboxes for UM.
Routing Groups
Routing groups and administrative groups are major architectural elements in Exchange 2003 but have been discontinued in Exchange 2007. What really confuses a lot of administrators is that existing routing groups and administrative groups are still accessible through ESM. Furthermore, Exchange 2007 creates its own routing group and administrative group for backward compatibility, and these groups are also visible through ESM. Fortunately, ESM uses version control to prevent you from editing some Exchange 2007–specific objects to help you avoid corrupting those objects.
Microsoft designed Exchange 2007 without routing groups because the developers felt that routing groups were redundant. In the vast majority of cases, Exchange routing groups mimicked AD site structure. Because so much of Exchange's configuration information is stored in AD anyway, Microsoft made the decision to use direct server-to-server SMTP routing, and to fall back on AD site topology for routing should a Hub Transport server be unavailable. This system provides the benefit of easier discovery across the organization.
As I already mentioned, though, routing groups are still visible through ESM. As Figure 1 shows, a coexistence environment has at least two different routing groups present. One of these routing groups is named First Routing Group, and the other is named Exchange Routing Group (DWBGZMFD01QNBJR).
As you probably know, every Exchange 2003 organization contains at least one routing group. When you install the first Exchange 2007 server in a legacy Exchange organization, Setup automatically creates a routing group specifically for Exchange 2007 servers. This routing group's name is Exchange Routing Group (DWBGZMFD01QNBJR). If you take all of the letters in the long string of seemingly random characters and roll them forward one position (D becomes E, W becomes X, etc.), the characters spell EXCHANGE12ROCKS.
So why does Setup create a routing group if Exchange 2007 doesn't use routing groups? Exchange 2007 doesn't require routing groups if it's operating in an organization consisting solely of Exchange 2007 servers. However, routing groups are an absolute requirement for Exchange 2003 organizations, so Exchange 2007 creates a routing group that it can use solely to get along with Exchange 2003 servers in coexistence scenarios.
The most important thing to know about the Exchange 2007 routing group is that it's not an ordinary routing group. It's intended for use only with Exchange 2007 servers. Remember that ESM is an Exchange 2003 management tool and is therefore unaware of the specialized nature of the Exchange 2007 routing group. ESM sees the Exchange 2007 routing group the same way it sees any other routing group. It will let you move Exchange 2007 servers into Exchange 2003 routing groups and vice versa. However, Microsoft doesn't support mixing Exchange 2007 and Exchange 2003 servers within a common routing group. Likewise, Microsoft doesn't support renaming the Exchange 2007 routing group.
Administrative Groups
Administrative groups exist in Exchange 2003 as a way of controlling which parts of the Exchange organization a particular administrator is allowed to manage. Microsoft has done away with this method of delegation in Exchange 2007 in favor of a more granular delegation model.
To see how administrative delegation works in Exchange 2007, open EMC and select the Organization Configuration container. Click the Add Exchange Administrator link located in the Actions pane to launch the Add Exchange Administrator wizard, which Figure 2 shows. You'll be given the opportunity to assign one of several different administrative roles to a user or a group, and then to choose which Exchange servers the administrative role assignment applies to. Table 1 lists the specific functions of each of the roles. It's important to remember that an administrator can be assigned multiple administrative roles.
In a way, administrative groups behave similarly to routing groups in that administrative groups have been discontinued from Exchange 2007, but a special administrative group named Exchange Administrative Group (FYDIBOHF23SPDLT) is created in mixed organizations for backward compatibility. In fact, you can see this administrative group in Figure 1.
Just as you could not safely move an Exchange 2007 server into an Exchange 2003 routing group, you should also avoid moving an Exchange 2007 server into an Exchange 2003 administrative group and vice versa. Furthermore, Microsoft doesn't support renaming the Exchange 2007 administrative group. There's an interesting TechNet article that talks about some of the problems that can occur when you move an Exchange 2007 server out of its designated administrative group. The article is "Exchange 2007 server object has been moved to a different administrative group."
Master Mixed Mode
As you've seen, Exchange 2007 has no trouble coexisting with Exchange 2003 and even Exchange 2000. However, there are some compatibility and management issues that you'll have to take into account any time you're operating a mixed-mode environment. I hope these tips will help you master your mixed-mode monster.