Blog Post

Exchange Team Blog
5 MIN READ

Spotlight on Exchange 2010: Version-Based Routing

The_Exchange_Team's avatar
Oct 14, 2009

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.

Conclusion

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

Updated Jul 01, 2019
Version 2.0
  • @Mike; thnx for this information
    I didn't know this, I always thought exchange failover licening was the same as sql server licensing.
    (which only needs 1 license per instance)
  • As stated by others before the need of a big migration with all costs that imply will be a show stopper in many companies. In my actual company at least we won't get the budget for another big migration inside the next 5 years. A soft migration (i.e. adding 2010 for a new required Mailbox Server) would be possible, but since that's not possible from the technical view I just can stop thinking about 2010. Also I have no love for the fact that the 2010 management tools can't be used to manage the 2007 servers also. I think it would be a nice idea to think about some interoperability improvement for 2010 SP1...
  • I don't even know where to start venting my frustration... would it be the fact that just about every MS product of 2007 vintage product has been nothing short of fiasco, half-baked, interim product? Or would it be seemingly unnecessary changes in interface and totaly rediculous changes to perform basic administrative duties? I'm still trying to understand how a 15 line, cryptic power shell command is more efficient than a well-designed GUI or at the very least something slightly more effective? If you look at unix shell - it's a well-optimized set of commands. Sure, some are cryptic as well - like "cp" instead of "copy" but I'd take that any day over powerHell.

    Have you tried setting up Exchange 2007 admin tools in an Exchange Resource Forest scenario? And extra points for completely abandoning the product support for Exchange 2007 in Win2K8 R2. Let's not even re-visit Vista, Office 2007, and other '07' gems.

    I know I will not in full sanity of mind recommend migrating from Exchange 2003/XP/Office 2003 to any of my clients any time soon.

    I appreciate technical advances Microsoft, I do - but to say it was done you-know-what backward would be a major understatement.

    Frustrating, really.

  • I know it's totally off-topic but in line with what I was saying earlier - Microsoft is losing it's grasp on market place and reality. I know I'm not alone in my frustration with how Microsoft has been rushing half-baked products to the market, only to have them replaced and be completely incompatible 2 - 3 short years later. I know that MS wants us to buy new product every 3 years and pay for software assurance in the interim but at some point, especially in this economy, someone in MS has to say "Hey, what about our customers?".

    This article provides a broader assesment of how Microsoft has fared in recent years and I think it sums it up nicely:

    http://www.nytimes.com/2009/10/18/business/18msft.html?_r=2&pagewanted=1
  • @Frustrated - We hear you, but it would be helpful if you could be more specific.  For example, what scenario requires you to run Exchange 2007 on Server R2?  What common scenarios are missing from the GUI that requires you to go to PowerShell?  What about PowerShell is most confusing?

    Honestly, though there are better forums, we'll even take feedback for any MS product -- just need it to be specific and actionable so that we can route it to the right place.  Thanks!
  • @Scott - I haven't bothered playing with 2010 yet, so you may have fixed these already, but common scenarios that you have to go to Powershell for in 2007.
    1. setting up certs... freaking cryptic... NO need to be
    2. list of mailbox sizes in a store on a mailbox.
    3. And did you see what got posted on 11/2? Remote Powershell, and the page of code it requries?  And the implication of that post if that its required?  Most of us aren't CODERS.. you guys get off on the coolness of the code.  Who cares!? we just want to get a job done.  
  • Ken, We should probably advertise more what we've done in certificates with the wizard in 2010 so you can offer more feedback -- not perfect, but I think you'll find it goes a long way to addressing the top concerns. #2 could be a good addition to the console -- it may be not there because of the seperation of permissions/roles, but I'll look into it more.  #3 is also a very good point.  Feel free to follow up more with me.  First.Lastname at the softie.