Rolling Exchange Migration
Exchange migration is a complex task that can take a long period of time. Because migration is performed in the production environment, it needs to be as transparent as possible to the end users.
A rolling Exchange migration strategy allows you to gradually collapse migrated Exchange servers and, at the same time, provide coexistence between Exchange organizations.
This strategy is useful if you need to reuse current production Exchange server hardware in the new Exchange environment. It is also useful if you must remove the administrative overhead and cost of supporting the source Exchange servers that no longer host active mailboxes by gradually decommissioning the source Exchange environment and its hardware.
Rolling Exchange migration requires more planning regarding decommissioning activities, the directory cleanup process, etc., as compared to the standard Exchange migration scenario outlined in the Basic Migration Steps topic.
If you need to decommission migrated production Exchange servers and re-use the freed-up hardware in the new Exchange environment, contact Quest Professional Services for a custom migration scenario designed for your specific environment.
Source Directory Preparation
Handling Disabled and Inactive Accounts
Migration Manager can automatically filter out disabled accounts during migration. We recommend you use this option and not bring disabled accounts to Active Directory.
You might also want to filter out user accounts that have not been logged on to for a long period of time and disable them prior to migration. To locate such accounts, use the following reports in Quest Reporter:
- Accounts that have never logged on – Displays user accounts that have never logged on
- Inactive Accounts – Shows all accounts that are disabled or deemed inactive during the time period you specify
Handling Accounts with Duplicate Names
There may be user accounts already created in the target Active Directory domain with the same names as the source accounts. If object matching by name is turned on for the domain pair (the rule is turned on by default), Migration Manager considers two objects to be duplicates if the source object’s SAMAccountName is equal to the target’s SAMAccountName.
Although Migration Manager reports on duplicate accounts during the migration session and allows you rename, merge, or skip them on the fly, the best practice is to handle duplicates before migration. You should find duplicate user and group names and determine which accounts belong to the same person and which do not. If two accounts, source and target, have the same name and belong to the same person, they should be merged during migration. If not, you should either rename one of them or skip them during migration.
To find duplicate user and group names, use the Duplicate Users and Duplicate Groups reports from Quest Reporter.
Third-party Applications
You should check your source environment for all business-critical third-party applications, such as ERP systems, fax software, and meta-directory services. These applications should be deployed in the test lab first and properly tested before you start migration in the production environment. Refer to the Test the Third-party Applications subsection.
Exchange Clusters
Migration Manager supports multi-node clusters running multiple Exchange Virtual Servers. Migration Manager detects such systems and configures agent services for automatic failover together with the Exchange services.
|
|
NOTE: By default, the QMMExNode$ and the QMMEx$<ExchangeServerName>$ shares have the same path. Otherwise, to be able to install the agents on the active node using the Install Agents Wizard take the following steps:
Bring the QMMEx$<ExchangeServerName>$ resource online. |
However, if several Exchange virtual servers are running on a single cluster node, the agents can be installed and run only on one Exchange virtual server at a time. Thus, such Exchange servers can only participate in migration with Migration Manager consecutively, one by one.
There are also some Exchange virtual server limitations on clusters that have more than two nodes. Refer to Microsoft Knowledge Base article 329208, “XADM: Exchange Virtual Server Limitations on Exchange 2000 Clusters and Exchange 2003 Clusters That Have More than Two Nodes,” at http://support.microsoft.com/default.aspx?scid=kb;en-us;329208.
Migration Manager fully supports Exchange 2007 Cluster Continuous Replication (CCR). Migration Manager detects such systems and configures agent services for automatic failover together with the Exchange services.
The rest two types of Exchange 2007 Continuous Replication that are Standby Continuous Replication (SCR) and Local Continuous Replication (LCR) are also supported, but in case of failover a full resynchronization of all mailboxes, calendars and public folders involved in the migration must be performed.