参考文章：
http://capitalhead.com/articles/upgrade-to-microsoft-exchange-2007-from-exchange-2003-or-2000.aspx
http://blogs.technet.com/b/exchange/archive/2006/11/01/3395982.aspx
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.
Conclusion
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.
论坛有用的帖子：
I am performing an Exchange 2007 transition for a global company which routes outbound internet email locally within each 2003 Admin group. The SMTP connector scopes are set to "Routing Group", not "Entire Organization". So, when I installed my first Exchange 2007 server and first SMTP "Send Connector" via the GUI console, all outbound internet email, in the entire organization, started going through it. Well, after much trial and error I figured out that by using the PowerShell to create the SMTP "Send Connector" (New-SendConnector) I could specify the ConnectorScope as "Local" which fixed my problem. The GUI does not give the option for ConnectorScope nor does it display it.
Hope this helps someone in the future cause I couldn't find anything on this at all.
论坛帖子2：
Its doesnt necessarily create a mail loop, but it could.
When you suppress link state changes in 2003, you are essentially telling 2003 to behave and route messages the same as 2007/2010 - based on least cost. If you dont suppress those changes and there a multiple connectors to the 2007 admin group, 2003 will try to route messages based on link state.
Imagine this scenario if link state changes arent suppressed:
A connection is down to another 2003 routing group. 2003 routes the message through the 2007 routing group to try to get that message to other 2003 routing group because it knows that the 2007 routing group also has a connection to that other 2003 Routing Group. Exchange 2007 however knows nothing about link state. Instead it uses least cost based on AD topology to route messages. The least cost is back to the same 2003 routing group that just routed a message to it. So it simply routes the message back to the original 2003 server that sent it the message in the first place. That same 2003 server simply routes the message back to the 2007 server because it determines that the link to other 2003 routing group is down. And so it goes- creating a mail loop.
With link state changes suppressed, the message will queue on the 2003 bridgeheads until the link to the other 2003 routing group is back online. A much better result.
论坛帖子3：
Exchange 2003 <=> 2007 connector question
I know that, to allow mail flow between 2003 and 2007, setup creates a routing group connector between one of 2003 routing group and one of exchange 2007 server.
Now here goes my question:
I have exchange 2003 org scattered across multiple geographical locations. Each location is a routing group and I have multiple servers in each location. When I am installing exchange 2007, it asked for creating routing group connector to allow mail flow between 2003<=>2007. I created it and pointed it to one of the routing group and started moving mailboxes(don't worry about remaining components configuration; everything is done). As I am doing the mailbox movement in parallel in all sites, when a E2k3 user is trying to send a mail from A site to a E2k7 user in of the same site, the mail to going to site B(where routing group connector is configured) E2k3 server and from there it is going to site B E2k7 server(through connector) and from there flowing to E2k7 server in site A. This is increasing the mail delivery time even if the both sender and recipient are in same LAN.
Now, please let me know if there is any option to setup connectors such that mails from E2k3 <-> E2k7 of same site will get delivered directly without reaching site B where I have configured first routing group connector. I guess this is very general requirement when large organizations are in transition from E2k3 to E2k7. Please let me know if I am not clear,