Converse agora com nosso suporte
Chat com o suporte

Binary Tree Migrator for Notes 20.11 - User Guide for Office 365

Section 1. Introduction Section 2. Pre-migration Activities Section 3. User Provisioning Section 4. Email Repliability Section 5. Migrating Mail Files Section 6. Rooms and Resources Database Migration Section 7. Mail-in Database Migration Section 8. Setting Migration Status Section 9. Access and Delegation Migration Section 10. All Accounts Section 11. Customer Status Reports Section 12. Logs Appendix A: Staging Replicas Appendix B: Pre-Migration Troubleshooting Appendix C: Work with Files (Import/Export) Appendix D: Item Processing Results Appendix E: Migration Result Statuses Appendix F: Recovery Process Appendix G: Automatic Migration Restart Appendix H: Folder Processing Order Third Party Components

Recovery to PST

The Migrator for Notes migration engine has been enhanced to track the status of processed messages during migration to help recover failed migrations.

If a critical failure occurs in the migration engine, the migration process can terminate unexpectedly. The user status must be reported in Notes Migrator.nsf as “Migration terminated abnormally.” After correcting the cause of the failure, the new recovery feature allows Migrator for Notes users to restart migrating to an Exchange mail store or to a PST file from the point of crash. It prevents the application from reprocessing messages that were migrated during the initial run of the migration and moves to the next message in the message store without attempting to reprocess the message that caused the failure.

In addition, this feature also allows Migrator for Notes users to restart the migration on a secondary workstation if the first workstation is now busy after the original failed status.

This section outlines the common reasons for a failed migration and recovery processes for each possible scenario and provides a background to the implementation and usage of this new feature.

Implementation and Feature Functionality

By default, this feature is enabled in the Enable Recovery setting in the Advanced tab of the migration profile used on each migration workstation. With this setting enabled, during each migration, the migration engine generates a text file, CMTUProcessedNoteIDs-[username].txt, in the temp directory. This .txt file contains all the NoteIDs processed during the migration. If a crash occurs causing the migration to fail, the last entry in the .txt file is the NoteID that caused the failure. If the migration is successful, this file is deleted during cleanup.

A migration workstation, when it first starts and between user migrations, checks the temp directory (typically c:\windows\temp\) for any existing CMTUProcessedNoteIDs-[Username].txt file(s). If a file is found, the migration workstation uploads the list of NoteIDs from the file into the migrated messages table in Migrator for Notes before starting the migration. This updates the Migrator for Notes migrated message table for the failed migration, then processes the pending queue as normal. This allows any migration workstation to run follow-up migrations.

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:

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running. If the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, then verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. 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:

    1. 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

    2. Once moved, go to the Preparation -> Advanced view, and select the user

    3. Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu

    4. From the dialog box, select either the same workstation that originally processed the user or a new one

  15. 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

  16. 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.

  17. 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

Recovery to Exchange

Recovery from a migration failure to a Microsoft Exchange mailbox is a very simple process whether you are recovering from the original workstation or a secondary one as long as the original AWD farm is utilized.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down menu

  5. Open the AWD migration workstation where the original migration failed

  6. Right- click on the Notes Migrator Worker App icon located on the Task Bar, then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running: if the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the Migration Workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation or a new workstation to continue the migration process where it left off; refer to step 14 in the General Recovery procedure for more details on this step

  15. Monitor the migration as needed

  16. 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

Recovery from a PST migration is no different from the above process except that it involves a PST rather than the Exchange message store. The following process is the preferred method for recovery from a failed PST migration because it assumes the same workstation is being utilized at the time of restart as was during the original run.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation to continue the migration process where it left off; perform the following procedure to select the original workstation for migration:

    1. 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

    2. Once moved, go to the Preparation -> Advanced view, and select the user

    3. Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu

    4. From the dialog box, select the workstation that originally processed the user

  15. Monitor the migration as needed

  16. 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

Recovery to PST using secondary AWD Workstation

