How does Quest Migration Manager migrate mail to Exchange 2007 CCR clusters? (4328276)

How does Quest Migration Manager migrate mail to Exchange 2007 CCR clusters?  What happens if the cluster fails over during a migration?

This article applies to versions of QMM starting from 8.3

Installation:

In previous versions of Quest Migration Manager, cluster installation was initiated via the Microsoft clustering API.  With the release of QMM 8.3, this method has been changed to use the Windows API (WMI) for Win2003/2008, while Win2000 installations still use an older method with Microsoft clustering API.  This offers an easier method to deploy agents to Microsoft Exchange 2007 cluster servers and now supports the installation of agents on a Windows 2008 Operating System.  With this new method, Exchange 2007 cluster servers are handled just as any other Exchange server.  When the CCR cluster is selected within QMM, the API installs all agents and directories to both nodes of the CCR cluster -active and passive.

The new in QMM agents logic:

QMM supports both scenarios where CCR cluster resides on the source or target.  If QMM agent runs on CCR cluster (it could be MSA, NTA or MTA), it now needs to perform some additional activities like coordination of PRV files copies between cluster nodes and synchronization of agents configuration databases.  These activities are explained in more details below.

Source Agent - creating PST/PRV files:

Normally during mail and public folder processing the data is extracted from the object whether it is a mailbox or public folder and placed within a .PST file.  This .PST file is then compressed into a .PRV file and moved to the NTA\OUT\<target server name> folder transmission folder.  However in the case of a target CCR cluster there will be two sub-directories present representing each node of the cluster: NTA\OUT\<NODE1> and NTA\OUT\<NODE2>.  If source is CCR cluster, PRV file is placed on the passive node first - then on the active node.

Transmission Agent -moving PRV files:

The transmission agent holds a listing of servers with configured pairs within its local database.  It will monitor the OUT folder on the source server for files approximately every 1 minute.  When new files are present they are copied to the target Exchange server under the following path: NTA\IN\<Source Server Name> or NTA\IN\<Virtual Server Name> if the source server is CCR cluster.  If target server is a CCR cluster, the container will be copied to the corresponding target nodes though the path \\TargetNodeName\QMMEXNode$ and not through the normal \\ServerName\QMMex$ServerName$ path for non-clustered servers.

If the source server being processed is a CCR cluster, after a successful copying of files to the target, the transmission agent will first try to delete the copy of the source file from the passive node container of the source server.  Only after a successful deletion will it be deleted on the currently active node (where the agent is running).  If the deletion failed on the passive node for some reason, the path to this PST container will be placed into the table DeletedDataFiles within the config.mdb file. The DeletedDataFiles table is explained below:

After each successfully processed mail or public folder file, an attempt by the processing agent is made to delete the .PRV file from the passive node.  If this process fails, the path to the .PST container will be placed within the DeletedDataFiles table of the transmission agents config.mdb database.  If the process is successful in deleting the file on the passive node, an attempt will be made to delete the file on the currently active node where the agent is running.  If this process fails, the path will also be added to the DeletedDataFiles table.  If after all of the above completes successfully, only then will the files be deleted from the active node.

When the transmission agent starts it will attempt to delete all files which exist in the table DeletedDataFiles.  If a file is successfully deleted, the corresponding record will be deleted from the table. If the deletion fails it will be kept, and processed again later.  The retention time for these records is configured within the config.ini file.  There are two new properties which control this process.

CcrDeletedItemsLifeTime life time of records in this table (Default 1 day).  Once expiring of this time the records will be deleted.

CcrDeletedItemsTouchInterval frequency of attempts to delete files. (Default 1 hour)

Target Agent - processing PST/PRV files:

Upon successful processing of every PRV file while running on CCR cluster, MTA deletes the corresponding copy from the passive node.  The logic is the same as with DeletedDataFiles table described above.

Replication of agents databases between CCR nodes:

Whenever agent runs on CCR cluster, it needs to replicate its configuration databases between CCR nodes.  This replication has to occur in the beginning of every session and also after processing of each item.  If during normal processing of items on a CCR cluster the agent fails to replicate database between nodes, it enters sleep mode and then attempts the replication again during normal sleep cycle.  This behavior can be modified by placing the following string within the config.ini:

ContinueWithoutReplication=1

This setting will make the agent continue processing files and wait until the end of the session to attempt a synchronization of the databases.  It should be used in cases where one of the CCR cluster nodes goes off line in the middle of synchronization and cannot be brought back on line in the timely manner.  Please note - this parameter does not entirely disable CCR logic on the Mail Target Agent.

Remember that any manual changes to agents CONFIG.INI files such as those suggested above will be overwritten when a Commit Changes or Agent Configuration update are performed from the QMM console.  To apply this change for all agents:

1. From the Migration Manager console, under the Exchange Data tab, select Tools | Options.

2. Highlight the Additional parameters for agents configuration files.  If this is not available, you can make this visible by opening regedit and navigating to HKLM\SOFTWARE\Aelita\Migration Manager\CurrentVersion\Exchange Data\ and creating the following Value:

Name: ShowAdditionalParameters
Type: DWORD
Value: 1

If the console is on a 64-bit system then the registry would be HKLM\SOFTWARE\WOW6432Node\Aelita\Migration Manager\Current Version\Exchange Data

3. Click Add and enter the corresponding parameter name, for example ContinueWithoutReplication with a value of1.

4. Under Apply to, Select Agent Configuration and corresponding agent or All Agents, then click OK.  This will update all config.ini files to reflect the change.