The Migrator for Notes Settings document displays. In the Settings document, the Required Settings -> Domino tab displays by default.
|
You can view the description of each field in each tab by clicking its corresponding question mark icon |
Before any migration can be performed, the Required Settings tab must be completed. Two of the most important entries in this tab are the Mail Server and the Domino Directory. The specified Mail Server name is used to access the Domino Directory. The Domino Directory is used to retrieve the information required to import and create the User Mail, Rooms & Resources Databases, Mail-in Databases, and Discussion & Document Library Databases control documents.
These control documents are critical to the migration process and in their absence, migration information cannot be collected for a given item, and therefore, the item cannot be migrated. The control documents are used extensively during the remaining migration processes.
The following table describes the values for each setting.
Settings |
Description |
Mail Server |
The Domino server that Migrator for Notes will use for importing users and for sending Migration Messages. |
Domino Directory |
The Domino Directory name that Migrator for Notes will use for importing users, as found on the Domino server. Up to five additional Domino directories can be set by checking the box. |
Server Mailbox |
The mailbox filename that Migrator for Notes uses for sending Migration-related messages to selected users (for example, mail.box). |
Audit Domino Encrypted Items |
When running Audit on user mail file, specifying Yes will check for encrypted items in the mail file. If encrypted items are found, you can either send the user an email message with a button that decrypts encrypted items so that they can be migrated, or you can send the user a message with document links to the encrypted items so that they can print them prior to migration. You can even do both if you have some reason to want a list of messages that had been encrypted before the decryption agent was run. |
Audit Domino Mail Rules |
When running Audit on user mail file, specifying Yes will check for the number of rules in the mail file. If rules are found, you can send users a list of their Rules that will help them in creating the rules in Outlook after migration. |
Audit Exchange Migrated Data |
Enables auditing of migrated data in Exchange. Exchange Auditing should be enabled before data is migrated. Audit reports can be found the \logs directory on the migration workstation(s). This is a post-migration validation process that indicates the state of documents which have been migrated by Migrator for Notes. This feature can be useful in environments as a validation check for data integrity. In addition, this can be used to audit results to reduce the size of user Domino mail files or archive databases after the migration phase on the Domino servers and user's workstation replicas. For example, removing documents with a Migration Status of 1 would leave only non-migrated data or documents that could not be migrated completely due to malformation or size restrictions in Exchange from a source database. Important: Consult your organizations data retention policies and regulatory compliance requirements before modifying source data. Full backups of the original source data may be required (and maintained post migration) before modifying working replicas to ensure regulatory compliance. |
Audit embedded eml attachments |
Enables auditing of eml attachments inside the message bodies to assist with migration troubleshooting. Results will be reported on the user document in EMM. This is not required for migration processing unless directed to enable this by Binary Tree's Product Support. Additionally, a flag can be enabled and adds the field BTFoundEML to documents in source mail files where auditing finds eml attachments inside the message bodies. |
Audit calendar unsupported patterns |
Enables auditing of calendar items where the user is the Chair for Notes custom repeating meetings and generates document links for meetings that are not supported by Outlook. This will use the Migration Date if set or the current date and include meetings from the date specified and future meetings. The audit adds the reported data to the Calendar audit RTF report for the account and can be sent to end users with the Remediation Summary Message Template. If enabled the audit can be specified to verify meetings where the user is the Chair, an Invitee or both. Additionally, label text can be added to the reported data to specify if the user is the Chair or the Invitee. |
User Notification Style |
Individual Notifications: Select if you want to send individual notification to each user and each mail/form will only have script for one action.
Combined Notifications: Select if you want to send one migration notification to each user and the notification/message to contain multiple selected forms, such as decrypting encrypted messages and synchronizing contacts and journals (notebooks) with mail file. |
Enable this CMT db for Notifications |
Click this button to create a Mail-In database document on the Domino Server for the Migrator for Notes database, and enable the database to receive User Notification responses. This database must be hosted on a Domino server. |
A Mail-in Database Document is required for mail to be delivered to the newly created server copy of the Migrator for Notes database. The procedure copies the database to the server and creates a Mail-In database document for the Migrator for Notes database.
Create a mail-in database for Migrator for Notes database. Click on the Server Db Copy and Mail-In Db Doc button to create a copy of the Migrator for Notes database on the Domino server and configure the Mail in Database document
The Does Migrator for Notes already exist? dialog box opens; click Yes (and skip to step 5):
If you are working with a local copy of the Migrator for Notes database, then click No. The Create a db copy? dialog box opens.
Click Yes to create a copy of the local Migrator for Notes database on the server:
If you clicked Yes in the Does Migrator for Notes CMT already exist? dialog box, the Choose Application dialog box opens. Locate the Migrator for Notes database in the CMT folder on the server, and then click Open.
The process will ask if there is already a mail-in db document in the Domino directory. If this has been created already then click Yes to run a search for the entry in the directory. This is case sensitive for the Migrator for Notes application name on the Notes Migrator.nsf file. Click No to create a mail-in db document.
The Fullname for the mail-in db doc dialog box confirms that the mail-in database for the selected server-based Migrator for Notes database does not exist, and prompts you to specify a name for the mail-in database. After specifying the name, click OK.
In the Open the new mail-in doc? dialog box, click Yes to open the mail-in database.
The mail-in database document for Migrator for Notes opens.
To verify the creation of the mail-in database, you can also launch Domino Administrator, open the Domino server, and access the Mail-In Databases and Resources folder under the People & Groups tab:
Double-click the document to open and review
Once the mail-in database is successfully created, the Open Mail-In Db Doc button replaces the Server Db Copy and Mail-In Db Doc button. Clicking it opens the database document for a review. Clicking the button with the X sign on it will remove all pointers to the location of the mail-in database.
|
If you do not have the appropriate access rights to perform this action, see the onsite Domino System Administrator for help. |
It is recommended that after copying the database to the server, you delete the database from the local client folder. To remove it, right-click on Migrator for Notes on Local. Select Database, and then Delete. The Lotus Notes client prompts that the database and related documents will be permanently deleted. Click Yes to delete the local database.
Once you have mail-enabled the database, you need to modify the Inbound Processing agent to view the updates. Perform the following steps to run the agent.
Install Domino Designer on the workstation where Migrator for Notes Domino database is located
Launch Migrator for Notes Domino database in Domino Designer
Expand Shared Code and select Agents
Select the InboundProcessing agent as shown below:
Double-click InboundProcessing to open the InboundProcessing Agent Properties
Click the Security tab
The Administrator should be listed in the Run on behalf of section
In the Set Runtime security level: field, select Allow Restricted Operations with full administration rights
Once you've edited the agent, close the Properties box
Close the Inbound Processing – Agent tab
Save the changes
Click Sign
|
This agent runs before new mail arrives and the Domino router must be set to allow these types of agents to run. To enable this option, go to Router/SMTP -> Restrictions and Controls -> Delivery Controls tab and set the Pre-delivery agents option to Enabled. |
|
The Notes ID that signs this agent does require security rights on the Domino server to run agents. |
Click LDAP under the Required Settings tab:
In this tab, specify the Active Directory information to resolve users by matching them between source and destination platforms via Lightweight Directory Access Protocol (LDAP). To use this option, specify the required details.
|
LDAP configuration is not specifically required for Office 365 only migrations. |
Use the following table to enter the correct values for each field:
Settings |
Description |
Domain |
The common name of the Active Directory domain. For example, binarytree rather than binarytree.com. |
LDAP IP Address or Host Name |
The fully qualified LDAP server name, IP Address, or resolvable DNS name of the Active Directory server. (e.g. PC-XP-01. binarytree.com or 192.163.15.12). |
LDAP Port |
Specify the LDAP port. The default port for LDAP is 389. The default port for SSL LDAP is 636. |
Login ID |
The AD domain account that has read rights to the target AD domain. For example: administrator and not <domain>\administrator |
Password |
The password associated with the ID specified in Login ID. |
Validate Settings |
Click to validate the specified values to ensure that you are able to connect to the domain in Exchange where the end users will be eventually migrated. |
LDAP Directory Base (Base DN) |
If LDAP settings result in a successful connection, then this field is automatically updated. Specify the directory base for all LDAP queries. The query settings will enable the search in AD to ensure that users are getting resolved against the right container ‘directory’ within AD. Example: DC=btexchange2k7,DC=com |
Quick Check Full Check |
If you want to search only the first ten users, select Quick Check; and if you want to search all the users, select Full Check. |
Validate Query Settings |
Click to validate the values specified in LDAP Directory Base to ensure that query string is resolving users and returning the number of resolved users. |
Specify the connection settings and then validate them by clicking the Validate Settings button:
The LDAP Connection Settings Test Results message box displays indicating that the settings were validated and the connection was successful; click OK:
Notice that the LDAP Directory Base (Base DN) field is automatically populated
To ensure that the specified directory base, where all LDAP searches will be conducted, is correct; you should validate this setting as well; click the Validate Query Settings button:
The LDAP Query User Settings Test Results message box displays; the query setting is validated and some records are returned; in a production environment, ten records should be returned always; click OK:
Click the Additional tab under Required Settings
Configure these settings with the names of the views to locate and import User and Mail-in Databases information. Also, specify the Migration Status Codes that can be assigned to users’ mail and databases control documents. You can assign a code to a user to update its status and view users based on their status codes. This helps in providing a better picture of the migration progress.
The following table describes the values for each setting:
Settings |
Description |
---|---|
CMT Migration Server |
Specify the network hostname or IP address of the machine that is running the migration server. |
CMT Program Directory |
Specify the complete program directory path to Migrator for Notes installation. This location will be used to launch the migration engine when the migration is triggered off.
Note: During the installation of Migrator for Notes, if you had specified a destination folder path other than the default (C:\Program Files\Binary Tree\CMT Exchange), then you must replace the default path specified in the CMT Program Directory field with the modified path. In failing to do so, the migration engine will not launch when the migrations are set to go off. |
Use Secure Web Services |
Specify whether the web service calls are made to an XML server configured for secure access. Note that additional steps are required to secure the web services. The default selection is “Yes” which uses the CMT eService COM object to access the XML server.
Refer to Appendix D: Securing Migrator for Notes Web Services with Windows Authentication for additional steps if you select Yes. |
I have multiple control Centers |
This option appears if the multiple Migration Control Center advanced feature is enabled on the Other Setting tab. Check this option to define the IP addresses of the Control Centers. When enabled, the Set Migration Status options include Set Migration MCC and Clear Migration MCC options. |
Migration Server Control Center IPs |
Appears if “I have multiple control Centers” is checked. This field is used by the Set Migration Status agent. Values must be entered as follows: Workstation#=IP address of Migrator for Notes Control Center For example: 1=192.168.1.0 2=192.168.1.1 3=192.168.1.2 |
User Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing users. Use the People view unless there is a custom view that you have created. |
Mail-In Databases Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing mail-in databases and resources. Use the Mail-In Databases view unless there is a custom view that you have created. |
Mail-In Databases View Category |
This is the NAB Mail-In database view category used for importing Mail-in Databases and Resources. Use the “Databases” default unless Domino is using a language other than English. Change this value to what is displayed in the NAB Mail-in Databases view. |
Migration Status Codes |
Specify a personalized list of status codes that will be used during the migration project. These codes can be assigned to users’ mail and databases control documents. If these status codes are assigned during the different phases of the migration process, timely status reports can be produced. These status reports will help provide a better picture of the migration progress. With this type of information, you have more control over the migration project and can react quickly to any identified issue. Adjustments can be made to help fine tune the migration schedule by adding more or different resources. Status codes must be separated by a new line. A list of status codes has been specified for you. You can either retain or change these status codes depending on your need. |
CAS Server |
Specify the Exchange Client Access Server (CAS) name. If a name is specified, then the matching process will use the following URL to resolve users. https://[servername]/autodiscover/autodiscover.xml
However, if you have specified the full URL to the Autodiscover service, then the URL will be used to resolve users.
This field is required for delegation migrations. |
Username |
If only the CAS Server name or IP address is specified in the CAS Server field, then you must specify a valid username for the authentication process that takes place on the CAS server. Note that the username should be in the following format for on-premises Exchange: <domain>\<username>. For Office 365 the format should be username@domain.com.
If you have specified a full URL (with https://) in the CAS Server field, then you can leave this field blank for on-premise migrations. |
Password |
Specify the password associated with the username provided in the previous field.
If you specified a full URL (with https://), then you can leave this field blank for on-premise migrations. |
Powershell Admin Credentials |
For on-premise Exchange servers, the credentials are of the form [Domain]\[Username]. For Office 365, the credentials are the SMTP address used to pass credentials to Office365 for remote access, for example o365Admin@tenant.onmicrosoft.com |
Powershell Admin Password |
Use the Set PowerShell Password button to update this field. This will request the password and record it using the AsSecure PowerShell method. This is not required for clicking the Migrator for Notes PowerShell buttons, if this is not entered the buttons (such as Set Full Acccess) will ask for the password when processed. |
PowerShell Logging Path |
The MS PowerShell used when generating, executing, and logging PS1 script. This path can be edited on User Provisioning tab. |
Default Reporting Path for Matching |
Specify the reporting path used by the matching process. The default path is C:\Matching\. |
Enable PowerShell Modern Auth |
Set to Yes to enable the use of the Microsoft Graph and Exchange Online modules for PowerShell processing. This will use Modern Auth connectivity to Microsoft Online services, removing the Basic Auth connection processing. Review Appendix E Microsoft Graph Application ID for additional configuration that is required to use Modern Authentication with an Azure AD Application ID. |
Enable Modern Auth for Migration |
Set to Yes to enable the use of Modern Authentication for Migrations. The Office 365 tenant must be configured to use Modern Authentication. Note: PowerShell matching using Modern Auth must be enabled for Modern Auth migrations to online mailboxes or archives. |
Autodiscover Username |
Autodiscover credentials to be used during creation of the profile used by the migration engine. For on-premise Exchange servers, the credentials entered should be the UPN (User Principal Name), for example: UserName@Example.Microsoft.com For Office 365, the credentials are the SMTP address of an account in the Office 365 domain, for example: o365Admin@tenant.onmicrosoft.com.
Note: This is used if a migration worker does not have an account specified and is a fall back option. This is not required if a migration farm is being built using AWD. |
Autodiscover Password |
Enter the password associated with the Autodiscover account entered above. |
Customer Name |
Specify the Customer name that you would like in the status report. |
Send Customer Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the status report. |
Send Operator Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the full status report. |
Migration Status Report Path |
Specify the working path for migration status reports. |
Create a combined report for multiple Migration Management databases (up to 5 additional) |
Check this option to specify up to five additional migration management databases to include in a combined report. |
The Migrator for Notes Settings document displays. In the Settings document, the Required Settings -> Domino tab displays by default.
|
You can view the description of each field in each tab by clicking its corresponding question mark icon |
Before any migration can be performed, the Required Settings tab must be completed. Two of the most important entries in this tab are the Mail Server and the Domino Directory. The specified Mail Server name is used to access the Domino Directory. The Domino Directory is used to retrieve the information required to import and create the User Mail, Rooms & Resources Databases, Mail-in Databases, and Discussion & Document Library Databases control documents.
These control documents are critical to the migration process and in their absence, migration information cannot be collected for a given item, and therefore, the item cannot be migrated. The control documents are used extensively during the remaining migration processes.
The following table describes the values for each setting.
Settings |
Description |
Mail Server |
The Domino server that Migrator for Notes will use for importing users and for sending Migration Messages. |
Domino Directory |
The Domino Directory name that Migrator for Notes will use for importing users, as found on the Domino server. Up to five additional Domino directories can be set by checking the box. |
Server Mailbox |
The mailbox filename that Migrator for Notes uses for sending Migration-related messages to selected users (for example, mail.box). |
Audit Domino Encrypted Items |
When running Audit on user mail file, specifying Yes will check for encrypted items in the mail file. If encrypted items are found, you can either send the user an email message with a button that decrypts encrypted items so that they can be migrated, or you can send the user a message with document links to the encrypted items so that they can print them prior to migration. You can even do both if you have some reason to want a list of messages that had been encrypted before the decryption agent was run. |
Audit Domino Mail Rules |
When running Audit on user mail file, specifying Yes will check for the number of rules in the mail file. If rules are found, you can send users a list of their Rules that will help them in creating the rules in Outlook after migration. |
Audit Exchange Migrated Data |
Enables auditing of migrated data in Exchange. Exchange Auditing should be enabled before data is migrated. Audit reports can be found the \logs directory on the migration workstation(s). This is a post-migration validation process that indicates the state of documents which have been migrated by Migrator for Notes. This feature can be useful in environments as a validation check for data integrity. In addition, this can be used to audit results to reduce the size of user Domino mail files or archive databases after the migration phase on the Domino servers and user's workstation replicas. For example, removing documents with a Migration Status of 1 would leave only non-migrated data or documents that could not be migrated completely due to malformation or size restrictions in Exchange from a source database. Important: Consult your organizations data retention policies and regulatory compliance requirements before modifying source data. Full backups of the original source data may be required (and maintained post migration) before modifying working replicas to ensure regulatory compliance. |
Audit embedded eml attachments |
Enables auditing of eml attachments inside the message bodies to assist with migration troubleshooting. Results will be reported on the user document in EMM. This is not required for migration processing unless directed to enable this by Binary Tree's Product Support. Additionally, a flag can be enabled and adds the field BTFoundEML to documents in source mail files where auditing finds eml attachments inside the message bodies. |
Audit calendar unsupported patterns |
Enables auditing of calendar items where the user is the Chair for Notes custom repeating meetings and generates document links for meetings that are not supported by Outlook. This will use the Migration Date if set or the current date and include meetings from the date specified and future meetings. The audit adds the reported data to the Calendar audit RTF report for the account and can be sent to end users with the Remediation Summary Message Template. If enabled the audit can be specified to verify meetings where the user is the Chair, an Invitee or both. Additionally, label text can be added to the reported data to specify if the user is the Chair or the Invitee. |
User Notification Style |
Individual Notifications: Select if you want to send individual notification to each user and each mail/form will only have script for one action.
Combined Notifications: Select if you want to send one migration notification to each user and the notification/message to contain multiple selected forms, such as decrypting encrypted messages and synchronizing contacts and journals (notebooks) with mail file. |
Enable this CMT db for Notifications |
Click this button to create a Mail-In database document on the Domino Server for the Migrator for Notes database, and enable the database to receive User Notification responses. This database must be hosted on a Domino server. |
A Mail-in Database Document is required for mail to be delivered to the newly created server copy of the Migrator for Notes database. The procedure copies the database to the server and creates a Mail-In database document for the Migrator for Notes database.
Create a mail-in database for Migrator for Notes database. Click on the Server Db Copy and Mail-In Db Doc button to create a copy of the Migrator for Notes database on the Domino server and configure the Mail in Database document
The Does Migrator for Notes already exist? dialog box opens; click Yes (and skip to step 5):
If you are working with a local copy of the Migrator for Notes database, then click No. The Create a db copy? dialog box opens.
Click Yes to create a copy of the local Migrator for Notes database on the server:
If you clicked Yes in the Does Migrator for Notes CMT already exist? dialog box, the Choose Application dialog box opens. Locate the Migrator for Notes database in the CMT folder on the server, and then click Open.
The process will ask if there is already a mail-in db document in the Domino directory. If this has been created already then click Yes to run a search for the entry in the directory. This is case sensitive for the Migrator for Notes application name on the Notes Migrator.nsf file. Click No to create a mail-in db document.
The Fullname for the mail-in db doc dialog box confirms that the mail-in database for the selected server-based Migrator for Notes database does not exist, and prompts you to specify a name for the mail-in database. After specifying the name, click OK.
In the Open the new mail-in doc? dialog box, click Yes to open the mail-in database.
The mail-in database document for Migrator for Notes opens.
To verify the creation of the mail-in database, you can also launch Domino Administrator, open the Domino server, and access the Mail-In Databases and Resources folder under the People & Groups tab:
Double-click the document to open and review
Once the mail-in database is successfully created, the Open Mail-In Db Doc button replaces the Server Db Copy and Mail-In Db Doc button. Clicking it opens the database document for a review. Clicking the button with the X sign on it will remove all pointers to the location of the mail-in database.
|
If you do not have the appropriate access rights to perform this action, see the onsite Domino System Administrator for help. |
It is recommended that after copying the database to the server, you delete the database from the local client folder. To remove it, right-click on Migrator for Notes on Local. Select Database, and then Delete. The Lotus Notes client prompts that the database and related documents will be permanently deleted. Click Yes to delete the local database.
Once you have mail-enabled the database, you need to modify the Inbound Processing agent to view the updates. Perform the following steps to run the agent.
Install Domino Designer on the workstation where Migrator for Notes Domino database is located
Launch Migrator for Notes Domino database in Domino Designer
Expand Shared Code and select Agents
Select the InboundProcessing agent as shown below:
Double-click InboundProcessing to open the InboundProcessing Agent Properties
Click the Security tab
The Administrator should be listed in the Run on behalf of section
In the Set Runtime security level: field, select Allow Restricted Operations with full administration rights
Once you've edited the agent, close the Properties box
Close the Inbound Processing – Agent tab
Save the changes
Click Sign
|
This agent runs before new mail arrives and the Domino router must be set to allow these types of agents to run. To enable this option, go to Router/SMTP -> Restrictions and Controls -> Delivery Controls tab and set the Pre-delivery agents option to Enabled. |
|
The Notes ID that signs this agent does require security rights on the Domino server to run agents. |
Click LDAP under the Required Settings tab:
In this tab, specify the Active Directory information to resolve users by matching them between source and destination platforms via Lightweight Directory Access Protocol (LDAP). To use this option, specify the required details.
|
LDAP configuration is not specifically required for Office 365 only migrations. |
Use the following table to enter the correct values for each field:
Settings |
Description |
Domain |
The common name of the Active Directory domain. For example, binarytree rather than binarytree.com. |
LDAP IP Address or Host Name |
The fully qualified LDAP server name, IP Address, or resolvable DNS name of the Active Directory server. (e.g. PC-XP-01. binarytree.com or 192.163.15.12). |
LDAP Port |
Specify the LDAP port. The default port for LDAP is 389. The default port for SSL LDAP is 636. |
Login ID |
The AD domain account that has read rights to the target AD domain. For example: administrator and not <domain>\administrator |
Password |
The password associated with the ID specified in Login ID. |
Validate Settings |
Click to validate the specified values to ensure that you are able to connect to the domain in Exchange where the end users will be eventually migrated. |
LDAP Directory Base (Base DN) |
If LDAP settings result in a successful connection, then this field is automatically updated. Specify the directory base for all LDAP queries. The query settings will enable the search in AD to ensure that users are getting resolved against the right container ‘directory’ within AD. Example: DC=btexchange2k7,DC=com |
Quick Check Full Check |
If you want to search only the first ten users, select Quick Check; and if you want to search all the users, select Full Check. |
Validate Query Settings |
Click to validate the values specified in LDAP Directory Base to ensure that query string is resolving users and returning the number of resolved users. |
Specify the connection settings and then validate them by clicking the Validate Settings button:
The LDAP Connection Settings Test Results message box displays indicating that the settings were validated and the connection was successful; click OK:
Notice that the LDAP Directory Base (Base DN) field is automatically populated
To ensure that the specified directory base, where all LDAP searches will be conducted, is correct; you should validate this setting as well; click the Validate Query Settings button:
The LDAP Query User Settings Test Results message box displays; the query setting is validated and some records are returned; in a production environment, ten records should be returned always; click OK:
Click the Additional tab under Required Settings
Configure these settings with the names of the views to locate and import User and Mail-in Databases information. Also, specify the Migration Status Codes that can be assigned to users’ mail and databases control documents. You can assign a code to a user to update its status and view users based on their status codes. This helps in providing a better picture of the migration progress.
The following table describes the values for each setting:
Settings |
Description |
---|---|
CMT Migration Server |
Specify the network hostname or IP address of the machine that is running the migration server. |
CMT Program Directory |
Specify the complete program directory path to Migrator for Notes installation. This location will be used to launch the migration engine when the migration is triggered off.
Note: During the installation of Migrator for Notes, if you had specified a destination folder path other than the default (C:\Program Files\Binary Tree\CMT Exchange), then you must replace the default path specified in the CMT Program Directory field with the modified path. In failing to do so, the migration engine will not launch when the migrations are set to go off. |
Use Secure Web Services |
Specify whether the web service calls are made to an XML server configured for secure access. Note that additional steps are required to secure the web services. The default selection is “Yes” which uses the CMT eService COM object to access the XML server.
Refer to Appendix D: Securing Migrator for Notes Web Services with Windows Authentication for additional steps if you select Yes. |
I have multiple control Centers |
This option appears if the multiple Migration Control Center advanced feature is enabled on the Other Setting tab. Check this option to define the IP addresses of the Control Centers. When enabled, the Set Migration Status options include Set Migration MCC and Clear Migration MCC options. |
Migration Server Control Center IPs |
Appears if “I have multiple control Centers” is checked. This field is used by the Set Migration Status agent. Values must be entered as follows: Workstation#=IP address of Migrator for Notes Control Center For example: 1=192.168.1.0 2=192.168.1.1 3=192.168.1.2 |
User Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing users. Use the People view unless there is a custom view that you have created. |
Mail-In Databases Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing mail-in databases and resources. Use the Mail-In Databases view unless there is a custom view that you have created. |
Mail-In Databases View Category |
This is the NAB Mail-In database view category used for importing Mail-in Databases and Resources. Use the “Databases” default unless Domino is using a language other than English. Change this value to what is displayed in the NAB Mail-in Databases view. |
Migration Status Codes |
Specify a personalized list of status codes that will be used during the migration project. These codes can be assigned to users’ mail and databases control documents. If these status codes are assigned during the different phases of the migration process, timely status reports can be produced. These status reports will help provide a better picture of the migration progress. With this type of information, you have more control over the migration project and can react quickly to any identified issue. Adjustments can be made to help fine tune the migration schedule by adding more or different resources. Status codes must be separated by a new line. A list of status codes has been specified for you. You can either retain or change these status codes depending on your need. |
CAS Server |
Specify the Exchange Client Access Server (CAS) name. If a name is specified, then the matching process will use the following URL to resolve users. https://[servername]/autodiscover/autodiscover.xml
However, if you have specified the full URL to the Autodiscover service, then the URL will be used to resolve users.
This field is required for delegation migrations. |
Username |
If only the CAS Server name or IP address is specified in the CAS Server field, then you must specify a valid username for the authentication process that takes place on the CAS server. Note that the username should be in the following format for on-premises Exchange: <domain>\<username>. For Office 365 the format should be username@domain.com.
If you have specified a full URL (with https://) in the CAS Server field, then you can leave this field blank for on-premise migrations. |
Password |
Specify the password associated with the username provided in the previous field.
If you specified a full URL (with https://), then you can leave this field blank for on-premise migrations. |
Powershell Admin Credentials |
For on-premise Exchange servers, the credentials are of the form [Domain]\[Username]. For Office 365, the credentials are the SMTP address used to pass credentials to Office365 for remote access, for example o365Admin@tenant.onmicrosoft.com |
Powershell Admin Password |
Use the Set PowerShell Password button to update this field. This will request the password and record it using the AsSecure PowerShell method. This is not required for clicking the Migrator for Notes PowerShell buttons, if this is not entered the buttons (such as Set Full Acccess) will ask for the password when processed. |
PowerShell Logging Path |
The MS PowerShell used when generating, executing, and logging PS1 script. This path can be edited on User Provisioning tab. |
Default Reporting Path for Matching |
Specify the reporting path used by the matching process. The default path is C:\Matching\. |
Enable PowerShell Modern Auth |
Set to Yes to enable the use of the Microsoft Graph and Exchange Online modules for PowerShell processing. This will use Modern Auth connectivity to Microsoft Online services, removing the Basic Auth connection processing. Review Appendix E Microsoft Graph Application ID for additional configuration that is required to use Modern Authentication with an Azure AD Application ID. |
Enable Modern Auth for Migration |
Set to Yes to enable the use of Modern Authentication for Migrations. The Office 365 tenant must be configured to use Modern Authentication. Note: PowerShell matching using Modern Auth must be enabled for Modern Auth migrations to online mailboxes or archives. |
Autodiscover Username |
Autodiscover credentials to be used during creation of the profile used by the migration engine. For on-premise Exchange servers, the credentials entered should be the UPN (User Principal Name), for example: UserName@Example.Microsoft.com For Office 365, the credentials are the SMTP address of an account in the Office 365 domain, for example: o365Admin@tenant.onmicrosoft.com.
Note: This is used if a migration worker does not have an account specified and is a fall back option. This is not required if a migration farm is being built using AWD. |
Autodiscover Password |
Enter the password associated with the Autodiscover account entered above. |
Customer Name |
Specify the Customer name that you would like in the status report. |
Send Customer Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the status report. |
Send Operator Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the full status report. |
Migration Status Report Path |
Specify the working path for migration status reports. |
Create a combined report for multiple Migration Management databases (up to 5 additional) |
Check this option to specify up to five additional migration management databases to include in a combined report. |
The Migrator for Notes Settings document displays. In the Settings document, the Required Settings -> Domino tab displays by default.
|
You can view the description of each field in each tab by clicking its corresponding question mark icon |
Before any migration can be performed, the Required Settings tab must be completed. Two of the most important entries in this tab are the Mail Server and the Domino Directory. The specified Mail Server name is used to access the Domino Directory. The Domino Directory is used to retrieve the information required to import and create the User Mail, Rooms & Resources Databases, Mail-in Databases, and Discussion & Document Library Databases control documents.
These control documents are critical to the migration process and in their absence, migration information cannot be collected for a given item, and therefore, the item cannot be migrated. The control documents are used extensively during the remaining migration processes.
The following table describes the values for each setting.
Settings |
Description |
Mail Server |
The Domino server that Migrator for Notes will use for importing users and for sending Migration Messages. |
Domino Directory |
The Domino Directory name that Migrator for Notes will use for importing users, as found on the Domino server. Up to five additional Domino directories can be set by checking the box. |
Server Mailbox |
The mailbox filename that Migrator for Notes uses for sending Migration-related messages to selected users (for example, mail.box). |
Audit Domino Encrypted Items |
When running Audit on user mail file, specifying Yes will check for encrypted items in the mail file. If encrypted items are found, you can either send the user an email message with a button that decrypts encrypted items so that they can be migrated, or you can send the user a message with document links to the encrypted items so that they can print them prior to migration. You can even do both if you have some reason to want a list of messages that had been encrypted before the decryption agent was run. |
Audit Domino Mail Rules |
When running Audit on user mail file, specifying Yes will check for the number of rules in the mail file. If rules are found, you can send users a list of their Rules that will help them in creating the rules in Outlook after migration. |
Audit Exchange Migrated Data |
Enables auditing of migrated data in Exchange. Exchange Auditing should be enabled before data is migrated. Audit reports can be found the \logs directory on the migration workstation(s). This is a post-migration validation process that indicates the state of documents which have been migrated by Migrator for Notes. This feature can be useful in environments as a validation check for data integrity. In addition, this can be used to audit results to reduce the size of user Domino mail files or archive databases after the migration phase on the Domino servers and user's workstation replicas. For example, removing documents with a Migration Status of 1 would leave only non-migrated data or documents that could not be migrated completely due to malformation or size restrictions in Exchange from a source database. Important: Consult your organizations data retention policies and regulatory compliance requirements before modifying source data. Full backups of the original source data may be required (and maintained post migration) before modifying working replicas to ensure regulatory compliance. |
Audit embedded eml attachments |
Enables auditing of eml attachments inside the message bodies to assist with migration troubleshooting. Results will be reported on the user document in EMM. This is not required for migration processing unless directed to enable this by Binary Tree's Product Support. Additionally, a flag can be enabled and adds the field BTFoundEML to documents in source mail files where auditing finds eml attachments inside the message bodies. |
Audit calendar unsupported patterns |
Enables auditing of calendar items where the user is the Chair for Notes custom repeating meetings and generates document links for meetings that are not supported by Outlook. This will use the Migration Date if set or the current date and include meetings from the date specified and future meetings. The audit adds the reported data to the Calendar audit RTF report for the account and can be sent to end users with the Remediation Summary Message Template. If enabled the audit can be specified to verify meetings where the user is the Chair, an Invitee or both. Additionally, label text can be added to the reported data to specify if the user is the Chair or the Invitee. |
User Notification Style |
Individual Notifications: Select if you want to send individual notification to each user and each mail/form will only have script for one action.
Combined Notifications: Select if you want to send one migration notification to each user and the notification/message to contain multiple selected forms, such as decrypting encrypted messages and synchronizing contacts and journals (notebooks) with mail file. |
Enable this CMT db for Notifications |
Click this button to create a Mail-In database document on the Domino Server for the Migrator for Notes database, and enable the database to receive User Notification responses. This database must be hosted on a Domino server. |
A Mail-in Database Document is required for mail to be delivered to the newly created server copy of the Migrator for Notes database. The procedure copies the database to the server and creates a Mail-In database document for the Migrator for Notes database.
Create a mail-in database for Migrator for Notes database. Click on the Server Db Copy and Mail-In Db Doc button to create a copy of the Migrator for Notes database on the Domino server and configure the Mail in Database document
The Does Migrator for Notes already exist? dialog box opens; click Yes (and skip to step 5):
If you are working with a local copy of the Migrator for Notes database, then click No. The Create a db copy? dialog box opens.
Click Yes to create a copy of the local Migrator for Notes database on the server:
If you clicked Yes in the Does Migrator for Notes CMT already exist? dialog box, the Choose Application dialog box opens. Locate the Migrator for Notes database in the CMT folder on the server, and then click Open.
The process will ask if there is already a mail-in db document in the Domino directory. If this has been created already then click Yes to run a search for the entry in the directory. This is case sensitive for the Migrator for Notes application name on the Notes Migrator.nsf file. Click No to create a mail-in db document.
The Fullname for the mail-in db doc dialog box confirms that the mail-in database for the selected server-based Migrator for Notes database does not exist, and prompts you to specify a name for the mail-in database. After specifying the name, click OK.
In the Open the new mail-in doc? dialog box, click Yes to open the mail-in database.
The mail-in database document for Migrator for Notes opens.
To verify the creation of the mail-in database, you can also launch Domino Administrator, open the Domino server, and access the Mail-In Databases and Resources folder under the People & Groups tab:
Double-click the document to open and review
Once the mail-in database is successfully created, the Open Mail-In Db Doc button replaces the Server Db Copy and Mail-In Db Doc button. Clicking it opens the database document for a review. Clicking the button with the X sign on it will remove all pointers to the location of the mail-in database.
|
If you do not have the appropriate access rights to perform this action, see the onsite Domino System Administrator for help. |
It is recommended that after copying the database to the server, you delete the database from the local client folder. To remove it, right-click on Migrator for Notes on Local. Select Database, and then Delete. The Lotus Notes client prompts that the database and related documents will be permanently deleted. Click Yes to delete the local database.
Once you have mail-enabled the database, you need to modify the Inbound Processing agent to view the updates. Perform the following steps to run the agent.
Install Domino Designer on the workstation where Migrator for Notes Domino database is located
Launch Migrator for Notes Domino database in Domino Designer
Expand Shared Code and select Agents
Select the InboundProcessing agent as shown below:
Double-click InboundProcessing to open the InboundProcessing Agent Properties
Click the Security tab
The Administrator should be listed in the Run on behalf of section
In the Set Runtime security level: field, select Allow Restricted Operations with full administration rights
Once you've edited the agent, close the Properties box
Close the Inbound Processing – Agent tab
Save the changes
Click Sign
|
This agent runs before new mail arrives and the Domino router must be set to allow these types of agents to run. To enable this option, go to Router/SMTP -> Restrictions and Controls -> Delivery Controls tab and set the Pre-delivery agents option to Enabled. |
|
The Notes ID that signs this agent does require security rights on the Domino server to run agents. |
Click LDAP under the Required Settings tab:
In this tab, specify the Active Directory information to resolve users by matching them between source and destination platforms via Lightweight Directory Access Protocol (LDAP). To use this option, specify the required details.
|
LDAP configuration is not specifically required for Office 365 only migrations. |
Use the following table to enter the correct values for each field:
Settings |
Description |
Domain |
The common name of the Active Directory domain. For example, binarytree rather than binarytree.com. |
LDAP IP Address or Host Name |
The fully qualified LDAP server name, IP Address, or resolvable DNS name of the Active Directory server. (e.g. PC-XP-01. binarytree.com or 192.163.15.12). |
LDAP Port |
Specify the LDAP port. The default port for LDAP is 389. The default port for SSL LDAP is 636. |
Login ID |
The AD domain account that has read rights to the target AD domain. For example: administrator and not <domain>\administrator |
Password |
The password associated with the ID specified in Login ID. |
Validate Settings |
Click to validate the specified values to ensure that you are able to connect to the domain in Exchange where the end users will be eventually migrated. |
LDAP Directory Base (Base DN) |
If LDAP settings result in a successful connection, then this field is automatically updated. Specify the directory base for all LDAP queries. The query settings will enable the search in AD to ensure that users are getting resolved against the right container ‘directory’ within AD. Example: DC=btexchange2k7,DC=com |
Quick Check Full Check |
If you want to search only the first ten users, select Quick Check; and if you want to search all the users, select Full Check. |
Validate Query Settings |
Click to validate the values specified in LDAP Directory Base to ensure that query string is resolving users and returning the number of resolved users. |
Specify the connection settings and then validate them by clicking the Validate Settings button:
The LDAP Connection Settings Test Results message box displays indicating that the settings were validated and the connection was successful; click OK:
Notice that the LDAP Directory Base (Base DN) field is automatically populated
To ensure that the specified directory base, where all LDAP searches will be conducted, is correct; you should validate this setting as well; click the Validate Query Settings button:
The LDAP Query User Settings Test Results message box displays; the query setting is validated and some records are returned; in a production environment, ten records should be returned always; click OK:
Click the Additional tab under Required Settings
Configure these settings with the names of the views to locate and import User and Mail-in Databases information. Also, specify the Migration Status Codes that can be assigned to users’ mail and databases control documents. You can assign a code to a user to update its status and view users based on their status codes. This helps in providing a better picture of the migration progress.
The following table describes the values for each setting:
Settings |
Description |
---|---|
CMT Migration Server |
Specify the network hostname or IP address of the machine that is running the migration server. |
CMT Program Directory |
Specify the complete program directory path to Migrator for Notes installation. This location will be used to launch the migration engine when the migration is triggered off.
Note: During the installation of Migrator for Notes, if you had specified a destination folder path other than the default (C:\Program Files\Binary Tree\CMT Exchange), then you must replace the default path specified in the CMT Program Directory field with the modified path. In failing to do so, the migration engine will not launch when the migrations are set to go off. |
Use Secure Web Services |
Specify whether the web service calls are made to an XML server configured for secure access. Note that additional steps are required to secure the web services. The default selection is “Yes” which uses the CMT eService COM object to access the XML server.
Refer to Appendix D: Securing Migrator for Notes Web Services with Windows Authentication for additional steps if you select Yes. |
I have multiple control Centers |
This option appears if the multiple Migration Control Center advanced feature is enabled on the Other Setting tab. Check this option to define the IP addresses of the Control Centers. When enabled, the Set Migration Status options include Set Migration MCC and Clear Migration MCC options. |
Migration Server Control Center IPs |
Appears if “I have multiple control Centers” is checked. This field is used by the Set Migration Status agent. Values must be entered as follows: Workstation#=IP address of Migrator for Notes Control Center For example: 1=192.168.1.0 2=192.168.1.1 3=192.168.1.2 |
User Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing users. Use the People view unless there is a custom view that you have created. |
Mail-In Databases Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing mail-in databases and resources. Use the Mail-In Databases view unless there is a custom view that you have created. |
Mail-In Databases View Category |
This is the NAB Mail-In database view category used for importing Mail-in Databases and Resources. Use the “Databases” default unless Domino is using a language other than English. Change this value to what is displayed in the NAB Mail-in Databases view. |
Migration Status Codes |
Specify a personalized list of status codes that will be used during the migration project. These codes can be assigned to users’ mail and databases control documents. If these status codes are assigned during the different phases of the migration process, timely status reports can be produced. These status reports will help provide a better picture of the migration progress. With this type of information, you have more control over the migration project and can react quickly to any identified issue. Adjustments can be made to help fine tune the migration schedule by adding more or different resources. Status codes must be separated by a new line. A list of status codes has been specified for you. You can either retain or change these status codes depending on your need. |
CAS Server |
Specify the Exchange Client Access Server (CAS) name. If a name is specified, then the matching process will use the following URL to resolve users. https://[servername]/autodiscover/autodiscover.xml
However, if you have specified the full URL to the Autodiscover service, then the URL will be used to resolve users.
This field is required for delegation migrations. |
Username |
If only the CAS Server name or IP address is specified in the CAS Server field, then you must specify a valid username for the authentication process that takes place on the CAS server. Note that the username should be in the following format for on-premises Exchange: <domain>\<username>. For Office 365 the format should be username@domain.com.
If you have specified a full URL (with https://) in the CAS Server field, then you can leave this field blank for on-premise migrations. |
Password |
Specify the password associated with the username provided in the previous field.
If you specified a full URL (with https://), then you can leave this field blank for on-premise migrations. |
Powershell Admin Credentials |
For on-premise Exchange servers, the credentials are of the form [Domain]\[Username]. For Office 365, the credentials are the SMTP address used to pass credentials to Office365 for remote access, for example o365Admin@tenant.onmicrosoft.com |
Powershell Admin Password |
Use the Set PowerShell Password button to update this field. This will request the password and record it using the AsSecure PowerShell method. This is not required for clicking the Migrator for Notes PowerShell buttons, if this is not entered the buttons (such as Set Full Acccess) will ask for the password when processed. |
PowerShell Logging Path |
The MS PowerShell used when generating, executing, and logging PS1 script. This path can be edited on User Provisioning tab. |
Default Reporting Path for Matching |
Specify the reporting path used by the matching process. The default path is C:\Matching\. |
Enable PowerShell Modern Auth |
Set to Yes to enable the use of the Microsoft Graph and Exchange Online modules for PowerShell processing. This will use Modern Auth connectivity to Microsoft Online services, removing the Basic Auth connection processing. Review Appendix E Microsoft Graph Application ID for additional configuration that is required to use Modern Authentication with an Azure AD Application ID. |
Enable Modern Auth for Migration |
Set to Yes to enable the use of Modern Authentication for Migrations. The Office 365 tenant must be configured to use Modern Authentication. Note: PowerShell matching using Modern Auth must be enabled for Modern Auth migrations to online mailboxes or archives. |
Autodiscover Username |
Autodiscover credentials to be used during creation of the profile used by the migration engine. For on-premise Exchange servers, the credentials entered should be the UPN (User Principal Name), for example: UserName@Example.Microsoft.com For Office 365, the credentials are the SMTP address of an account in the Office 365 domain, for example: o365Admin@tenant.onmicrosoft.com.
Note: This is used if a migration worker does not have an account specified and is a fall back option. This is not required if a migration farm is being built using AWD. |
Autodiscover Password |
Enter the password associated with the Autodiscover account entered above. |
Customer Name |
Specify the Customer name that you would like in the status report. |
Send Customer Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the status report. |
Send Operator Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the full status report. |
Migration Status Report Path |
Specify the working path for migration status reports. |
Create a combined report for multiple Migration Management databases (up to 5 additional) |
Check this option to specify up to five additional migration management databases to include in a combined report. |
The Migrator for Notes Settings document displays. In the Settings document, the Required Settings -> Domino tab displays by default.
|
You can view the description of each field in each tab by clicking its corresponding question mark icon |
Before any migration can be performed, the Required Settings tab must be completed. Two of the most important entries in this tab are the Mail Server and the Domino Directory. The specified Mail Server name is used to access the Domino Directory. The Domino Directory is used to retrieve the information required to import and create the User Mail, Rooms & Resources Databases, Mail-in Databases, and Discussion & Document Library Databases control documents.
These control documents are critical to the migration process and in their absence, migration information cannot be collected for a given item, and therefore, the item cannot be migrated. The control documents are used extensively during the remaining migration processes.
The following table describes the values for each setting.
Settings |
Description |
Mail Server |
The Domino server that Migrator for Notes will use for importing users and for sending Migration Messages. |
Domino Directory |
The Domino Directory name that Migrator for Notes will use for importing users, as found on the Domino server. Up to five additional Domino directories can be set by checking the box. |
Server Mailbox |
The mailbox filename that Migrator for Notes uses for sending Migration-related messages to selected users (for example, mail.box). |
Audit Domino Encrypted Items |
When running Audit on user mail file, specifying Yes will check for encrypted items in the mail file. If encrypted items are found, you can either send the user an email message with a button that decrypts encrypted items so that they can be migrated, or you can send the user a message with document links to the encrypted items so that they can print them prior to migration. You can even do both if you have some reason to want a list of messages that had been encrypted before the decryption agent was run. |
Audit Domino Mail Rules |
When running Audit on user mail file, specifying Yes will check for the number of rules in the mail file. If rules are found, you can send users a list of their Rules that will help them in creating the rules in Outlook after migration. |
Audit Exchange Migrated Data |
Enables auditing of migrated data in Exchange. Exchange Auditing should be enabled before data is migrated. Audit reports can be found the \logs directory on the migration workstation(s). This is a post-migration validation process that indicates the state of documents which have been migrated by Migrator for Notes. This feature can be useful in environments as a validation check for data integrity. In addition, this can be used to audit results to reduce the size of user Domino mail files or archive databases after the migration phase on the Domino servers and user's workstation replicas. For example, removing documents with a Migration Status of 1 would leave only non-migrated data or documents that could not be migrated completely due to malformation or size restrictions in Exchange from a source database. Important: Consult your organizations data retention policies and regulatory compliance requirements before modifying source data. Full backups of the original source data may be required (and maintained post migration) before modifying working replicas to ensure regulatory compliance. |
Audit embedded eml attachments |
Enables auditing of eml attachments inside the message bodies to assist with migration troubleshooting. Results will be reported on the user document in EMM. This is not required for migration processing unless directed to enable this by Binary Tree's Product Support. Additionally, a flag can be enabled and adds the field BTFoundEML to documents in source mail files where auditing finds eml attachments inside the message bodies. |
Audit calendar unsupported patterns |
Enables auditing of calendar items where the user is the Chair for Notes custom repeating meetings and generates document links for meetings that are not supported by Outlook. This will use the Migration Date if set or the current date and include meetings from the date specified and future meetings. The audit adds the reported data to the Calendar audit RTF report for the account and can be sent to end users with the Remediation Summary Message Template. If enabled the audit can be specified to verify meetings where the user is the Chair, an Invitee or both. Additionally, label text can be added to the reported data to specify if the user is the Chair or the Invitee. |
User Notification Style |
Individual Notifications: Select if you want to send individual notification to each user and each mail/form will only have script for one action.
Combined Notifications: Select if you want to send one migration notification to each user and the notification/message to contain multiple selected forms, such as decrypting encrypted messages and synchronizing contacts and journals (notebooks) with mail file. |
Enable this CMT db for Notifications |
Click this button to create a Mail-In database document on the Domino Server for the Migrator for Notes database, and enable the database to receive User Notification responses. This database must be hosted on a Domino server. |
A Mail-in Database Document is required for mail to be delivered to the newly created server copy of the Migrator for Notes database. The procedure copies the database to the server and creates a Mail-In database document for the Migrator for Notes database.
Create a mail-in database for Migrator for Notes database. Click on the Server Db Copy and Mail-In Db Doc button to create a copy of the Migrator for Notes database on the Domino server and configure the Mail in Database document
The Does Migrator for Notes already exist? dialog box opens; click Yes (and skip to step 5):
If you are working with a local copy of the Migrator for Notes database, then click No. The Create a db copy? dialog box opens.
Click Yes to create a copy of the local Migrator for Notes database on the server:
If you clicked Yes in the Does Migrator for Notes CMT already exist? dialog box, the Choose Application dialog box opens. Locate the Migrator for Notes database in the CMT folder on the server, and then click Open.
The process will ask if there is already a mail-in db document in the Domino directory. If this has been created already then click Yes to run a search for the entry in the directory. This is case sensitive for the Migrator for Notes application name on the Notes Migrator.nsf file. Click No to create a mail-in db document.
The Fullname for the mail-in db doc dialog box confirms that the mail-in database for the selected server-based Migrator for Notes database does not exist, and prompts you to specify a name for the mail-in database. After specifying the name, click OK.
In the Open the new mail-in doc? dialog box, click Yes to open the mail-in database.
The mail-in database document for Migrator for Notes opens.
To verify the creation of the mail-in database, you can also launch Domino Administrator, open the Domino server, and access the Mail-In Databases and Resources folder under the People & Groups tab:
Double-click the document to open and review
Once the mail-in database is successfully created, the Open Mail-In Db Doc button replaces the Server Db Copy and Mail-In Db Doc button. Clicking it opens the database document for a review. Clicking the button with the X sign on it will remove all pointers to the location of the mail-in database.
|
If you do not have the appropriate access rights to perform this action, see the onsite Domino System Administrator for help. |
It is recommended that after copying the database to the server, you delete the database from the local client folder. To remove it, right-click on Migrator for Notes on Local. Select Database, and then Delete. The Lotus Notes client prompts that the database and related documents will be permanently deleted. Click Yes to delete the local database.
Once you have mail-enabled the database, you need to modify the Inbound Processing agent to view the updates. Perform the following steps to run the agent.
Install Domino Designer on the workstation where Migrator for Notes Domino database is located
Launch Migrator for Notes Domino database in Domino Designer
Expand Shared Code and select Agents
Select the InboundProcessing agent as shown below:
Double-click InboundProcessing to open the InboundProcessing Agent Properties
Click the Security tab
The Administrator should be listed in the Run on behalf of section
In the Set Runtime security level: field, select Allow Restricted Operations with full administration rights
Once you've edited the agent, close the Properties box
Close the Inbound Processing – Agent tab
Save the changes
Click Sign
|
This agent runs before new mail arrives and the Domino router must be set to allow these types of agents to run. To enable this option, go to Router/SMTP -> Restrictions and Controls -> Delivery Controls tab and set the Pre-delivery agents option to Enabled. |
|
The Notes ID that signs this agent does require security rights on the Domino server to run agents. |
Click LDAP under the Required Settings tab:
In this tab, specify the Active Directory information to resolve users by matching them between source and destination platforms via Lightweight Directory Access Protocol (LDAP). To use this option, specify the required details.
|
LDAP configuration is not specifically required for Office 365 only migrations. |
Use the following table to enter the correct values for each field:
Settings |
Description |
Domain |
The common name of the Active Directory domain. For example, binarytree rather than binarytree.com. |
LDAP IP Address or Host Name |
The fully qualified LDAP server name, IP Address, or resolvable DNS name of the Active Directory server. (e.g. PC-XP-01. binarytree.com or 192.163.15.12). |
LDAP Port |
Specify the LDAP port. The default port for LDAP is 389. The default port for SSL LDAP is 636. |
Login ID |
The AD domain account that has read rights to the target AD domain. For example: administrator and not <domain>\administrator |
Password |
The password associated with the ID specified in Login ID. |
Validate Settings |
Click to validate the specified values to ensure that you are able to connect to the domain in Exchange where the end users will be eventually migrated. |
LDAP Directory Base (Base DN) |
If LDAP settings result in a successful connection, then this field is automatically updated. Specify the directory base for all LDAP queries. The query settings will enable the search in AD to ensure that users are getting resolved against the right container ‘directory’ within AD. Example: DC=btexchange2k7,DC=com |
Quick Check Full Check |
If you want to search only the first ten users, select Quick Check; and if you want to search all the users, select Full Check. |
Validate Query Settings |
Click to validate the values specified in LDAP Directory Base to ensure that query string is resolving users and returning the number of resolved users. |
Specify the connection settings and then validate them by clicking the Validate Settings button:
The LDAP Connection Settings Test Results message box displays indicating that the settings were validated and the connection was successful; click OK:
Notice that the LDAP Directory Base (Base DN) field is automatically populated
To ensure that the specified directory base, where all LDAP searches will be conducted, is correct; you should validate this setting as well; click the Validate Query Settings button:
The LDAP Query User Settings Test Results message box displays; the query setting is validated and some records are returned; in a production environment, ten records should be returned always; click OK:
Click the Additional tab under Required Settings
Configure these settings with the names of the views to locate and import User and Mail-in Databases information. Also, specify the Migration Status Codes that can be assigned to users’ mail and databases control documents. You can assign a code to a user to update its status and view users based on their status codes. This helps in providing a better picture of the migration progress.
The following table describes the values for each setting:
Settings |
Description |
---|---|
CMT Migration Server |
Specify the network hostname or IP address of the machine that is running the migration server. |
CMT Program Directory |
Specify the complete program directory path to Migrator for Notes installation. This location will be used to launch the migration engine when the migration is triggered off.
Note: During the installation of Migrator for Notes, if you had specified a destination folder path other than the default (C:\Program Files\Binary Tree\CMT Exchange), then you must replace the default path specified in the CMT Program Directory field with the modified path. In failing to do so, the migration engine will not launch when the migrations are set to go off. |
Use Secure Web Services |
Specify whether the web service calls are made to an XML server configured for secure access. Note that additional steps are required to secure the web services. The default selection is “Yes” which uses the CMT eService COM object to access the XML server.
Refer to Appendix D: Securing Migrator for Notes Web Services with Windows Authentication for additional steps if you select Yes. |
I have multiple control Centers |
This option appears if the multiple Migration Control Center advanced feature is enabled on the Other Setting tab. Check this option to define the IP addresses of the Control Centers. When enabled, the Set Migration Status options include Set Migration MCC and Clear Migration MCC options. |
Migration Server Control Center IPs |
Appears if “I have multiple control Centers” is checked. This field is used by the Set Migration Status agent. Values must be entered as follows: Workstation#=IP address of Migrator for Notes Control Center For example: 1=192.168.1.0 2=192.168.1.1 3=192.168.1.2 |
User Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing users. Use the People view unless there is a custom view that you have created. |
Mail-In Databases Import View |
Specify the view in the Domino directory that Migrator for Notes database will use for importing mail-in databases and resources. Use the Mail-In Databases view unless there is a custom view that you have created. |
Mail-In Databases View Category |
This is the NAB Mail-In database view category used for importing Mail-in Databases and Resources. Use the “Databases” default unless Domino is using a language other than English. Change this value to what is displayed in the NAB Mail-in Databases view. |
Migration Status Codes |
Specify a personalized list of status codes that will be used during the migration project. These codes can be assigned to users’ mail and databases control documents. If these status codes are assigned during the different phases of the migration process, timely status reports can be produced. These status reports will help provide a better picture of the migration progress. With this type of information, you have more control over the migration project and can react quickly to any identified issue. Adjustments can be made to help fine tune the migration schedule by adding more or different resources. Status codes must be separated by a new line. A list of status codes has been specified for you. You can either retain or change these status codes depending on your need. |
CAS Server |
Specify the Exchange Client Access Server (CAS) name. If a name is specified, then the matching process will use the following URL to resolve users. https://[servername]/autodiscover/autodiscover.xml
However, if you have specified the full URL to the Autodiscover service, then the URL will be used to resolve users.
This field is required for delegation migrations. |
Username |
If only the CAS Server name or IP address is specified in the CAS Server field, then you must specify a valid username for the authentication process that takes place on the CAS server. Note that the username should be in the following format for on-premises Exchange: <domain>\<username>. For Office 365 the format should be username@domain.com.
If you have specified a full URL (with https://) in the CAS Server field, then you can leave this field blank for on-premise migrations. |
Password |
Specify the password associated with the username provided in the previous field.
If you specified a full URL (with https://), then you can leave this field blank for on-premise migrations. |
Powershell Admin Credentials |
For on-premise Exchange servers, the credentials are of the form [Domain]\[Username]. For Office 365, the credentials are the SMTP address used to pass credentials to Office365 for remote access, for example o365Admin@tenant.onmicrosoft.com |
Powershell Admin Password |
Use the Set PowerShell Password button to update this field. This will request the password and record it using the AsSecure PowerShell method. This is not required for clicking the Migrator for Notes PowerShell buttons, if this is not entered the buttons (such as Set Full Acccess) will ask for the password when processed. |
PowerShell Logging Path |
The MS PowerShell used when generating, executing, and logging PS1 script. This path can be edited on User Provisioning tab. |
Default Reporting Path for Matching |
Specify the reporting path used by the matching process. The default path is C:\Matching\. |
Enable PowerShell Modern Auth |
Set to Yes to enable the use of the Microsoft Graph and Exchange Online modules for PowerShell processing. This will use Modern Auth connectivity to Microsoft Online services, removing the Basic Auth connection processing. Review Appendix E Microsoft Graph Application ID for additional configuration that is required to use Modern Authentication with an Azure AD Application ID. |
Enable Modern Auth for Migration |
Set to Yes to enable the use of Modern Authentication for Migrations. The Office 365 tenant must be configured to use Modern Authentication. Note: PowerShell matching using Modern Auth must be enabled for Modern Auth migrations to online mailboxes or archives. |
Autodiscover Username |
Autodiscover credentials to be used during creation of the profile used by the migration engine. For on-premise Exchange servers, the credentials entered should be the UPN (User Principal Name), for example: UserName@Example.Microsoft.com For Office 365, the credentials are the SMTP address of an account in the Office 365 domain, for example: o365Admin@tenant.onmicrosoft.com.
Note: This is used if a migration worker does not have an account specified and is a fall back option. This is not required if a migration farm is being built using AWD. |
Autodiscover Password |
Enter the password associated with the Autodiscover account entered above. |
Customer Name |
Specify the Customer name that you would like in the status report. |
Send Customer Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the status report. |
Send Operator Status Report To |
Specify the Group Name or SMTP addresses of the persons that should receive the full status report. |
Migration Status Report Path |
Specify the working path for migration status reports. |
Create a combined report for multiple Migration Management databases (up to 5 additional) |
Check this option to specify up to five additional migration management databases to include in a combined report. |
© ALL RIGHTS RESERVED. Feedback Nutzungsbedingungen Datenschutz Cookie Preference Center