As in the previous process, the recovery from a PST migration is no different from any other except for the location of the PST file. Either it must be centrally located (shared drive) for all workstations to update or the PST must be copied to the AWD Migration Workstation where the processing is designated to restart. This method is used when the original workstation is busy with other migrations.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down men

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may also shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select a new workstation to continue the migration process where it left off; refer to step 14 in the General Recovery procedure for more details on this step

  15. When 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 will be created and you may end up with two PSTs, which is not desirable

  16. Monitor the migration as needed.

  17. 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

Recovery to PST using Manual Processes

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right- click on the Notes Migrator Worker App icon located on the Task Bar, then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may also shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation or a new workstation to continue the migration process where it left off; Refer to step 14 in the General Recovery procedure for more details on this step

  15. 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, which is not desirable

  16. Monitor the migration as needed

  17. 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

Recovery to PST using secondary AWD Workstation

The Migrator for Notes migration engine has been enhanced to track the status of processed messages during migration to help recover failed migrations.

If a critical failure occurs in the migration engine, the migration process can terminate unexpectedly. The user status must be reported in Notes Migrator.nsf as “Migration terminated abnormally.” After correcting the cause of the failure, the new recovery feature allows Migrator for Notes users to restart migrating to an Exchange mail store or to a PST file from the point of crash. It prevents the application from reprocessing messages that were migrated during the initial run of the migration and moves to the next message in the message store without attempting to reprocess the message that caused the failure.

In addition, this feature also allows Migrator for Notes users to restart the migration on a secondary workstation if the first workstation is now busy after the original failed status.

This section outlines the common reasons for a failed migration and recovery processes for each possible scenario and provides a background to the implementation and usage of this new feature.

Implementation and Feature Functionality

By default, this feature is enabled in the Enable Recovery setting in the Advanced tab of the migration profile used on each migration workstation. With this setting enabled, during each migration, the migration engine generates a text file, CMTUProcessedNoteIDs-[username].txt, in the temp directory. This .txt file contains all the NoteIDs processed during the migration. If a crash occurs causing the migration to fail, the last entry in the .txt file is the NoteID that caused the failure. If the migration is successful, this file is deleted during cleanup.

A migration workstation, when it first starts and between user migrations, checks the temp directory (typically c:\windows\temp\) for any existing CMTUProcessedNoteIDs-[Username].txt file(s). If a file is found, the migration workstation uploads the list of NoteIDs from the file into the migrated messages table in Migrator for Notes before starting the migration. This updates the Migrator for Notes migrated message table for the failed migration, then processes the pending queue as normal. This allows any migration workstation to run follow-up migrations.

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:

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running. If the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, then verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. 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:

    1. 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

    2. Once moved, go to the Preparation -> Advanced view, and select the user

    3. Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu

    4. From the dialog box, select either the same workstation that originally processed the user or a new one

  15. 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

  16. 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.

  17. 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

Recovery to Exchange

Recovery from a migration failure to a Microsoft Exchange mailbox is a very simple process whether you are recovering from the original workstation or a secondary one as long as the original AWD farm is utilized.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down menu

  5. Open the AWD migration workstation where the original migration failed

  6. Right- click on the Notes Migrator Worker App icon located on the Task Bar, then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running: if the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the Migration Workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation or a new workstation to continue the migration process where it left off; refer to step 14 in the General Recovery procedure for more details on this step

  15. Monitor the migration as needed

  16. 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

Recovery to PST

Recovery from a PST migration is no different from the above process except that it involves a PST rather than the Exchange message store. The following process is the preferred method for recovery from a failed PST migration because it assumes the same workstation is being utilized at the time of restart as was during the original run.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation to continue the migration process where it left off; perform the following procedure to select the original workstation for migration:

    1. 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

    2. Once moved, go to the Preparation -> Advanced view, and select the user

    3. Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu

    4. From the dialog box, select the workstation that originally processed the user

  15. Monitor the migration as needed

  16. 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

As in the previous process, the recovery from a PST migration is no different from any other except for the location of the PST file. Either it must be centrally located (shared drive) for all workstations to update or the PST must be copied to the AWD Migration Workstation where the processing is designated to restart. This method is used when the original workstation is busy with other migrations.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down men

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may also shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select a new workstation to continue the migration process where it left off; refer to step 14 in the General Recovery procedure for more details on this step

  15. When 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 will be created and you may end up with two PSTs, which is not desirable

  16. Monitor the migration as needed.

  17. 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

