Spotlight on Exchange 2010: Version-Based Routing

Published 10-14-2009 02:03 PM 4,766 Views

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

Not applicable
By now I've come to terms with this sort of thing, but it is frustrating to many of my customers that they had to deploy a completely new infrastructure for Exchange 2007, and now they have to start all over with Exchange 2010.  

Otherwise, personally I think this technology is cool!
Not applicable
Thanks for the information, but now that I know it sounds like "version based routing" isn't cool at all. It sounds like a workaround and a hack to avoid having to update the 2007 API to know whether or not the mailbox server is 2007 or 2010. Which probably would have simply taken more coding to accomplish.

I'm disappointed you can't mix and match server rolls, between these two very similar platforms. Other than time and money there is no reason 2007 SP2 couldn't have made 2007 HUBs compatible with 2010 mailbox servers.

I still don't see why 2010 HUBs couldn't have been made compatible with 2007 SP2 mailbox servers, which would have eased this upgrade path a lot.

Over all I'm migrating straight from 2003, so I'm not impacted but I can empathize.
Not applicable
Any upgrade of a core service such as Email shouldnt be undertaken lightly - this article provides a great starting point for solution designs. For those that havent yet made the jump to virtualisation this should serve as a well meant nudge in the right direction.

The only concern I do have is the impact on other transport applications such as AV and Email Release packages - does this mean that vendors will need to have significant code upgrades to support 2010, obviously AV/Filtering that takes place outside of the environment can still route via SMTP, but there are already a number of products that interact with the transport services and will undoubtedly have issues. (I wonder about the support for Stirling for 2010 - how far in step are the product sets)

Keep up the good work - even if you dont get significant feedback we're listening!
Not applicable
I'm with Mike's customers and Brian on this one. It seems that with every new version of Exchange there's a huge infrastructure overhaul required of the product itself and not just the typical 3rd party product overhaul (fax, backup, anti-whatever, archiving, non-Exchange UM, etc.) that comes with every new Exchange version.

We were able to upgrade from 5.0 to 5.5 and from 2000 to 2003 with relative ease, but had to migrate from 5.5 to 200/2003, from 2003 to 2007, and now again it seems from 2007 to 2010.  The 5.5 to 2000/2003 migration made sense as we moved from the Exchange Directory to Active Directory, but now this is starting to get silly with migrations required at every major release.

Many of the features introduced by the new versions are welcome, but migrations take a large amount of time and expense and it's getting harder and harder to justify the expense every 3-5 years, even for the desirable features.

For example, I especially like the ability of E14 mailbox servers configured with DAGs to be able to host both the CAS and HT roles. This makes high availability much easier than E12 where no other roles can exist with CCR mailbox servers. While those of us (including myself) on the technical side of things might sigh at the thought of a migration but resolve ourselves to do it for the technical gains, the people with the checkbooks say: "Didn't we just upgrade e-mail back in 2008 after 6-9 months of testing and planning the new system and at a cost of (some_big_number) that we're still paying off?" Then you have to try and explain why we should start planning another test and migration project at a cost of (some_other_big_number) for features that only geeks love (except for OWA 2010 - everyone loves that :) ). This blow can be mitigated a bit if there's a feature that's desired from the business side of things (such as archiving or discovery), but to many of the purseholders, "E-mail is working and I'm not paying for another 'upgrade' so soon."

My initial impression was that 2007 to 2010 would be similar enoug to allow an upgrade, rather than a migration. So it's suprising to even hear things like, "a separate AD site was the original plan." Really? I can't believe that was considered long enough to even become a "plan."

I know I sound really negative, but I think going forward this needs to be a little easier. The organizations I support like to stay current, but the Exchange overhauls have to stop.
Not applicable
Again with domain functional levels... in the Exchange 2007 - Planning Roadmap for Upgrade and Coexistence is says that "Active Directory must be in Windows Server 2003 forest functionality mode during upgrade and coexistence." What if I already rised the domain functional level to 2008 r2. Considering that exchange 2007 is working fine, can Exchange 2007 and 2003 coexist in that enviroment?

Not applicable
Thanks for the feedback so far - we're definitely listening!  Part of the purpose of this blog is to have the good two-way discussions as well as getting these sometimes tough messages out there.

@Ian - glad this has helped your planning.  The best advice I can give is to check with your vendor(s).  The APIs that they are using probably have not changed (we definitely apply different criteria for an internal API vs. an API we expose to others), but only they would know if their product has been tested and is supported on the new version.  At the least, they may have an update you should apply.

@Julian - You'll want to check the (new) supportability matrix which should help with this question:
Not applicable
Is there any info already about licensing requirements ?

With Exchange 2007 SCC you only need 1 exchange enterprise license on the mailbox role server(cluster).
What about DAG on Exchange 2010 ?
Not applicable
Overall, just frustrating.  To me it seems as if MS is trying to make this appear so difficult that they can have an esier time suggesting BPOS as an alternitive to reduce complications and migration costs.  Exch2007 RTM was horrible, the early adopters had a miserable time with support.  WIth this new "feature" (which I have to agree with the above is only a shortcut), we can imagine the headaches of this version.

If MS cant fix the CAS scenario (so I only need to have one CAS version, as in previous version the lates was alwasy backwards compatible) it doesnt make much sense at all to migrate unless you do a big bang.  It would make publishing OWA a nightmare in a mixed environment.

Personnally Id rather have Microsoft go back to the days of delivering software late but having most of the features and interporbility intact.

Just Frustrating, looks like we will stay 2007 for some time.
Not applicable
Stephan, I believe you are incorrect.  You need two licenses of Exchange for a 2-node cluster.  See here:
"When you deploy Exchange 2007 in a failover cluster, an Enterprise Edition license is required for each node on which Exchange 2007 is installed"
Not applicable
So just to be clear:

1) Can an Exchange 2010 Hub Transport send directly to an Exchange 2007 Mailbox server or not?

2) Can an Exchange 2010 Client Access "front end" an Exchange 2007 (or earlier) Mailbox server or not?
Not applicable
2-2007 CAS will redirect to 2010 CAS if user resides on 2010 MB.  Vice versa as well.  See here: Coexistence with Outlook Web Access
Not applicable
@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)
Not applicable
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...
Not applicable
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.

Not applicable
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:
Not applicable
@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!
Not applicable
@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.  
Not applicable
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.
Version history
Last update:
‎Jul 01 2019 03:47 PM
Updated by: