The Getting Started section of the MNE Quick-Start Guide explains how to install Migrator for Notes to Exchange. The topics that follow describe the configuration tasks that should be performed now as part of the Migrator for Notes to Exchange configuration before the first run of any MNE component application. (All but the first are optional or conditional.)
IMPORTANT: Any antivirus software on the admin workstation must be configured to not scan the Quest program files directory or %temp% directory, or can be turned off prior to running any Quest admin application. (Although it may be restarted after the program runs.) MNE program calls will not succeed if an antivirus scan tries to "clean" an Migrator for Notes to Exchange temporary file that it misinterprets as a threat. |
Enter these Default Settings into Notes Migration Manager (the MNE console) before other you use other MNE features or the wizards so that the information is available and need not be entered again. If the information is not entered upon installation, the wizards prompt for the values as needed and most of the values must be entered more than once—entered for each feature and wizard that needs them.
NOTE: Quest recommends you access all five of the Edit Default Settings screens in Notes Migration Manager now to enter this information. The Notes Migration Manager is described in chapter 1 of the Migrator for Notes to Exchange Administration Guide. |
Migrator for Notes to Exchange tasks are defined by wizards, most of which let you schedule tasks. The Manage Scheduled Operations screen in Notes Migration Manager lets you revise these task-execution schedules. However. the wizards and Manage Scheduled Operations screen only manage the task schedules since the schedules are saved in the SQL database. A scheduled task does not execute by itself. Tasks are executed by the MNE Task Scheduler (qsched.exe).
The task scheduler is a separate command-line application that executes the scheduled MNE tasks. The program checks the SQL database to see if any tasks have been scheduled to run since the last check and executes the tasks. You manage the task scheduler as any other Windows service using the Windows Service Manager. Instructions for configuring a Windows service can be found at: http://msdn.microsoft.com/en-us/library/ms681921(v=vs.85).aspx
For information about configuring and using the task scheduler, see the section titled “Using the Qsched.exe task-scheduling utility” in the Migrator for Notes to Exchange Administration Guide.
Conditional Step: This step applies only if you will use Migrator for Notes to Exchange to create objects in the target AD. |
If you using Migrator for Notes to Exchange to create user objects in the target AD, use a text editor to edit the following parameter settings in the Global Defaults:
|
The PSRetryAttempts parameter tells the Provisioning Wizard how many times to retry the transmission at intervals specified by the PSRetryWait parameter. If the error persists through all retry attempts, the wizard logs an error, skips the current message property or element, and continues to process the next item. Depending on the Log level setting (on the Specify Run Information screen), the retry attempts can appear in the program logs with no other documented error or warning. The default settings (PSRetryAttempts=3, PSRetryWait=15) tell the wizard to retry an AD transmission to a maximum of three attempts at 15-second intervals.
IMPORTANT: If you set the PSRetry parameters to values higher than the defaults, consider adjusting the WatchDogMinutes parameter. WatchDogMinutes specifies the number of minutes (default=180) of inactivity the Data Migration Wizard waits before concluding the connection has timed out and ending the process. Quest recommends you set WatchDogMinutes at the greater of: its 180-minute default, or a setting of 10 minutes for every 30 seconds of retry waiting (PSRetryAttempts x PSRetryWait). |
Conditional Step: This step applies only if you want to migrate Notes custom attributes. |
A Notes message contains several standard attributes such as the From, To and Subject fields, and can also include user-defined fields. The MNE Data Migration Wizard and SSDM can migrate custom Notes attributes from email messages and Notes contacts to unused properties in Exchange, but only if the migration software knows which properties in the target correspond to which attributes in the source. The migration of custom attributes requires that you map these source-to-target attribute associations in a tsv data file, before the migration, so the migration apps can refer to that file to migrate the attributes.
This mapping file must be a Unicode (not ANSI) file named customattrs.tsv located in the installation folder for the Data Migration Wizard (by default C:\Program Files\Quest\Migrator for Notes to Exchange) and also in the folder containing the notesdtapp.exe file if you want to migrate Notes custom attributes via the SSDM. The migrator applications can refer to this file to map the source attributes to free (unused) properties in Exchange.
Migrator for Notes to Exchange installs a Unicode attrs.tsv file, with the same column headings required for customattrs.tsv that you can use as a template to create the customattrs.tsv file.
1 |
Use a text editor to open attrs.tsv, and save the open copy under the new name customattrs.tsv. Ensure you save customattrs.tsv as a Unicode (not ANSI) file in the appropriate folder. Delete any data rows that appear in the copy. |
• |
ID: Name of the custom attribute—a unique string that distinguishes the row’s custom attribute from all other attributes in the file. |
IMPORTANT: If any data rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files. |
• |
SourceProperty: Name of an attribute that has been added to a Notes mail message or a Notes contact, to be migrated to a property in Exchange. |
• |
TargetPropertySet: The GUID for the target property set, which must be one of these values: |
• |
TargetProperty: Name of the corresponding MAPI property in Exchange. A hexadecimal user-property value is created in Exchange on each migrated mail message or contact with the Notes property which will hold the value. The hexadecimal values of the created properties is reported in the log (search for "custom attr" in the log file). |
• |
TargetPropertyType: The data type of the MAPI property which must logically correspond to the data type used in Notes. Valid values are: STRING, MV_STRING, LONG, SYSTIME, BOOLEAN. |
3 |
Save and close the updated customattrs.tsv file. |
For example, a typical customattrs.tsv file might look as shown in the following table:
ArchiveId |
Archive ID |
You can use the Microsoft MfcMapi.exe utility to view the property and its value. (The utility is a free download from Microsoft. You can search in Google for "mfcmapi" and visit the www.microsoft.com/downloads link.)
Most problems in migrating custom attributes can be diagnosed by these quick tests:
• |
Verify that the target property that is specified in the customattrs.tsv file does not already exist and that the target property is in the correct format. See About MAPI properties for more information. |
• |
Verify that the customattrs.tsv file is Unicode, not ANSI. |
• |
Verify that the last line in the customattrs.tsv file is followed by a line feed and carriage return (position the cursor at the end of the last line and press Enter). |
• |
If any data rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files. |
A named property name is a property-set GUID and an ID that is either a 32-bit integer or a string. A 16-bit integer alias in the range 0x8000 to 0xFFFF is assigned to the named property by MAPI. That alias is mailbox-specific.
An unnamed property name is a 16-bit integer in the range 0x0001 to 0x7FFF. That 16-bit integer is valid in all mailboxes. Examples of unnamed properties are 0x0070 (i.e., PR_CONVERSATION_TOPIC) and 0x6656, both of which are used by MAPI. So you cannot use these two examples as target property values for message attributes since they are already used though they may be used to map Notes contact attributes to Exchange.
A custom property can be unnamed or named.
If the custom property is unnamed, select a 16-bit integer TargetProperty in the range 0x0001 to 0x7FFF that is not already in use by MAPI. The following values are reserved by MNE:
• |
• |
• |
• |
• |
If you want named custom properties, Quest recommends you use the PS_PUBLIC_STRINGS property-set GUID, (PS_PUBLIC_STRINGS being an alias for {00020329-0000-0000-C000-000000000046}), and use string IDs with a prefix that is unique to your application (like "Quest-").
Conditional Step: This step applies only if you will configure email coexistence using temporary routing domains (domain differentiation in DNS) during the migration. If you use smart hosts for mail routing or will not configure mail routing at all, skip to step 5. |
1 |
If appropriate SMTP domains are not already available, create them in DNS. One domain directs traffic to Exchange (e.g., exchg.domain.com). Mail sent to the Notes mailboxes of migrated users is forwarded to the corresponding mailboxes in Exchange using the exchg.domain.com domain. The other domain (e.g., notes.domain.com) is used to route mail back to Notes for users who have not yet migrated. |
2 |
After configuring the new exchg.domain.com domain in DNS, configure Exchange to accept the SMTP domain and create a recipient policy to generate secondary SMTP addresses so all Exchange users are able to receive mail at this domain. |
3 |
Configure Notes to accept mail to the new notes.domain.com SMTP domain/address. |
Conditional Step: This step applies only if you will configure some method of email, directory and/or free/busy coexistence during the migration transition period. If you will migrate without coexistence, skip to step 6. |
Configure your coexistence strategy:
• |
For complete coexistence with Quest CMN: Refer to the Coexistence Manager for Notes documentation to install and configure the desired components (Directory Connector, Free/Busy Connector, and/or Mail Connector). Directory Connectors must be created and run to update Domino and Active Directory with routing objects that correspond to the users in the other system to establish complete directories. |
IMPORTANT: If you have existing mail-enabled objects in AD, enable the MNE Compatability Mode for the CMN Directory Connectors that will populate AD from Notes to avoid duplicate entries in AD. The CMN Mail Connector and Free/Busy Connector can be configured similar to other scenarios. See the Coexistence Manager for Notes User Guide for more information. |
• |
For SMTP mail routing (without CMN): If you have not tested mail flow to verify the subdomains you configured in the preceding step, do so now. |
Define the free/busy and mail domains in the Domino Administrator:
• |
Add a Foreign Domain for the free/busy server: |
• |
Mail Information tab: Set Gateway server name to the name of the Domino mail server. |
• |
Calendar Information tab: Set Calendar server name to the name of the Domino server where qcalcon.exe is installed. |
• |
• |
Set Internet Domain to the name of the Exchange subdomain. |
• |
Set Internet Host to the IP of the Internet host. |
NOTE: These procedures do not create user Exchange mailboxes until prior to migration (in the Batch migration process) due to the Exchange free/busy limitation (as explained in chapter 1—see the Important note under Provisioning and mailbox creation for Office 365). If you create Exchange mailboxes earlier in this procedure, be aware that free/busy data for not-yet-migrated Notes users are unavailable until the users are fully migrated to Exchange. |
Conditional Step: This step applies only for migrations to an Exchange 2010 or later target environment, and is optional but recommended. |
Some migrations to Exchange 2010 or later have achieved improved throughput using a custom throttling policy. This topic is discussed in detail in this article.
© ALL RIGHTS RESERVED. Feedback Termini di utilizzo Privacy Cookie Preference Center