As we get closer to the release date for Microsoft Exchange Server 2007, I notice that the questions readers ask are changing. To date, most of the questions have focused on features: "Is there a feature to do X?" "What does feature Y do?" This focus on features is understandable because most IT implementers want to know first what's new or different about a product, particularly when it's not widely available. However, people are now starting to apply what they know (or have heard) about Exchange 2007 to their own environments so they can figure out what they'll need to do for a successful deployment.
The simplest Exchange 2007 deployment starts with a "green field"—a deployment that puts Exchange into an infrastructure where it wasn't present before. Such deployments usually happen for one of three reasons: a company starts up (or starts using email); migrates from a non-Exchange system such as IBM Lotus Notes or Lotus Domino; or sets up a completely new Active Directory (AD) structure, often as part of a merger or acquisition. The deployment considerations for Exchange 2007 in these cases are pretty straightforward because there are no existing Exchange servers. However, when you install Exchange 2007 in a green-field environment, you can't later add Exchange 2003 servers to that same organization; Exchange Server 2003 ForestPrep adds security groups and other directory objects that aren't used in Exchange 2007 and aren't present when you initially deploy Exchange 2007.
A much more common deployment scenario is when an organization that uses Exchange 2003 or Exchange 2000 wants to upgrade to Exchange 2007. Microsoft has written plenty about this process, referred to as "transition." (For details about the transition process, see "Upgrading to Exchange 2007," https://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/a313c016-0e51-466e-a3de-953e1e0d347d.mspx?mfr=true.) Briefly, you install a new Exchange 2007 server and move existing mailboxes to it, rehoming public folders that you want to keep using and adjusting connectors whose endpoints have changed. If this scenario describes your organization, I recommend reading "Planning for Coexistence," http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/54c6e6d4-aa19-4d30-87b6-31a1ca018a3f.mspx, because it points out some important changes to the way Exchange 2007 works. For example,
- Exchange 2007 has only one administrative group; instead of moving objects to different administrative groups for delegation, you now delegate permissions directly to the rightful holders.
- Message routing is based on AD site topology, not on arbitrary routing groups (a long-overdue change, in my opinion!). As a result, you need to pay attention to your AD site topology to ensure that it reflects how you want messages routed.
- Link state routing has been replaced with an improved system that automatically balances traffic loads between Hub Transport servers in a site and uses the site link costs from AD to make routing decisions. You still need routing group connectors between your Exchange 2003 routing groups because Exchange 2007 doesn't propagate link state information through the X-LINK2STATE SMTP verb.
Of course, you should bear in mind that some Exchange 2007 features depend on combinations of server roles. For example, if your mailbox is on an Exchange 2003 server and you access it through an Exchange 2007 Client Access server, you get the Exchange 2003 version of Microsoft Outlook Web Access.
Next week I'll talk more about how role combinations work and what you can and can't do with them.
End of Article
Register