Recovery to PST using Manual Processes

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right- click on the Notes Migrator Worker App icon located on the Task Bar, then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may also shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation or a new workstation to continue the migration process where it left off; Refer to step 14 in the General Recovery procedure for more details on this step

  15. 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, which is not desirable

  16. Monitor the migration as needed

  17. 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

Recovery to PST using Manual Processes

The Migrator for Notes migration engine has been enhanced to track the status of processed messages during migration to help recover failed migrations.

If a critical failure occurs in the migration engine, the migration process can terminate unexpectedly. The user status must be reported in Notes Migrator.nsf as “Migration terminated abnormally.” After correcting the cause of the failure, the new recovery feature allows Migrator for Notes users to restart migrating to an Exchange mail store or to a PST file from the point of crash. It prevents the application from reprocessing messages that were migrated during the initial run of the migration and moves to the next message in the message store without attempting to reprocess the message that caused the failure.

In addition, this feature also allows Migrator for Notes users to restart the migration on a secondary workstation if the first workstation is now busy after the original failed status.

This section outlines the common reasons for a failed migration and recovery processes for each possible scenario and provides a background to the implementation and usage of this new feature.

Implementation and Feature Functionality

By default, this feature is enabled in the Enable Recovery setting in the Advanced tab of the migration profile used on each migration workstation. With this setting enabled, during each migration, the migration engine generates a text file, CMTUProcessedNoteIDs-[username].txt, in the temp directory. This .txt file contains all the NoteIDs processed during the migration. If a crash occurs causing the migration to fail, the last entry in the .txt file is the NoteID that caused the failure. If the migration is successful, this file is deleted during cleanup.

A migration workstation, when it first starts and between user migrations, checks the temp directory (typically c:\windows\temp\) for any existing CMTUProcessedNoteIDs-[Username].txt file(s). If a file is found, the migration workstation uploads the list of NoteIDs from the file into the migrated messages table in Migrator for Notes before starting the migration. This updates the Migrator for Notes migrated message table for the failed migration, then processes the pending queue as normal. This allows any migration workstation to run follow-up migrations.

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:

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running. If the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, then verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. 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:

    1. 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

    2. Once moved, go to the Preparation -> Advanced view, and select the user

    3. Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu

    4. From the dialog box, select either the same workstation that originally processed the user or a new one

  15. 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

  16. 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.

  17. 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

Recovery to Exchange

Recovery from a migration failure to a Microsoft Exchange mailbox is a very simple process whether you are recovering from the original workstation or a secondary one as long as the original AWD farm is utilized.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down menu

  5. Open the AWD migration workstation where the original migration failed

  6. Right- click on the Notes Migrator Worker App icon located on the Task Bar, then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running: if the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the Migration Workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view. Select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation or a new workstation to continue the migration process where it left off; refer to step 14 in the General Recovery procedure for more details on this step

  15. Monitor the migration as needed

  16. 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

Recovery to PST

Recovery from a PST migration is no different from the above process except that it involves a PST rather than the Exchange message store. The following process is the preferred method for recovery from a failed PST migration because it assumes the same workstation is being utilized at the time of restart as was during the original run.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane, and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation to continue the migration process where it left off; perform the following procedure to select the original workstation for migration:

    1. 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

    2. Once moved, go to the Preparation -> Advanced view, and select the user

    3. Click the Set Migration Status button and select the Set Migration Workstation option from the drop-down menu

    4. From the dialog box, select the workstation that originally processed the user

  15. Monitor the migration as needed

  16. 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

Recovery to PST using secondary AWD Workstation

