By now, you've seen a few of our Spotlight on Exchange 2010 postings. If you have, hopefully you're excited about the great work that has been going on to make Exchange 2010 the best version of Exchange yet. So then the practical side of you kicks in and starts to wonder what it is going to take to start utilizing these new features when the time comes. Certainly, rolling out a new version of Exchange is rarely an endeavor to be entered into lightly.

In the interest of making certain that you can begin planning early and as informed as possible, I want to call out a requirement that we had to put in place for Transport server roles in order to deliver a quality product with cool new features. This requirement is often referred to as "version-based routing" or just "versioned routing."

What this requirement means

Simply put, this requirement means that Exchange 2010 Hub Transport servers and Exchange 2010 Mailbox servers will only communicate with each other. Also, it means that Exchange 2007 Hub Transport servers and Exchange 2007 mailbox servers will only communicate with each other. However, any version Hub is able to communicate (via SMTP) to any other Hub server. So, for a user on Exchange 2007 to be able to send to a user on Exchange 2010 in the same site, the mail must pass through both Hub servers.

For example:

Note that Exchange 2007 Service Pack 2 implements this restriction for Exchange 2007 Mail Submission and Exchange 2007 Mailbox Delivery. This is one reason that Service Pack 2 is required before deploying Exchange 2010 - and all servers must remain at Service Pack 2 to ensure that this feature continues to work properly. Also, note that (while out of scope of this posting) this same requirement applies to Client Access servers - Client Access server versions must match the version of the mailbox server that they are communicating with.

The mail routing between Exchange 2003 and Exchange 2010 has not changed from Exchange 2007. In Exchange 2010 we still rely on a Routing Group Connector (RGC) between the Exchange 2003 Routing Group and the Exchange 2007/2010 Routing Group. If you do not have Exchange 2007 today and would like to know more about routing considerations migrating from Exchange 2003, check out this post. Additionally, mail flow between AD sites (because it also uses SMTP) is not affected by version based routing.

Possible migration strategies

For a single all-in-one server deployment, the migration from 2007 to 2010 is relatively simple, just as it was from 2003 to 2007. Simply bring up the new server and migrate mailboxes. During that migration, mail will simply flow from one server to the other without impacting users - simply make sure that both servers have both roles.

For more complex migrations, in the interest of utilizing hardware effectively, you may consider using a swing server type method. That is, you have one spare server that you install Exchange 2010 onto. Once you move the mailboxes from 2007 to 2010, you can reclaim the hardware to repeat in other locations. For this reason, you want to incorporate this into your planning, and possibly consider a short co-existence period. Of course, as your users on 2007 are moved to 2010, you may consider appropriating hardware from being 2007 Hub servers to 2010 Hub servers.

A special note about redundancy/fault tolerance: Depending on the requirements and number of users, you also may consider making sure that you always have 2 hubs of both versions for redundancy. Of course if you have Exchange 2007 deployed with CCR clustering, then the Hub role cannot be installed on the same server. However, the replacement for CCR, Database Availability Group (DAG) does allow the Hub role to coexist with the mailbox role.

For those that have less hardware available, particularly if that hardware will be underutilized, virtualization is a great option for minimizing the number of physical servers that are required. Best of all, physical resources can be reallocated without having to rebuild an entire machine, although it requires that the environment was virtualized to begin with. For example, you could have two physical machines hosting both Exchange 2007 and Exchange 2010 Hub transport roles, providing you with redundancy for both versions, while not requiring additional hardware. Hyper-V is of course provided at no extra cost for those running Windows Server 2008 or later.

Why this requirement?

Essentially, as with most software development, this decision was about tradeoffs. But, first a little history...

If you're interested in these sort of things, you may be aware that as of Exchange 2007, transport no longer uses the now defunct Exchange file system driver to move messages in and out of the mailbox store. Instead we use a special managed internal RPC API that has some similarities to MAPI called Exchange Storage Objects (XSO). For many reasons, XSO is not a public API like Exchange Web Services or MAPI, but it is used by other roles that need to get messages in and out of the mailbox store.

If I still haven't lost you, you may also be aware of the huge value proposition we're delivering with the improvements to storage and the I/O requirements. In order to do that, and prepare for continuing storage improvements, some changes had to be made to the database schema. Accordingly, the XSO API had to be updated, and any code that utilized the old API had to also be updated.

Originally, the plan was to require that Exchange 2010 be in a separate AD site from the Exchange 2007 servers. Because that would have made deployment incredibly difficult, the Transport team took a feature to introduce the concept of "version based routing." This is also why Service Pack 2 is now required on Exchange 2007 servers.


Now that you understand the requirements introduced, you can plan accordingly to keep mail flowing smoothly during the migration to Exchange 2010. Feel free to let us know what you think - does this information help you plan better?

By the way, this will be more formally documented in these online help topics (depending on when you check, this may or may not be fully updated at the time of this posting):

- Scott Landry