Corrupt Views:
Common Failure Types
Before restarting a failed migration, you must first examine the migration status of the user and log files from the failed migration to determine the cause of the failure. If the cause of the failure is corrupted views or database design elements, restarting the migration will not help. The migration will continue to fail until the problem is resolved and the recovery process will not allow the migration to continue past the point of failure.
If the cause of the failure is a failed physical attribute that needs correcting, then provided below are the four most common types of physical attribute failures with their corresponding example log files, and possible resolutions.
Cannot Open Mail File: “Migration initialization failed”
If the mail file does not exist at the specified location, or the migration account does not have access to the mail file, Migrator for Notes reports a status of “Migration initialization failed.” This status can appear if either the source or destination server is unavailable, or if the migration account does not have access to the message store. Regardless of the number of attempts made, this type of problem cannot be successful until it is resolved. If the log file records a similar message as the following example, “Unable to open mail file CN=SERVERNAME/OU=MS/OU=SVR/O=ONE!!mail6\harr0156,” either the mail file is not present or there is an ECL alert on the workstation that is running that user. In case of ECL alerts, click through them until they stop appearing.
Corrupt Tables:
When the log file records the following statement “NSFDbGetModifiedNoteTable returned 'No documents have been modified since specified time.' while getting Note IDs of folders to process”, the tables in the mail template are corrupt. To fix this, the common practice is to create a new copy of the mail file, then replace the database design.
|
|
When you create a copy or a replica of the mail file to correct corrupt tables, you must remember that the recovery log does not work as expected with the copy or the replica. This is because all the documents in the mail file now have new NoteIDs. So, when you restart the migration, all the documents in the mail file are migrated and you will end up with duplicates. To resolve this, when you restart the migration, you must treat it as a complete redo of that user’s mail file migration, and clear the contents of the user's Exchange mailbox before proceeding. |
Corrupt Views:
When the log file contains a statement like the one shown right before the summary “Error: NSFNoteOpen returned 'You are not authorized to perform that operation' opening view note”, some of the views in the mail template are corrupt, and you need to create a new copy of the mail file, then replace design as instructed above.
Notes Crash:
If there is a critical error in the HCL Notes client, the user’s status must be reported as “Migration Terminated Abnormally.” The can also be verified by viewing the migration log: the log file’s last statement will show this “3/2/2009 10:05:17 PM Migration preformed on workstation na svr20 workstation 1.” To resume migration, restart the migration worker application on the Migration Workstation that is stated at the end of the log, then reset the user in Migrator for Notes and migrate again. Users in this status can be restarted and the migration will be successful.
This type of crash can be easily identified if the log file does not contain a summary of the events before ending the log with the statement “Migration performed on workstation…”. In such a case, if you restart the migration with recovery enabled, the migration is allowed to continue past the point of failure. However, if the log ends without the “Migration performed on workstation…” statement, then when you restart the migration, you will need to ensure that the migration is processed by the same workstation (that processed it earlier at the time of crash) to ensure that it properly resumes from the point of failure.
Notes Crash:
Common Failure Types
Before restarting a failed migration, you must first examine the migration status of the user and log files from the failed migration to determine the cause of the failure. If the cause of the failure is corrupted views or database design elements, restarting the migration will not help. The migration will continue to fail until the problem is resolved and the recovery process will not allow the migration to continue past the point of failure.
If the cause of the failure is a failed physical attribute that needs correcting, then provided below are the four most common types of physical attribute failures with their corresponding example log files, and possible resolutions.
Cannot Open Mail File: “Migration initialization failed”
If the mail file does not exist at the specified location, or the migration account does not have access to the mail file, Migrator for Notes reports a status of “Migration initialization failed.” This status can appear if either the source or destination server is unavailable, or if the migration account does not have access to the message store. Regardless of the number of attempts made, this type of problem cannot be successful until it is resolved. If the log file records a similar message as the following example, “Unable to open mail file CN=SERVERNAME/OU=MS/OU=SVR/O=ONE!!mail6\harr0156,” either the mail file is not present or there is an ECL alert on the workstation that is running that user. In case of ECL alerts, click through them until they stop appearing.
Corrupt Tables:
When the log file records the following statement “NSFDbGetModifiedNoteTable returned 'No documents have been modified since specified time.' while getting Note IDs of folders to process”, the tables in the mail template are corrupt. To fix this, the common practice is to create a new copy of the mail file, then replace the database design.
|
|
When you create a copy or a replica of the mail file to correct corrupt tables, you must remember that the recovery log does not work as expected with the copy or the replica. This is because all the documents in the mail file now have new NoteIDs. So, when you restart the migration, all the documents in the mail file are migrated and you will end up with duplicates. To resolve this, when you restart the migration, you must treat it as a complete redo of that user’s mail file migration, and clear the contents of the user's Exchange mailbox before proceeding. |
Corrupt Views:
When the log file contains a statement like the one shown right before the summary “Error: NSFNoteOpen returned 'You are not authorized to perform that operation' opening view note”, some of the views in the mail template are corrupt, and you need to create a new copy of the mail file, then replace design as instructed above.
Notes Crash:
If there is a critical error in the HCL Notes client, the user’s status must be reported as “Migration Terminated Abnormally.” The can also be verified by viewing the migration log: the log file’s last statement will show this “3/2/2009 10:05:17 PM Migration preformed on workstation na svr20 workstation 1.” To resume migration, restart the migration worker application on the Migration Workstation that is stated at the end of the log, then reset the user in Migrator for Notes and migrate again. Users in this status can be restarted and the migration will be successful.
This type of crash can be easily identified if the log file does not contain a summary of the events before ending the log with the statement “Migration performed on workstation…”. In such a case, if you restart the migration with recovery enabled, the migration is allowed to continue past the point of failure. However, if the log ends without the “Migration performed on workstation…” statement, then when you restart the migration, you will need to ensure that the migration is processed by the same workstation (that processed it earlier at the time of crash) to ensure that it properly resumes from the point of failure.
General Recovery
If a crash condition does occur, then the following procedures should be followed to recover from the failed migration. A failed status in Migrator for Notes will appear as illustrated in the image below.
Depending on the reason why the migration failed, the status may also be set to Migration Cancelled, in which case the same procedure should be followed to recover the migration. As stated earlier, a recovery can be executed on the Migration Control Center or on one of the AWD (Automated Workload Distribution) Migration Workstations within the original set or farm. The following sections outline the procedures for recovery for all scenarios.
General Recovery Process:
-
Open Migrator for Notes on the Migration Control Center where the migration failed
-
Under Mail File Migration, expand Migration and click Advanced
-
Select the user in the Data Pane whose migration failed
-
Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu
-
Open the AWD Migration Workstation where the original migration failed
-
Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:
-
Right-click on the Windows Bar, then select Task Manager
-
Close the Outlook.exe process if still running. If the CMTProxy.exe process is still running, you may shut it down
-
(Optional) You may restart or log-off the workstation to avoid steps 6 – 8
-
If you restarted, then verify that the original workstation has restarted and the Notes Migrator Worker App is running again
-
Go back to the Migration Control Center
-
Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane
-
Select the same profile as previously used for this migration
-
Select the original workstation or a new workstation to continue the migration process where it left off. AWD assigns a migration workstation when a new migration job is queued, and it may or may not be the original workstation where the crash occurred, but if you want to specify a specific workstation to perform the migration, then you can follow the procedure given below:
-
Select the user in the Migrate view, click the Change to… button, and select any one of the options to bring the user to the Preparation view
-
Once moved, go to the Preparation -> Advanced view, and select the user
-
Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu
-
From the dialog box, select either the same workstation that originally processed the user or a new one
-
-
If migrating to PST, make sure the file is available to the workstation now running the process; if it is not available, then a new PST is created and you may end up with two PSTs; this may not be desirable
-
Monitor the migration as needed; to recover a failed migration, when you restart a migration, it does not start right from the last message that was migrated. It, in fact, processes every message again just like the first time; however, the recovery table and the migration history allow Migrator for Notes to skip everything that was previously migrated. Therefore, the first part of the migration proceeds through all the folders and messages very quickly until it reaches the point where it previously failed, then it slows down as it starts moving data again.
-
The migration should complete with a status of Migrated Successfully unless it encounters a new error, in which case follow the same process to recover
The final sections will cover each variant within this procedure so you may gain a better understanding of how the feature operates with respect to your migration project
General Recovery Process:
General Recovery
If a crash condition does occur, then the following procedures should be followed to recover from the failed migration. A failed status in Migrator for Notes will appear as illustrated in the image below.
Depending on the reason why the migration failed, the status may also be set to Migration Cancelled, in which case the same procedure should be followed to recover the migration. As stated earlier, a recovery can be executed on the Migration Control Center or on one of the AWD (Automated Workload Distribution) Migration Workstations within the original set or farm. The following sections outline the procedures for recovery for all scenarios.
-
Open Migrator for Notes on the Migration Control Center where the migration failed
-
Under Mail File Migration, expand Migration and click Advanced
-
Select the user in the Data Pane whose migration failed
-
Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu
-
Open the AWD Migration Workstation where the original migration failed
-
Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:
-
Right-click on the Windows Bar, then select Task Manager
-
Close the Outlook.exe process if still running. If the CMTProxy.exe process is still running, you may shut it down
-
(Optional) You may restart or log-off the workstation to avoid steps 6 – 8
-
If you restarted, then verify that the original workstation has restarted and the Notes Migrator Worker App is running again
-
Go back to the Migration Control Center
-
Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane
-
Select the same profile as previously used for this migration
-
Select the original workstation or a new workstation to continue the migration process where it left off. AWD assigns a migration workstation when a new migration job is queued, and it may or may not be the original workstation where the crash occurred, but if you want to specify a specific workstation to perform the migration, then you can follow the procedure given below:
-
Select the user in the Migrate view, click the Change to… button, and select any one of the options to bring the user to the Preparation view
-
Once moved, go to the Preparation -> Advanced view, and select the user
-
Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu
-
From the dialog box, select either the same workstation that originally processed the user or a new one
-
-
If migrating to PST, make sure the file is available to the workstation now running the process; if it is not available, then a new PST is created and you may end up with two PSTs; this may not be desirable
-
Monitor the migration as needed; to recover a failed migration, when you restart a migration, it does not start right from the last message that was migrated. It, in fact, processes every message again just like the first time; however, the recovery table and the migration history allow Migrator for Notes to skip everything that was previously migrated. Therefore, the first part of the migration proceeds through all the folders and messages very quickly until it reaches the point where it previously failed, then it slows down as it starts moving data again.
-
The migration should complete with a status of Migrated Successfully unless it encounters a new error, in which case follow the same process to recover
The final sections will cover each variant within this procedure so you may gain a better understanding of how the feature operates with respect to your migration project