As in the previous process, the recovery from a PST migration is no different from any other except for the location of the PST file. Either it must be centrally located (shared drive) for all workstations to update or the PST must be copied to the AWD Migration Workstation where the processing is designated to restart. This method is used when the original workstation is busy with other migrations.

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down men

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right-click on the Notes Migrator Worker App icon located on the Task Bar, and then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may also shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify that the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select a new workstation to continue the migration process where it left off; refer to step 14 in the General Recovery procedure for more details on this step

  15. When 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 will be created and you may end up with two PSTs, which is not desirable

  16. Monitor the migration as needed.

  17. 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

  1. Open Migrator for Notes on the Migration Control Center where the migration failed

  2. Under Mail File Migration, expand Migration and click Advanced

  3. Select the user in the Data Pane whose migration failed

  4. Click the Clear or Reset User(s) button in the Data Pane and select Reset User(s) from the drop-down menu

  5. Open the AWD Migration Workstation where the original migration failed

  6. Right- click on the Notes Migrator Worker App icon located on the Task Bar, then select Exit Now to shut down the service:

  7. Right-click on the Windows Bar, then select Task Manager

  8. Close the Outlook.exe process if still running; if the CMTProxy.exe process is still running, you may also shut it down

  9. (Optional) You may restart or log-off the workstation to avoid steps 6 – 8

  10. If you restarted, verify the original workstation has restarted and the Notes Migrator Worker App is running again

  11. Go back to the Migration Control Center

  12. Select Migrate in the Mail File Migration -> Migration view; select the user(s) to be migrated in the Data Pane

  13. Select the same profile as previously used for this migration

  14. Select the original workstation or a new workstation to continue the migration process where it left off; Refer to step 14 in the General Recovery procedure for more details on this step

  15. 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, which is not desirable

  16. Monitor the migration as needed

  17. 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

Appendix G: Automatic Migration Restart

Overview

Automatic Migration Restart is a process by which any abnormal termination of the Migrator for Notes engine (commonly referred to as a ‘crash’) is identified, and the migration job is automatically re-queued.  If this occurs, the migration is restarted and resumed on the next document in the message store, until either the migration completes process the message store, or the maximum number of retries has been exceeded.

Automatic Migration Restart works in conjunction with the existing migration recovery features in Migrator for Notes to resume a migration on the next document immediately after the document which caused the crash. 

Terminology

This following table lists and describes the terms commonly used when describing the automatic restart process:

Term

Description

Migrator for Notes

Migrator for Notes application environment, encompassing the server instance

Job

A migration event within the context of Migrator for Notes, each migration job is a unique event

Migration server

Refers to the system running the Migrator for Notes web services. This is the primary instance where the web server and CMT Monitor are installed

Migrator for Notes Database (or Notes Migrator.nsf)

Used for configuring settings, managing user records, and queuing users to the migration server

Migration worker

An instance of the CMT_MigrationWorker.exe application running on a migration workstation; this application runs continuously on the migration workstation, polls the migration server for pending migration jobs, and initializes an instance of the migration engine (CMTProxy.exe) for each migration job

Migration engine (or CMTProxy)

An instance of CMTProxy.exe, which is initialized and managed by the Migration worker; CMTProxy.exe performs the actual data migration

Crash

Abnormal termination of the migration engine, resulting in a status of “Migration terminated abnormally”

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 the MaximumRetryCount 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.

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.

 


The migrated message table is not used if the Discover History from Migrated Data option is used. In this case, the previously processed messages are read from the Exchange Mailbox directly.

Detecting abnormal termination of a migration

The Notes Migrator Worker application can detect a migration crash. When the Notes Migrator Worker application starts a migration job, it launches the migration by calling CMTProxy.exe in a separate process.  While the migration is running, the Notes Migrator 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). 

Summary

In this section, we have reviewed how the Notes Migrator Migration Worker application detects a crash of the migration engine, how the Migrator for Notes server processes the “Migration Terminated Abnormally” status and requeues the job if necessary, and ultimately how the migration automatically restarts on the same workstation.

In this manner, the Automatic Restart process in Migrator for Notes allows migration administrators to queue jobs to the migration server and know that if a crash were to occur the migration will automatically be restarted without intervention up to the maximum number of times indicated by the MaximumRetryCount parameter.  This feature reduces the amount of resources required to monitor Migrator for Notes migrations and eliminates the need for administrator intervention in the case where the migration engine has crashed.

Again, it should be noted that the HCL Notes application interface (Notes Migrator.nsf) will report the last migration status for the user.  Any automatic restart events will be evident in the complete migration history but will not be reflected directly in the interface.  In the case where the maximum restart count has been exceeded, the last migration event will be reported as “Migration terminated abnormally.”

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação