Chat now with support
Chat with Support

Welcome, Quadrotech customers to Quest Support Portal click here for for frequently asked questions regarding servicing your supported assets.

Migrator for Notes to Exchange 4.16 - Scenarios Guide

About the Migrator for Notes to Exchange documentation Scenarios overview Migration to a proprietary Exchange
Migration to a proprietary Exchange target Pre-migration preparations Batch migration process Post-migration activities
Migration to Microsoft Office 365
Pre-migration preparations Batch migration process Post-migration activities
SSDM (per-desktop) migration

Step 3: Install and configure the Migrator for Notes to Exchange software

The Getting Started section of the Migrator for Notes to Exchange Quick-Start Guide explains how to install Migrator for Notes to Exchange. The subtopics below describe particular configuration tasks that should be performed now, as part of the Migrator for Notes to Exchange configuration, before the first run of any Migrator for Notes to Exchange component application. (All but the first are optional or conditional.)

Consider also whether the MNE Self-Service Desktop Migrator (SSDM) will be used as part of your Migration Plan. If so, it should also be installed and configured.

IMPORTANT: Remember also that any antivirus software on the admin workstation must be configured to not scan the Quest program files directory or %temp% directory, or may simply be turned off prior to running any Quest admin application. (Although it may be restored after the program runs.) Migrator for Notes to Exchange 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.

Most of the features and Wizards of Migrator for Notes to Exchange require access to information stored in a central database on the SQL server. Most also require access to the Notes server, Exchange server, Active Directory, and the shared directories that contain the Self-Service Desktop Migrator and its log and status files, and admin application log files. Migrator for Notes to Exchange features and Wizards therefore need to know the pertinent server names, locations, configuration options, access credentials and so forth for the various servers.

These Default Settings should be entered now into Notes Migration Manager (the Migrator for Notes to Exchange "console"), before other Migrator for Notes to Exchange features or the wizards are used, so that the information will be available to them and need not be entered again. If the information is not entered now, upon installation, the features and Wizards will prompt for the values as needed, and most of them will have to be entered more than once—reentered for each feature and Wizard that needs them.

NOTE: Quest therefore recommends you visit 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 also let you schedule tasks to run at particular times on particular days. The Manage Scheduled Operations screen in Notes Migration Manager lets you revise these task-execution schedules. But the wizards and Manage Scheduled Operations screen manage only the scheduling of task runs as these schedules are saved in the SQL database, and a "scheduled" task does not execute by itself. Tasks are executed by the Migrator for Notes to Exchange Task Scheduler (qsched.exe).

The task scheduler is a separate command-line application that executes the scheduled Migrator for Notes to Exchange tasks. The program checks the SQL database to see whether any tasks have been scheduled to run since the last check, and then executes these tasks. You can manage the task scheduler as you would any other Windows service using the Windows Service Manager. Instructions for configuring a Windows service can be found at:

For more 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: Configure SetUserAccountControl and UserAccountControl parameters

Conditional Substep: This substep applies only if you will use Migrator for Notes to Exchange to create objects in the target AD.

If you will use Migrator for Notes to Exchange to create user objects in the target AD, use a text editor to add (or edit) these parameter settings in the Global Defaults:

The MNE Provisioning Wizard includes the ability to retry transmissions to Active Directory when issues occur. In some environments, transmissions to AD can be occasionally interrupted, which may lead to incomplete provisioning. If you expect your provisioning may be significantly affected by such issues, you can use a text editor to configure these features by program parameters in the [ActiveDirectory] section of Task Parameters and Global Defaults:


// integer (number of retries), default=3
// integer (seconds), default=15

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 will note the error in the log, skip the current message property or element, and move on to process the next item. Depending on the Log level setting (on the Specify Run Information screen), the retry attempts may 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 some values higher than their defaults, you should also consider adjusting the WatchDogMinutes parameter. WatchDogMinutes specifies the number of minutes (default=180) of inactivity the Data Migration Wizard will wait before concluding the connection has timed out and aborting 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: Prepare customattrs.tsv file to migrate Notes custom attributes

Conditional Substep: This substep 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 app knows which properties in the target correspond to which attributes in the source. The migration of custom attributes therefore requires that someone 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 in the default installation folder for the Data Migration Wizard (typically C:\Program Files\Quest\Migrator for Notes to Exchange), and also in the folder containing notesdtapp.exe if you want to migrate Notes custom attributes via the SSDM. Either or both 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.

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 folder(s) as previously mentioned. Delete any data rows that may appear in the copy.
ID: Name of the custom attribute—a unique string that distinguishes this row’s custom attribute from all others in the file.
IMPORTANT: If any data rows remain in the original attrs.tsv file, make sure 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:
If the TargetPropertySet value is PS_PUBLIC_STRINGS, the familiar GUID for the set named will be substituted for the string provided.
TargetPropertySet can be left blank, but in that case TargetProperty (see below) must be an integer property ID in the range 0x0000-0x7FFF.
TargetProperty: Name of the corresponding MAPI property in Exchange. A hexadecimal user-property value will be 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 will be reported in the log (search for "custom attr" in the log file).
If TargetPropertySet (above) is left blank, this TargetProperty value must be specified as a 16-bit integer in the range 0x0000-0x7FFF that is not already defined for some other MAPI property.
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.
Save and close the updated customattrs.tsv file.

