Routing changes recap
By now you’re probably aware of the basics of Exchange Server 2007 routing:
- No more routing groups (except for legacy purposes)
- No more routing group connectors (except for legacy purposes)
- Uses AD sites and site links instead
- Uses least cost routing with no more rerouting over an alternate path (rely on network layer’s OSPF capabilities to do that for us; more diagnosable due to being deterministic)
- Queue closest to point of failure (back-off)
- Improved bifurcation algorithm
However, many people are still confused about the exact message around co-existence. Many of you remember how painful it was to transition to the LINKSTATE based routing because 5.5 had no concept of it. Well, this time, not only do you have to deal with the fact that Exchange 2007, like 5.5, does not speak the language of LINKSTATE, but you also have to deal with entirely new concepts. Add that to the fact that your legacy versions of Exchange will not even pretend to understand what goes on inside of the Exchange 2007 routing group.
The good news is that we’ve learned some from the past and we’re providing what I think is some pretty solid guidance about how to do your migration and coexistence and survive with as little pain as possible.
Phase 1: The introduction of your first Exchange 2007 servers
The first obstacle you will face is that you want your new server roles to be able to communicate with your existing environment. Assuming that you’re not installing into a completely new forest, the first thing you will need to do is pick which of your existing routing groups you will connect with. This is because all of your Exchange 2007 servers will exist in a special routing group that should only house Exchange 2007 servers.
Currently, when you run your first installation of a hub role, you will be prompted for this information so that a Routing Group Connector (RGC) can be created for you (if using setup unattended, this is specified with a switch). In an ideal world, your first Exchange 2007 server is going to be near to one of your existing hub RGs and you’ll just pick that.
Introducing your first Exchange 2007 server:
If you’re installing into a spoke site, then the decision becomes a bit more tricky – if you pick the spoke RG, then when you send mail back and forth between Exchange 2007 and legacy servers, it will all stay within the physical location. However, when you go to add additional Exchange 2007 servers to other locations, you’ll need to do some work so that all mail going between the Exchange 2007 and legacy worlds is not being directed through that location. For example, if you deploy your first Exchange 2007 server in Chicago, you may not want mail going between your Hong Kong Exchange 2007 server and Hong Kong legacy servers to have to go to Chicago first.
All mail going between legacy and Exchange 2007 servers in Hong Kong will have to go across the RGC in Chicago:
However, if you pick an intermediary hub for your first co-existence RGC, then all mail making the transition between the Exchange 2007 and legacy worlds in both Ireland and Japan will have to go through that hub.
Bottom line: for your co-existence RGC that gets created as part of your first installation, pick the RG/location where you intend to deploy the most Exchange 2007 servers initially. You can always add routes later (see phase 2).
Important change from some of our very early documentation: As long as you only have a single RGC between the Exchange 2007 world and the legacy world, you do NOT need to do anything to disable Linkstate. If you have ever seen this guidance, you may ignore it for now. Basically, except for the one link between the two worlds, Exchange 2007 and legacy servers will operate independently with no chance for loops to exist. The true beauty of this is that many smaller customers with only 1 or 2 routing groups will probably never even have to think about this.
Phase 2: Coexistence is a necessary evil
No one that I know likes coexistence, but unless you have the tooth fairy working for you, I suspect you will need to plan for this phase. Basically, now you’re deploying in a few locations around the globe. The single co-existence RGC is no longer adequate. You want mail in Japan to stay in Japan, and mail in Ireland to stay in Ireland, but you’re not quite ready to move everyone to an Exchange 2007 server to do it.
Fortunately, creating additional co-existence connectors is perfectly fine. All you have to do is pick one or more Exchange 2007 and one or more legacy servers to be bridgeheads for the connector. On the legacy side, pick server(s) from the routing group that matches the location. On the Exchange 2007 side, you want to pick the server(s) that reside in the closest AD site. For best results with Exchange 2007 routing group connectors, use the new PowerShell task “new-RoutingGroupConnector”. Optionally, you can still use Exchange 2003 ESM to create these, but you have to originate the connector in the E2K3 routing group & choose to create both directions at the same time; plus, there’s an extra step of adding the legacy servers to the “ExchangeLegacyInterop” security group.
Creation of an additional RGC between Hong Kong routing group and the Exchange 2007 servers in that location:
But wait! If you do that, you now have more than one way in and out of the Exchange 2007 routing group that has no idea about Linkstate. Because of that, you could end up in a situation where E2K3 sees the best route as not necessarily being the least cost route (if a connector is marked down for example). Exchange 2007, however, always picks the least cost route, and you now have a potential looping situation!
This is where we say you MUST “disable” Linkstate. Well, technically, you’re not going to disable it. You’re going to suppress the possibility for any connectors to be marked down. You’ll do this by setting the SuppressStateChanges registry key that is talked about in the Exchange 2003 Routing and Transport Guide. This will ensure that legacy versions of Exchange also will only use least cost routing, and there will then be no chances for loops to occur. You should set this registry key on all servers. (Sidebar: It is technically not necessary to set it on all servers – there are many servers in a typical environment that do not host connectors, or that host connectors that already cannot be marked as down, such as a connector where no other route exists, or one with multiple bridgeheads. However, this recommendation is being made for simplicity and because configuration changes could be dangerous if the registry key is not set everywhere.)
Linkstate will still propagate, but it will be a lot more boring because there won’t be any connector state changes. These are minor version changes. Major version changes (configuration updates) and user version changes (used by status & monitoring) will still occur. Make certain that you understand that by making this change, mail will no longer reroute to a different connector!
Some other things to remember:
- When Exchange 2007 has to route mail over to the legacy environment, it will select the path that keeps the message in the Exchange 2007 environment as long as possible. In other words, it will try to minimize the legacy connector costs before it tries to minimize the AD site link costs. In this way, Exchange 2007 will always keep mail going to Exchange 2007 within the new environment – it will never attempt to backbone over a legacy server.
- When legacy Exchange has to route a message to the Exchange 2007 environment, or through it, it will pick the least cost route based on the legacy RGC costs. It will never know anything about the AD topology. For this reason, you want to consider your legacy connector costs carefully. The current version of the new-RoutingGroupConnector task costs new connectors at 1 by default. This may be too low if you’re not ready to backbone over Exchange 2007.
Showing how Exchange 2007 calculates least cost routing in complex mixed topology:
Bottom line: you must suppress minor version changes in your legacy environment before introducing additional co-existence connectors. It is also a good idea to understand basic route selection algorithms before setting the costs on RGCs – or mail may take a route that you do not expect.
Phase 3: Getting rid of legacy servers is easy, right?
Wrong! This is actually where the biggest risks are. One of the worst things you could do during the migration from Exchange 5.5 was to create a shiny new RGC to replace your 5.5 site connector, and then change your mind. The reason is because once Linkstate propagation starts, you should not break it. Configuration changes propagate via Linkstate (when a major version changes, this indicates a configuration change). Once the major version for a particular routing group is non-zero, it will no longer be read from the AD, but instead will be expected to come via the Linkstate updates, from the routing group master which is authoritative for that routing group.
Well, essentially, that’s what you’re doing now! You’re changing your mind and getting rid of the RGCs that propagate Linkstate and slowly going back to the least cost only world. You’re breaking propagation, because Exchange 2007 won’t be propagating Linkstate information. We call this creating Linkstate islands. The good news is that users already on Exchange 2007 will never see any pain. Also good news: stragglers in the legacy world will always see things like new Internet SMTP connectors homed in Exchange 2007 (Exchange 2007 never will speak Linkstate, so it will always have a major version 0, and changes will always come from the AD). The bad news is the stragglers in the legacy environment may not see routes changes that are created elsewhere in the legacy org.
Deleting the Chicago RG will create Linkstate islands:
The only simple solution to this problem is this: if you create a situation where you backbone over the Exchange 2007 RG, then you must have an alternative path for Linkstate to propagate. That is, there must be a path for every legacy server to talk to every other legacy server that does not pass through the Exchange 2007 RG. You can cost these alternate paths such that no mail will ever flow through them – they will only be used for Linkstate propagation – so that no islands exist.
How to properly remove the Chicago RG and solve the Linkstate island issue:
If this is too confusing for you, consider this option, which while not required, will also most definitely keep you out of trouble: keep it such that emails between any two users anywhere in the legacy environment never have to go through an Exchange 2007 server.
Bottom line: whenever you remove a legacy RGC, you must consider whether or not you are creating Linkstate islands in doing so. If you do, then you must create a dummy connector between the two islands for Linkstate propagation – otherwise, configuration changes will not be known by both sides.
One last piece of good news. We are planning for ExBPA and the new Exchange Troubleshooting Resolution Assistant suite of tools (Mail Flow Analyzer) to eventually check to make sure that these recommendations are followed correctly. If they are not followed, they will be flagged for you – but only when you run the tools. It might therefore be a good idea to run the appropriate tools whenever you make a routing topology change.
If you follow these very simple recommendations, the hardest part of your transition away from Linkstate will be making the plans for the party to celebrate its demise.