Microsoft Exchange Server 2010: Exchange Server Coexistence

  • Article

You can start from scratch with Microsoft Exchange Server 2010, but it’s far more likely that you’ll need to work alongside an older version for a while.

Excerpted from “Exchange 2010 - A Practical Approach,” published by Red Gate Books (2009).

Jaap Wesselius

It really isn’t that difficult to install and correctly configure Exchange Server 2010 in a new environment. However, it’s more likely that you’re already using an earlier version of Exchange, like Exchange Server 2007 or Exchange Server 2003. That gets a bit more complicated.

Many companies haven’t upgraded from Exchange Server 2003 to Exchange Server 2007. A common reason is that “Exchange Server 2003 is good enough.” To be fair, if the scalability, unified messaging or high availability options in Exchange Server 2007 can’t help you make a solid business case for upgrading, that’s a perfectly understandable decision.

With Exchange Server 2010, however, things will change. Besides the new functionality, you’ll find that Microsoft will eventually stop supporting Exchange Server 2003. Microsoft’s focus will be on Exchange Server 2010 and Exchange Server 2007. So, if you want to make sure you’re fully supported, you can upgrade to Exchange Server 2010 in two ways:

  • Integrate Exchange Server 2010 into your existing infrastructure and transition your mailboxes to the new Exchange servers. You can use this method when you’re running Exchange Server 2007 or Exchange Server 2003.
  • Build a new Active Directory and Exchange Server 2010 infrastructure and migrate your mailboxes to the new environment. This is the preferred method if your current environment isn’t compatible with Exchange Server 2010.

Moving mailboxes from Exchange Server 2003 to Exchange Server 2010 is called transitioning. If you already have Exchange Server 2010 installed and you’re moving a new Active Directory forest and mailboxes from one Active Directory forest to another, it’s called migration.

Here I’ll focus on integrating Exchange Server 2010 into an existing Exchange Server 2003 or Exchange Server 2007 environment. Keep in mind that you won’t be able to install Exchange Server 2010 into an Exchange Server 2000 environment. This is enforced in the setup programs, which will check the current version of all Exchange servers. If Exchange Server 2000 is detected on any server, the setup program will display an error and abort.

Exchange Server 2010 supports the following deployment scenarios:

  • Single Forest, Single Active Directory site
  • Single Forest, Multiple Active Directory sites
  • Multiple Forest, Multiple Active Directory sites
  • Coexistence with Exchange Server 2003 SP2—an Exchange Server 2010 coexistence scenario will not support older versions of Exchange Server 2003
  • Coexistence with Exchange Server 2007 SP2—an Exchange Server 2010 coexistence scenario will not support older versions of Exchange Server 2007

When transitioning to Exchange Server 2010, you must start with an Internet-facing Active Directory site. Other Active Directory sites will move later in the transition process. You can’t start with internal Active Directory sites because it’s not supported.

Coexistence Scenarios

Let’s talk about getting you running Exchange Server 2010 in coexistence with the respective older environments, including:

  • The order in which you should install the different servers
  • Active Directory upgrades and prerequisite considerations
  • The actual installation process for Exchange Server 2010
  • The SMTP infrastructure
  • Moving mailboxes

When planning to have Exchange Server 2010 coexist with Exchange Server 2003, you have to consider the numerous differences between the two. The most important are:

  • Exchange Server 2010 is available only in a 64-bit version
  • Exchange Server 2010 doesn’t use Administrative Groups for delegation of control
  • Exchange Server 2010 doesn’t use Routing Groups for routing messages
  • Exchange Server 2010 doesn’t use Link State Routing for updating the routing table
  • Exchange Server 2010 doesn’t use the Recipient Update Service for setting Exchange properties on recipient objects

This is a much more extensive list than the differences with Exchange Server 2007. These differences are also more significant. Just to make sure everyone is on the same proverbial page, here is a closer look at what is different.

64-bit Support

Exchange Server 2010 is only available in a 64-bit version. The Exchange Product Group is taking full advantage of the hardware advances made since the release of Exchange Server 2007. The current 32-bit (X86) platform was developed in the mid-1980s, and has a 4GB memory limit. In those days, 4GB of memory was beyond everyone’s imagination. Today, 4GB of memory is commonly installed in a laptop.

As the successor of the 32-bit platform, one of the clear advantages of 64-bit is a theoretical memory limit of 2^64 bytes, or 16PB (petabytes). Windows obviously can’t address this much memory yet.

The current memory limit of Windows Server 2008 R2 Enterprise is 2TB. Naturally, current processors can’t address anything close to this much physical memory, but Moore’s law and the inexorable march of technological progress mean that this limit will continuously expand in the future.

While 4GB of memory might be enough for a laptop or workstation, for large server applications like Exchange server, a mere 4GB of memory is a huge limitation—a fact that can be clearly illustrated in Exchange Server 2003, when having more than 2,000 mailboxes on one Exchange server will result in a severe disk I/O penalty, which typically results in an expensive storage solution. There are special techniques for addressing more than 4GB of memory on the 32-bit platform, like a Physical Address Extension (PAE), which you can read more about at Microsoft Support (tinyurl.com/32bitPAE).

However, Exchange Server 2003 does not use this technique. It’s stuck with the 4GB memory limit (and you can read more about that at Microsoft Support: tinyurl.com/2003Limit). Given that Exchange server 2010 is only 64-bit, this automatically implies that an in-place upgrade of Exchange Server 2003 to Exchange Server 2010 is impossible. You must always install a new Exchange Server 2010 in a 2003 environment on separate hardware. The same is true for Exchange Server 2007. Although it’s also a 64-bit application, Microsoft doesn’t support an in-place upgrade due to technical complexity in both products.

