Configuring Automatic Restart
Automatic restart is controlled by a parameter in the Web.config file for the Migrator for Notes server. This file is located in [installDirectory]\CMT for Exchange\CMT_XMLServer\Web.config , for example “C:\Program Files (x86)\BinaryTree\CMT for Exchange\CMT_XMLServer\web.config”.
The Web.config file contains the startup parameters for the Migrator for Notes server. Located in this file is an \appSettings\MaximimumRetryCount XML node, which indicates the maximum number of times a migration will be automatically restarted.
<appSettings>
---snip ----
<add key="ScheduleTimerInterval" value="3"></add>
<add key="UseSQL" value="1"></add>
<add key="MaximumRetryCount" value="10"></add>
<add key="RetryJobStatus" value="#001;#002"></add>
</appSettings>
The MaximumRetryCount is set to 10 by default. A value of 0 or a negative number will disable the Automatic Restart functionality.
RetryJobStatus is set by default to resubmit if the #001 (Notes memory exception) or #002 (Outlook memory exception) job status code is returned.
|
|
If MaximumRetryCount or “RetryJobStatus” is changed or disabled, the Migrator for Notes server instance must be restarted for the change to take effect. This can be done by opening a command prompt on the migration server and typing “iisreset” at the prompt, or manually restarting the IIS service. |
|
|
Windows Error Reporting can prevent the Migration Worker from completing the Automatic Restart. This can be disabled on Windows using Disable-WindowsErrorReporting, for more information please refer to Microsoft Online Documentation for this functionality. |
Migrator for Notes Worker Basics
The Migrator for Notes Worker is an application that runs in the task bar of windows. This application is responsible for queuing, migrating, and updating the status of a migration job on the Migrator for Notes server.
The Migrator for Notes Worker has three basic states:
-
Offline – the migration worker is not started.
-
Online – the service is running, and actively checking for migration jobs
-
Migrating – a migration job is in progress.
When the Migration Worker application is online, the application periodically checks the Migrator for Notes server for pending migration jobs. If a job is available, the migration server passes back the job number from the migration queue, along with settings and user information required to start the migration. The worker then starts the migration by calling CMTProxy.exe as a separate process with the appropriate parameters, which begins the actual data migration. Once the migration starts, the migration worker application sends notification back to the Migrator for Notes server that the workstation is in Migrating status. During the course of the migration, the migration worker periodically communicates throughput and migration time statistics back to the migration server.
When the migration has completed, the Migration Worker updates the CMT server and then uploads the history of migrated messages and relevant log files.
The key concept is that the Migration Worker is responsible for checking the Migrator for Notes Control Center Server for work, triggering a migration job when required, updating the Migration Control Center Server during the migration, and finally uploading log files once the job has been completed.
Migrator for Notes Recovery Basics
During a migration, the Migrator for Notes engine reads and catalogs the unique identifier of each message it encounters before the message is processed. This identifier is stored in memory to prevent migrating a document multiple times, and is also immediately written to disk in a “ProcessedNoteID-username.txt’ file on disk, where username is the unique key of the user on the migration server.
In the event of a crash, the ProcessedNoteID file on disk contains the list of unique identifiers of each document processed during the failed migration. This file is read by the Migration Worker application, merged with any existing migrated message information residing on the server for the user, and stored back on the migration server prior to the next migration. This ensures that the migrated message table on the Migrator for Notes Server is up to date when the migration is restarted.
When the migration engine is restarted, the migrated message table is read and all previously processed messages (including the ID of the message that was being processed when the migration crashed) are skipped in subsequent runs. This allows Migrator for Notes to resume where it left off, and prevents re-migrating documents repeatedly on subsequent runs.
|
|
|
Detecting abnormal termination of a migration
The Migrator for Notes Worker application is a key component in detecting when a migration crashes. When the Migrator for Notes Worker application starts a migration job, it launches the migration by calling CMTProxy.exe in a separate process. While the migration is running, the Migrator for Notes Worker application periodically sends information back to the Migrator for Notes server indicating migration time and throughput for the current migration.
If the migration engine (CMTProxy.exe) crashes, the handle to the migration engine becomes invalid, and the Migration Worker application knows that the currently running migration has crashed. At this point, the Migration Worker reads the ProcessedNoteID table from the temporary directory, merges it with any existing information in the Migrated Message table on the Migrator for Notes server, and updates the status of the job to “Migration Terminated Abnormally.”
|
|
The Migration Worker does not actually re-queue the job, it reports only “Migration Terminated Abnormally” status back to the Migrator for Notes server. The Migrator for Notes server is responsible for determining if the job will be re-queued. |