You should never begin an Exchange Server 2010 upgrade 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 required directory server roles.
A useful tool to download and run before deploying Exchange Server 2010 is the 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 what to watch for in the new environment. This 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 before 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 to upgrade a system.
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 move data to the new servers. Upgrades to Exchange Server 2007 had that same restriction, so experienced Exchange administrators should already be familiar with this. In the long run, this restriction is actually helpful; you can leave your existing Exchange installation untouched and the new setup coexists with it until you choose to decommission it.
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 this 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 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 2007 server for mailboxes that are managed by WebDAV-based applications.
In Exchange 2010, Exchange Web Services (EWS ) replace Store Events APIs, CDOEX and ExOLEDB APIs. In the future, a few other APIs -- Exchange Server MAPI Client and Collaboration Data Objects -- will be moved to “extended support” status.
ABOUT THE AUTHOR:
Serdar Yegulalp has been writing about computers and IT for more than 15 years for a variety of publications, including SearchWinIT.com, SearchExchange.com, InformationWeek and Windows magazine.