Administrative Groups No Longer Delegate Control

Exchange Server 2003 uses Administrative Groups for delegating control. This lets you create multiple Administrative Groups and delegate control to different administrators. For example, if you’re with a large multinational company, you could create Administrative Groups for each country. Each country could have its own Exchange administration department, responsible for maintaining their local Exchange servers.

You could delegate control of the appropriate Administrative Group to specific Universal Security Groups, to which these Exchange administrators are assigned. Unfortunately, this approach is complicated and error-prone.

Exchange Server 2010 no longer uses Administrative Groups. When you first install Exchange Server 2010, it will create a new Administrative Group in Active Directory called “Exchange Administrative Group (FYDIBOHF23SPDLT).” It will install all subsequent servers in this Administrative Group. You now delegate control in Exchange Server 2010 with a Role-Based Access Control (RBAC) model.

Routing Groups No Longer Route Messages

For routing messages between different locations, Exchange Server 2003 uses Routing Groups. A Routing Group is a location with a high-bandwidth and low-latency network, such as an office with a 100 Mbps internal network where all Exchange Server 2003 servers have full access to each other all the time.

When there are multiple locations present, each has its own Routing Group. The Routing Groups in an Exchange infrastructure are connected with Routing Group Connectors, so Routing Groups are very similar to Active Directory sites. There have been Active Directory sites since Windows 2000 Active Directory, but Exchange Server 2003 just didn’t use them.

Instead of Routing Groups, Exchange Server 2010 now uses Active Directory sites to route messages to Exchange servers in other locations. To connect Exchange Server 2010 with an Exchange Server 2003 environment in the same Active Directory forest (and thus the same Exchange organization), there’s a special Routing Group, “Exchange Routing Group (DWBGZMFD01QNBJR),” created when you first install Exchange Server 2010.

There’s also a special Interop Routing Group Connector created during that initial server setup. This routes messages between Exchange Server 2003 and Exchange Server 2010. Because Exchange Server 2010 uses Active Directory sites for routing SMTP messages, every site that contains an Exchange Server 2010 Mailbox Server role will also need an Exchange Server 2010 Hub Transport Server role.

A process called Link State is used to keep routing information up-to-date in Exchange Server 2003. When a connector in Exchange Server 2003 changes its state, it updates the Routing Table used by the Routing Group connectors. This Routing Table is immediately sent to other Exchange servers in the same Routing Group.

When an Exchange Server 2003 server initiates an SMTP connection to a similar server in another Routing Group, it compares the Routing Tables on both servers. If needed, the newer version of the Routing Table is sent to the other server.

This works fine as long as the Routing Table is not very large. There are known cases with more than 75 Routing Groups and hundreds of Routing Group Connectors where the Routing Table was between 750KB and 1MB in size. It might not sound like much, but when a Routing Table is being exchanged frequently, this will have a noticeable negative impact on the network traffic across the WAN.

As explained previously, Exchange Server 2010 has replaced this whole system with Active Directory site links. This leverages Active Directory information to determine an alternate route when a specific link is no longer available. Before installing the first Exchange Server 2010 server into an existing Exchange Server 2003 environment, you need to suppress Link State Updates to avoid routing conflicts between the Exchange versions.

There’s more information on message routing in Exchange Server 2003 in the “Exchange Server Transport and Routing Guide.” When you want to take a closer look at the routing table in your own Exchange Server 2003 environment, you can download the WinRoute tool.

Recipient Update Service vs. E-mail Address Policies

The Recipient Update Service (RUS) in Exchange Server 2003 is the service responsible for updating the Exchange-specific properties of Exchange recipients in Active Directory. When you use Active Directory Users and Computers to create a new user, the RUS will pick up the user account and “stamp” it with Exchange-specific attributes, such as the homeserver, homeMTA, homeMDB and e-mail addresses. It can take some time for a user to be fully provisioned and available, especially on busy servers. The Service is part of the System Attendant, and there’s only one instance running in each Active Directory domain.

Exchange Server 2010 doesn’t use the RUS anymore. It uses E-mail Address Policies instead. When you create a mailbox-enabled user, it immediately applies an E-mail Address Policy. Therefore, the mailbox is instantly available. The user object still needs to be replicated between all domain controllers to be fully available at all locations.

In a coexistence scenario, you can only manage the RUS and the accompanying Recipient Policies from the Exchange Server 2003 System Manager. You can only manage the Exchange Server 2010 Address List Policies from the Exchange Management Console or the Exchange Management Shell. The only time a Recipient Policy is accessed using the Exchange Management Shell is when upgrading the Recipient Policy to an E-mail Address Policy.

Keeping these different capabilities and configuration options in mind ought to help you keep your Exchange Server 2010 coexisting peacefully with Exchange Server 2007 or 2003.

Jaap Wesselius

Jaap Wesselius is the founder of DM Consultants, a company with a strong focus on messaging and collaboration solutions. After working at Microsoft for eight years, Wesselius decided to commit more of his time to the Exchange community in the Netherlands, resulting in an Exchange Server MVP award in 2007. Wesselius is also a regular contributor at the Dutch Unified Communications User Group and a regular author for Simple-Talk.

Learn more about “Exchange 2010 - A Practical Approach” at red-gate.com/our-company/about/book-store/.

Related Content