Migrator for Notes Worker Basics
The Notes Migrator 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 Notes Migrator 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 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 Migrator for Notes 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 server for work, triggering a migration job when required, updating the Migration 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 can detect a migration crash. 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. |
Automatic re-queue of a migration job
The sections above describe how the Notes Migrator Worker application identifies a crash in the migration engine and returns “Migration terminated abnormally” status. This section describes how the Migrator for Notes server re-queues the user and resulting migration status values.
If the migration worker application returns a value of “Migration terminated abnormally” or one of the RetryJobStatus codes to the Migrator for Notes server, the migration server determines if the RetryCount exceeds the MaximumRetryCount configured for the server.
-
If the RetryCount is less than the MaximumRetryCount, the job is re-queued by creating a new migration job in the migration queue. This job will be a high-priority job queued for the specific workstation, ensuring that it is the next job processed by that workstation.
-
If the RetryCount for a particular migration is greater or equal to the MaximumRetryCount, the migration will be left in “Migration terminated abnormally” status or the last job status. This allows the migration administrator to determine which migrations have exceeded the maximum allowable number of automatic restarts and indicates that the file will need additional remediation before resetting and remigrating the user. It should be noted that the migration server will contain a history (in the form of a migrated message table) corresponding to all of the data that has been migrated up to that point. After remediation, the migration administrator can simply reset and requeue the user to continue the migration from this point, or clear previously migrated data and clear the migrated message table to restart the migration from the beginning.
-
If a migration has been automatically restarted by this process, the Notes Migrator.nsf database will only show the status of the last migration that was restarted. Consider the situation where a migration crashed, was automatically restarted, and continued to completion without further errors. The migration status in the Migrator for Notes Database will report “Migration completed successfully” even though there was a crash on the initial run. The migration history will indicate the first migration completed with a status of “Migration terminated abnormally” status, but this may not be evident in the Notes Migrator.nsf HCL Notes application interface. Advanced or customized installations of the HCL Notes application may retrieve and summarize the complete migration history for a user, but a complete migration history is not included in the default Notes Migrator.nsf application interface.
The RetryJobStatus parameter is a string list of semicolon delimited codes that will automatically be resubmitted if the job returns with that specific status code. By default, Migrator for Notes will resubmit memory exception codes #001 (Notes memory exception) and #002 (Outlook memory exception).