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, (more than likely) you’ll have to build up 2 CAS/2010 servers in the Exchange 2010 environment, etc).

Overall, the sequence for a migration from Exchange 2007 to Exchange 2010 is as follows:

Upgrade all Exchange Servers to Exchange Server 2007 Service Pack 2.
Bring the AD forest and domains to Windows Server 2003 Functional (or higher) levels.
Upgrade at least one Global Catalog domain controller in each AD Site that will house Exchange Server to Windows Server 2003 SP2 or greater.
Prepare a Windows Server 2008 (RTM or R2) x64 edition server for the first Exchange 2010 server.
Install the AD LDIFDE tools on the new Exchange 2010 server (to upgrade the schema).
Install any necessary prerequisites (WWW for CAS server role).
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.)
Install CAS server role servers and configure per 2010 design. Validate function-ality.
Transfer OWA, ActiveSync, and Outlook Anywhere traffic to new CAS servers.
Install Hub Transport role and configure per 2010 design.
Transfer inbound and outbound mail traffic to the 2010 HT servers.
Install Mailbox servers and configure Databases (DAG if needed).
Create public folder replicas on Exchange 2010 servers using AddReplicatoPFRe-cursive.ps1or Exchange 2010 Public Folder tool.
Move mailboxes to Exchange 2010 using Move Mailbox Wizard or Powershell.
Rehome the Offline Address Book (OAB) generation server to Exchange Server 2010.
Transfer all Public Folder Replicas to Exchange Server 2010 Public folder store(s).
Delete Public and Private Information Stores from Exchange 2007 server(s).
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.  If you’re interested in having our firm perform an Exchange migration, please contact us today.


Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Microsoft

Azure AD and Manual UPN Update

In Azure AD, the UserPrincipalName (UPN) can be manually updated using Set-MsolUserPrincipalName Power Shell cmdlet.  The details and syntax are explained here – https://msdn.microsoft.com/en-us/library/azure/dn194135.aspx One of the common issues you experience during this process is Read more…

Microsoft

Azure Password Reset – The Password you’ve selected does not meet your Active Directory password policy

This is a common error message when you try to reset a password from Azure management port or Self service portal.  The error message is very clear here – “The Password you’ve selected does not Read more…

Microsoft

Azure – Your account is temporarily locked to prevent unauthorized use

Here is the another common error message when dealing with directory and password synchronization.  Error Message: Your account is temporarily locked to prevent unauthorized use. Try again later. Contact Customer Support if the problem persists Read more…