You should never begin an Exchange Server 2010 deployment until you’ve confirmed that you can meet Microsoft’s prerequisites. You’ll need sufficient hardware to run Exchange Server 2010 (at least 4 GB to 8 GB of RAM is recommended), Windows Server 2008 or Windows Server 2008 R2 and machines configured to handle the required directory server roles.
A useful tool to download and run while you’re still preparing to deploy Exchange Server 2010 is the Exchange Pre-Deployment Analyzer, which examines the environment in which you’re planning to install Exchange Server 2010 and alerts you to any existing problems with the network topology.
Microsoft’s Exchange Server Deployment Assistant is another useful tool. It queries you for information about your existing Exchange Server setup and generates a checklist of things to do and watch for in the new environment, which is especially helpful if you’re running a mixed architecture of Exchange Server 2003 and Exchange 2007, for example. Running the latest Microsoft Baseline Security Analyzer prior to rolling out a migration project to determine if there are any outstanding security issues in your organization is also beneficial.
One major prerequisite for adding Exchange Server 2010 to an organization is to prepare the Active Directory schema to accommodate Exchange. If you’re upgrading from Exchange 2003 to Exchange Server 2010, part of the process includes configuring legacy permissions to ensure that Exchange 2003’s Recipient Update Service (RUS) will still work properly.
With the release of Exchange Server 2010, all changes across all three of the most recent versions of Exchange are being tracked in a single document called Active Directory Schema Changes Reference.
And you can’t mention Active Directory without discussing the Microsoft Active Directory Topology Diagrammer, which can read your current AD topology and produce a Visio diagram from it. The only drawback of this tool is that you need Visio 2003 or higher.
Tricks to an Exchange 2010 Upgrade
Upgrading an existing Exchange infrastructure is one of the most common scenarios—and also one of the trickiest. For example, the process of upgrading to Exchange Server 2010 might defy common sense about how systems are upgraded.
• In-place upgrades. You can’t perform an “in-place
upgrade” of Exchange Server 2007 to Exchange Server 2010. Instead, you must install Exchange Server
2010 in parallel, on a different system and then migrate the data to the new servers. Upgrades to
Exchange Server 2007 had that same restriction, so experienced Exchange administrators will already
be familiar with it. In the long run, this restriction actually helps. You can leave your existing
Exchange installation untouched and the new setup coexists with it until you choose to decommission
• No backward migration. Exchange Server 2010 does not support adding an earlier version of Exchange into an existing Exchange Server 2010 organization. According to Microsoft, if you create a new forest in which to install Exchange Server 2010, you can’t add earlier versions of Exchange at a later time. If you plan to keep an earlier version of Exchange around for backward compatibility, building your new Exchange infrastructure in parallel allows you to do that. But it also means you must think ahead and not pull the plug on your legacy Exchange setup until you’re sure that it’s no longer needed. Remember, too, that you cannot set up Exchange Server 2010 to coexist with any version of Exchange prior to Exchange Server 2003. And you earlier versions of Exchange Server must be running in native mode, not mixed mode, before deploying Exchange 2010.
• Third-party products. Another major area to consider before attempting a migration is what third-party products you will use in conjunction with Exchange 2010. This decision isn’t just about whether or not the product will work with Exchange 2010, but also whether the product’s functionality is native to the new server version. For example, a third-party backup product may not be necessary since Exchange Server 2010 includes database availability groups.
• Deprecated APIs. Exchange Web-based Distributed Authoring and Versioning is being replaced in Exchange Server 2010 with Exchange Web Services or the EWS Managed API. This change mostly affects third-party applications that use WebDAV or custom-written, in-house programs. If you can’t replace affected applications immediately, one workaround is to maintain an Exchange Server 2007 server for mailboxes that are managed by WebDAV-based applications.
The Store Events APIs, CDOEX and ExOLEDB APIs have been removed from Exchange 2010 and were replaced by Exchange Web Services. In the future, a few other APIs, such as the Exchange Server MAPI Client and Collaboration Data Objects, will be moved to “extended support” status.
This was first published in December 2010