Deployment Blockers for Upgrading to Exchange Server 2007

Executive Summary: Avoid the gotchas and ensure a successful upgrade. You’ll need to be clear on AD topology, and then deal with deployment issues with public folders, client software, archival and retention, fax, mobility, and coexistence with other Exchange versions.

In a perfect world, IT upgrades would happen automatically and seamlessly—without any human intervention. Despite the effort Microsoft put into building Microsoft Exchange Server 2007, it still can’t perform an upgrade for you; that’s something that you’ll have to do yourself.  But when you take on an upgrade you can smooth the way by understanding and dealing with potential deployment blockers, such as Active Directory (AD) infrastructure, public folders, client software, archival and retention, fax, mobility, and coexistence in a mixed Exchange world.

Active Directory and Exchange 2007 Upgrades
AD topology is the biggest aspect of your environment to consider. There are five scenarios to keep in mind when you choose a topology for your upgraded environment:

• One forest. In this scenario, a single AD forest contains Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 servers, and you install Exchange 2007 into it. This is the simplest scenario, because you simply install your Exchange 2007 servers and move mailboxes to them.
• Cross-forest. In this scenario, an existing cross-forest AD infrastructure contains previous versions of Exchange and you want to retain multiple forests.
• One forest to cross-forest. This is more complicated than the preceding configurations because it calls for deploying Exchange 2007 in one forest and keeping your existing Exchange infrastructure in its separate forest. This scenario lets you build a completely new forest for your new Exchange deployment, but introduces lots of subtle complexities related to cross-forest Exchange management. If you go this route, I suggest that you read the Exchange 2007 documentation from Microsoft, which has a great deal to say about how to synchronize the global address lists between two forests and how to make Exchange work properly in this environment.
• Resource forest. In this scenario, you’ve deployed a previous version of Exchange  using a resource forest, and you plan to keep the resource forest and replace (or augment) your existing Exchange servers with new Exchange 2007 servers. This is almost as easy as the one-forest scenario; you can install Exchange 2007 servers in your dedicated Exchange forest and move mailboxes to them.
• Single forest to resource forest. This is the most complicated scenario because it requires you to set up a resource forest for Exchange 2007 (which in turn, implies adding a forest for user accounts too), then create a cross-forest relationship between the old and new forests. This scenario is pretty rare, fortunately, but organizations that need it usually need it badly because of legal or regulatory requirements that force them to a multi-forest design.

Keep a few additional caveats in mind. First, after you create an Exchange 2007 organization by installing into a virgin forest, you can’t install older versions into that organization. You’re free to install Exchange 2007 servers into your Exchange 2000 or Exchange 2003 environments (with the proper schema updates). Second, remember that all Exchange 2007 servers will be in their own routing group and their own administrative group. Don’t move them, and don’t move older servers into the Exchange 2007 groups. Third, if you’re using more than one routing group, you’ll need to disable link state routing updates as detailed in the Exchange 2007documentation. . . .