For example, a typical customattrs.tsv file might look something like this:









Archive ID
Archived Date
Saveset ID
Retention Category


You can use the Microsoft MfcMapi.exe utility to view the property and its value, if they have been created. (The utility is a free download from Microsoft. You can search in Google for "mfcmapi" and visit the link.) Most problems in migrating custom attributes can be diagnosed by these quick tests:

Verify that the target property specified in the customattrs.tsv file does not already exist, and that the target property is in the correct format. See About MAPI properties below for more information about this.
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, make sure 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's 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's 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 happen to be used by MAPI. So these two examples cannot be used as target property values for message attributes since they are already used, although they may be used to map Notes contact attributes to Exchange.

A custom property can be unnamed or named.

If it is unnamed, you must select a 16-bit integer TargetProperty in the range 0x0001 to 0x7FFF that is not already in use by MAPI. Note that the following values are reserved by MNE:

If it is named, you can select any property-set GUID. If you select a property set that is already in use, you must choose a 32-bit integer or string ID that is not already in use in that property set. If you select a brand new property-set GUID, you need not worry about IDs already in use because there will not be any.

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-").

Step 4 (if mail routing by domain differentiation): Configure mail routing domains

Conditional Step: This step applies only if you will configure email coexistence by temporary routing domains (domain differentiation in DNS) during the migration. If you will instead use smart hosts for mail routing (or will not configure mail routing at all), skip ahead to step 5.

Whether you are implementing SMTP mail connectivity only or complete coexistence with Quest CMN, most migrating organizations use temporary SMTP domains to route traffic between Notes and Exchange. Other administrators prefer to configure SMTP mail routing with smart host servers, for single-namespace environments. In either case, the routing method must be configured at both the server and user levels. At the user level, Notes person documents and AD object records are configured later in this procedure, when provisioning the target AD and synchronizing the two directories.

Notes-to-Exchange mail routing is configured so that new mail in Notes, both external inbound mail and internal mail from not-yet-migrated Notes users, can be correctly routed to already-migrated recipients in Office 365. The Notes-to- Exchange routing domains therefore must be configured (but not yet activated) before the first user collection is migrated to Exchange. The forwarding rules will then be activated for each user collection as that collection is migrated.

External inbound mail can be switched (by MX record) to arrive in Exchange instead of Notes at any time after mail-enabled objects have been provisioned into AD—before, during or after the actual migration. Many admins prefer to minimize change before and during the migration process, so they update the MX record only when the migration is complete. Others prefer to minimize the forwarding "hops" by switching about halfway through the migration process. And some make the switch as soon as the target AD objects are mail-enabled.

Whenever the DNS switch occurs, the Notes routing domains (for Exchange-to- Notes mail routing) must be configured before the switch, so Exchange can route mail for not-yet-migrated recipients to their Notes mailboxes.

The routing domains may be subdomains of the primary domain (e.g., and or completely separate SMTP domains. As long as they are unique to the respective mail systems, they will suffice for routing purposes. To configure subdomains:

If appropriate SMTP domains are not already available, create them in DNS. One should direct traffic to Exchange (e.g., Mail sent to the Notes mailboxes of migrated users will be forwarded to the corresponding mailboxes in Exchange using the domain. The other SMTP domain (e.g., may be used to route mail back to Notes for users who have not yet migrated.
After configuring the new domain in DNS, configure Exchange to accept the SMTP domain, and create a recipient policy to generate appropriate secondary SMTP addresses, so all Exchange users will be able to receive mail at this domain.
Configure Notes to accept mail to the new SMTP domain/address.

Step 5 (optional): Configure coexistence strategy

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 ahead to step 6.

Configure your coexistence strategy:

For complete coexistence with Quest CMN: Refer to the CMN documentation to install and configure the desired components (Directory Connector, Free/Busy Connector, and/or Mail Connector). If applicable, Directory Connectors should be created and run to update Domino and Active Directory with routing objects corresponding to the users in the other system (to establish complete directories).
IMPORTANT: If you have existing mail-enabled objects in AD, enable the Migrator for Notes to Exchange Compatability Mode for the CMN Directory Connector(s) 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 CMN User Guide for much more information.
For SMTP mail routing (without CMN): If you have not already tested mail flow to verify the subdomains you configured in the preceding step, do it now.

Be sure to define 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.
Add a Foreign SMTP Domain for the mail server. On the Routing tab:
Set Internet Domain to the name of the Exchange subdomain.
Set Internet Host to the IP of the Internet host.
NOTE: Remember, these procedures do not create users’ Exchange mailboxes until just prior to their 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 choose to create Exchange mailboxes earlier in this procedure, be aware that free/busy data for not-yet-migrated Notes users will be unavailable until the users are fully migrated to Exchange.

Step 6 (for Exchange 2010 or later target): Configure throttling policy

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 greater detail in this article.

Related Documents