Migrating from Exchange 2007 to Exchange 2010

Best Practices in Moving from Exchange 2007 to Exchange 2010

In my last blog post I covered the migration process from Exchange 2003 to Exchange 2010.  In this post, I’m going to outline the sequence and provide tips, tricks, and best practices to look forward to in the migration process from Exchange 2007 to Exchange 2010.

Since Exchange 2010 is similar if not almost identical to Exchange 2007 in terms of server roles (CAS, Hub Transport, Mailbox, Edge), if you implemented Exchange 2007 in a manner that suits the needs of your organization, then your transition to Exchange 2010 will be pretty straight forward.  Effectively, you would add Exchange 2010 server roles to mirror the Exchange 2007 server roles you have today (ie: if you have 2 CAS/2007 servers today, you’d likely build up 2 CAS/2010 servers in the Exchange 2010 environment, etc).

The sequence for a migration from Exchange 2007 to Exchange 2010 is as follows:

  1. Upgrade all Exchange Servers to Exchange Server 2007 Service Pack 2.

  2. Bring the AD forest and domains to Windows Server 2003 Functional (or higher) levels.

  3. Upgrade at least one Global Catalog domain controller in each AD Site that will house Exchange Server to Windows Server 2003 SP2 or greater.

  4. Prepare a Windows Server 2008 (RTM or R2) x64 edition server for the first Exchange 2010 server.

  5. Install the AD LDIFDE tools on the new Exchange 2010 server (to upgrade the schema).

  6. Install any necessary prerequisites (WWW for CAS server role).

  7. Run setup on the Exchange 2010 server, upgrade the schema, and prepare the forest and domains. (Setup runs all in one step or separate at the command line.)

  8. Install CAS server role servers and configure per 2010 design. Validate function-ality.

  9. Transfer OWA, ActiveSync, and Outlook Anywhere traffic to new CAS servers.

  10. Install Hub Transport role and configure per 2010 design.

  11. Transfer inbound and outbound mail traffic to the 2010 HT servers.

  12. Install Mailbox servers and configure Databases (DAG if needed).

  13. Create public folder replicas on Exchange 2010 servers using AddReplicatoPFRe-cursive.ps1or Exchange 2010 Public Folder tool.

  14. Move mailboxes to Exchange 2010 using Move Mailbox Wizard or Powershell.

  15. Rehome the Offline Address Book (OAB) generation server to Exchange Server 2010.

  16. Transfer all Public Folder Replicas to Exchange Server 2010 Public folder store(s).

  17. Delete Public and Private Information Stores from Exchange 2007 server(s).

  18. Uninstall all Exchange 2007 servers.

One of the areas of change that you’ll make with your transition to Exchange 2010 that is different than in your Exchange 2007 implementation is the high availability and disaster recovery functions of your Mailbox server role.  Because the concepts of Single Copy Clusters, Cluster Continous Replication (CCR), and Standby Continous Replicaton (SCR) no longer exist in Exchange 2010, you’ll be transitioning your mailboxes off of Exchange 2007 that has these functions to Exchange 2010 that users Database Availability Groups (DAGs).  Of course if you are just migrating to a single Exchange 2010 Mailbox server with no high availability or disaster recovery, then you will just have mailbox databases that you’ll be moving your mailboxes to.  However for organizations implementing high availability and disaster recovery, the DAGs provide replication of mail (of up 16 copies) from server to server.  When you setup your Exchange 2010 Mailbox servers to prepare them for the transition of mailboxes, setup your DAG replication and test your failover and failback of Exchange 2010 Mailbox servers, and then move your mailboxes to the DAG(s).

Another area of change between Exchange 2007 and Exchange 2010 is that ALL client connections go through the CAS server(s).  Unlike Exchange 2007 and prior where OWA connections went through the CAS server but Outlook (2003/2007) connections actually communicated directly over MAPI to the backend Mailbox servers.  However with Exchange 2010, client systems no longer communicate directly to the backend Mailbox servers.  Instead, the client MAPI connections hit the CAS server(s) that then communicate with the Mailbox servers on the backend.  So just like in the shift to Hub Transport servers in Exchange 2007 where all mail routes through the Hub Transport servers (incoming mail, outgoing mail, user to user mail between servers, and even user to user mail between users on the same server), with Exchange 2010, all clients go through the CAS server(s).  As such, the CAS servers take on more of a performance load and need to be beefed up a little.  Our recommendations for CAS to Mailbox in Exchange 2007 was 1 CAS servers for every 2 Mailbox servers.  For Exchange 2010, our recommendation is now 3 CAS servers for every 4 Mailbox servers.  Most organizations have at least 2 CAS servers in their environment for redundancy, and because you can virtualize the CAS role plus have 2000, 3000, even 5000 mailboxes on a single Mailbox server, we typically find this 3:4 CAS:MBX ratio hasn’t been a showstopper for organizations in terms of a design change.

Also important to note is that all 2007 server roles (CAS, Hub Transport, Mailbox) in Exchange 2007 need to remain until all users are migrated to Exchange 2010.  Exchange 2010 CAS, Hub Transport, and Mailbox servers are not backwards compatible with Exchange 2007, so in order for a user to access Outlook Web Access on Exchange 2007, they need to still hit the Exchange 2007 CAS servers to access their mailbox on the Exchange 2007 Mailbox server.  After their mailbox is migrated to Exchange 2010, then the user will hit the Exchange 2010 CAS server and access their mailbox on the Exchange 2010 Mailbox server.  Because Exchange 2010 has a proxy service on the CAS server, your external URL for OWA can point to the Exchange 2010 CAS server and if the user’s mailbox is still on Exchange 2007, the CAS/2010 server will automatically redirect the client connection to the CAS/2007 server for OWA.

Lastly, after moving mailboxes off of Exchange 2007 to Exchange 2010, leave the Exchange 2007 infrastructure in place for a couple (2) weeks.  By leaving the old Exchange 2007 server(s) in place, when an Outlook client tries to connect to the old Exchange 2007 server for its mail, the old Exchange 2007 server will notify the Outlook client software that the user’s mail has been moved to the Exchange 2010 server and will automatically update the user’s Outlook profile with the new destination server information.  Thereafter, when the Outlook client is launched, Outlook will access the user’s mailbox on the new Exchange 2010 server.  By leaving the old Exchange 2007 infrastructure in place for a couple weeks, pretty much all of your users will launch Outlook to have the profile automatically changed thus requiring no client system intervention during the migration process.  The only users you will likely need to manually reset their Outlook profile are users who are on extended leave and had not accessed their Outlook mail during the 2 week time that you had the Exchange 2007 environment still in place.

Hopefully these steps are helping in providing you guidance in your migration from Exchange 2007 to Exchange 2010.  I cover the migration process in much more detail (including specific steps and step by step processes for cutting over CAS, Hub Transport, and Mailbox server roles) in my book “Exchange 2010 Unleashed” from Sams Publishing.  The book was written from 2-yrs of early adopter experience working with Exchange 2010 and will hopefully provide more detailed guidance on the migration process from Exchange 2007 to Exchange 2010.

I’ve been ask to blog information about the new Hub Transport “Shadow Redundancy” process that provides fault tolerance to the routing of mail through Hub Transport servers, as well as I’ve been asked to blog about the new Exchange 2010 Unified Messaging (voicemail), so I’ll put together my thoughts on those areas upcoming…


Copyright © 2009 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022