How to migrate from Exchange 2007 CCR to Exchange 2010 DAG on existing hardware
If you are currently running an Exchange Server 2007 Organization with high availability configuration in a Cluster Continuous Replication Setup and you are planning to upgrade to Exchange Server 2010 SP1, you are often considering a way to move without changing your hardware. The reason for this might be that the hardware is only 1-2 years old or has been leased for five years.
In these series of articles we will discuss the way to move to Exchange 2010 SP1 DAG (Database Availability Group) setup without having to buy new hardware. The plan implicates that you are losing high availability over a short period of time but if you are planning the migration on a straight-forward project, the time window you are running with no high availability can be calculated and is quite short.
As one of the first steps before you start your project plan to move to Exchange 2010 SP1 you should check if your existing hardware is suitable for Windows Server 2008 R2. In general one of the preparation steps is to flash your servers ROM to the newest available release to make sure that Windows Server 2008 R2 is supported.
After being successful with your hardware compatibility the next step is to update your Exchange Server 2007 environment to be prepared for Exchange Server 2010 SP1. The easiest way to do this is updating your current messaging infrastructure (all servers in your Exchange Server 2007 environment) to Exchange Server 2007 SP3. The way to update is starting on your servers with the Client Access Role, moving to those ones that hold the Hub Transport Role and finally moving to the Mailbox Server Role.
Also you need to make sure to update your CCR environment as described below in order to make everything work properly after the update.
Updating Exchange Server 2007 CCR to Service Pack 3
Basically Exchange Server 2007 supports rolling Service Pack Updates, you only need to make sure that you are always upgrading the passive cluster node.
The straight forward method can be run as follows:
1. Move all cluster resource group to Node A
2. Stop performance counter Services and System Center Operations Manager Services (if installed)
3. Restart the Remote Registry Service
4. Open a Command prompt and navigate to the Exchange Server 2007 SP3 installation files logged on as Exchange Organization administrative Group member
5. Run the following command:
6. Restart Node B after Setup has completed
7. After having finished the passive Node B is running SP3
8. Now you need to run the Stop-ClusteredMailboxServer cmdlet to stop the clustered mailbox server using the following syntax:
Stop-ClusteredMailboxServer -StopReason “Upgrade to SP2”
9. Now we need to move the clustered mailbox server to Node B using
-MoveComment “Upgrade to SP2”
10. At a Command Prompt navigate to the Exchange 2007 SP3 installation files
11. Run the following command to upgrade your CCR Cluster:
12. Setup upgrades the CCR server and brings it back online again
13. Now we need to stop any services that have open handles to performance counters and System Center Operations Manager Service on Node A
14. Restart the Remote Registry service
15. Open a Command Prompt and then navigate to the Exchange 2007 SP3 installation files
16. Run the following command on Node A to upgrade it to Exchange 2007 SP3:
17. Restart Node A to finish the upgrade to Exchange Server 2007 SP3 completely
18. Use Exchange Best Practice Analyzer to check whether further configuration changes need to be done before the update
Update Active Directory Schema to Exchange Server 2010 SP1
As a next step we will need to import the Exchange Server 2010 SP1 schema to your Windows Server 2008 based Active Directory environment.
The easiest way to do this is as follows:
1. Logon as member of the Active Directory Groups of Enterprise Administrators and Schema Administrators on one of your existing Exchange Servers.
2. At first we need to make sure that non Exchange Server 2007 or 2010 servers can run properly in the new security model:
setup /PrepareLegacyExchangePermissions or setup /pl
If no Exchange Server 2003 or earlier versions are part of your Exchange Organization you can successfully skip this command.
3. Afterwards we need to import the new schema entries to your Active Directory Schema Master using this command:
setup /PrepareSchema or setup /ps
4. Now we need to automatically create some security groups and further settings for Exchange Server 2010 SP1:
setup /PrepareAD or setup /p
5. Finally we need to make sure that all security groups are properly filled in using:
setup /PrepareAllDomains or setup /pad
The easiest way is to run this properly for all existing domains in one step. If you do not want to do this, you can run
setup /PrepareDomain or setup /pd
After having finished this procedure you should make sure that Active Directory replication took place and has finished successfully. You can check this using the Event Log on your Domain Controllers.
Decommissioning your passive Exchange Server 2007 SP3 Node
Now after having finished all necessary steps we can start over with the migration to Exchange Server 2010 SP1 DAG by decommissioning your passive Exchange Server 2007 SP3 node. When starting this task, you will lose redundancy temporary.
The steps for this procedure are as follows:
1. Make sure that all Databases are running on the active node
2. Move responsibility of OAB-Generation to the active node
3. Uninstall Exchange Server 2007 SP3 from your passive cluster node using:
4. Evict the formerly passive node from Failover Clustering
5. Disjoin the machine from Active Directory and shutdown the computer
Finally we have finished freeing up server hardware to prepare the rollout of Exchange Server 2010 SP1 on this machine in the future.
After having discussed the way to prepare the Exchange Server 2010 Service Pack 1 deployment in your Exchange 2007 CCR based deployment in the first part of this article, we now need to discuss how to go on with further steps and finish the deployment.
Install Exchange 2010 Mailbox Server Role
At first we need to install Windows Server 2008 R2 on the former Exchange Server 2007 server. After this we will install Exchange Server 2010 SP1 with the following roles on the machine:
• Mailbox Server Role
• Client Access Server Role
• Hub Transport Role
The roles “Client Access” and “Hub Transport” need to be moved after the decommissioning of the Exchange 2007 server environment. Then the existing Hub Transport and Client Access servers based on Exchange Server 2007 are not needed anymore and can be removed from the organization.
Configure Client Access and Hub Transport
To make sure that the new mailbox server can be contacted from the clients and that routing is impossible, we now need to transfer the Exchange 2007 Client Access and Hub Transport Server configuration to their Exchange Server 2010 pendant.
After having all mailboxes moved from Exchange 2007 to Exchange 2010 SP1 to Exchange Server 2007 including the internal Exchange mailboxes, we can uninstall the last Exchange 2007 Mailbox CCR node and finally uninstall the existing Exchange Servers with the Client Access Role and the Hub Transport role.
This means we now have a native Exchange 2010 Service Pack 1 Organization, but need to make sure that no fragments of Exchange Server 2007 are left in Active Directory. This can be done by manually researching the “Configuration Partition” of Active Directory for entries that include the old Exchange Server 2007 names. Before deleting them manually, which is the only way to get rid of them, you should create a System State Backup of the Server to have a roll back if things are missing because of having deleted false entries.
Installing the second DAG member
After a clean installation of Windows Server 2008 R2 Enterprise Edition on the formerly existing Exchange 2007 box, we need to install Exchange Server 2010 SP1 Mailbox Server Role in the corresponding version that already exists as the first Exchange 2010 Server.
Now we need to join this server to the existing DAG, this can be done quite easily using the DAG container in the Organization Configuration of the Exchange Server 2010 System Manager. Afterwards, we need to prepare the most time consuming task of creating the mailbox database copies from DAG Server 1 to DAG Server 2. Depending on the size of the mailboxes and the server and network performance this tasks may take from some hours to some days. You may find out that there are some databases in your Environment that do not have proper database states. If this is the case, you will need to check this using the well-known recovery tasks of Exchange. In the case the database copy task of some mailboxes does not finish successfully, you have a way to copy the database files, log files and checkpoint files manually from one server to another with stopped Exchange Information Store services on the source Exchange Server.
Transferring the Client Access and Hub Transport Server Role
After decommissioning the last Exchange 2007 mailbox server, we do not need the Hub Transport and Client Access Server anymore. So we can uninstall and reinstall them with Windows Server 2008 R2 and the corresponding Exchange Server 2010 server roles. Due to the configuration lives in Active Directory, we only have to transfer some of the settings to the new role members. Now, having Exchange Server 2010 based dedicated Hub Transport and Client Access Server roles, we need to uninstall the hub transport and client access server role from the first DAG member, where it has been installed for the migration time.
Finalizing the deployment
Finally you should check every connector and configuration for entries that point to the old servers. You should delete these entries as to get rid of them totally.
After a successful integration of the second DAG member, you should define a time window when you check if high availability is working properly, this means the following tasks should then be checked:
1. Active Directory Replication took place properly.
2. One database goes to shutdown state è this should result in switching over to the passive Database node copy.
3. The database goes online again è this should result in do not creating a fall back solution, because this is by-design.