Migrator for Notes to Exchange 4.16.1 - Scenarios Guide

Configuring Migrator for Notes to Exchange performance for migration to Office 365

Migration to Office 365 uses the Internet to transport data which is slower and less reliable than local network connections. Migrator for Notes to Exchange offers several parameters to minimize timeouts when data transmission delays are encountered during a migration.

Quest recommends you set parameters as detailed in the following sections.

Migrator for Notes to Exchange lets you configure the Data Migration Wizard to retry MAPI calls to Exchange and/or Office 365 when issues occur. In some environments, MAPI communications/connectivity can be occasionally interrupted, which can lead to incomplete migration results. This feature controls MAPI retries when certain errors are encountered.

When you are using the default Quest MNE MAPI/HTTP library, the MAPI error retry feature is simplified. When you are using the legacy Outlook library, there are more parameters to configure. For information about when to use the Outlook MAPI/HTTP library, see the parameter [Exchange] UseMneMapiHttpLib in the MNE Program Parameters Reference Guide.

The retry algorithms for both libraries are described in the following sections.

The feature is configured by the MessageRetryWait parameter in the [Exchange] section of Task Parameters and Global Defaults:

If MNE encounters a MAPI API function that fails with a network or session connection related error, it attempts to recover using the following algorithm:

The feature is configured by the following program parameters in the [Exchange] section of Task Parameters and Global Defaults:

If MNE encounters a MAPI API function that fails with a network or session connection related error, it attempts to recover using the following algorithm:

For both the Quest MNE MAPI/HTTP library and the Outlook MAPI/HTTP library, depending on the Log level set in the Specify Run Information screen, retry attempts may appear in the program logs without any other documented errors or warnings.

For the Outlook MAPI/HTTP library, the default settings tell the wizard to retry a MAPI call that returns the error 80040115 or 80040125, to a maximum of three attempts at 10-second intervals.

IMPORTANT: If you set the MessageRetry parameters to values higher than the defaults, consider adjusting the WatchDogMinutes parameter as described in the next Important note that follows.

In the Migrator for Notes to Exchange Global Defaults, the WatchDogMinutes parameter:

... specifies the number of minutes of inactivity an Migrator for Notes to Exchange Wizard will wait before it concludes that a data connection has encountered a fatal error and ends the process. Migration to hosted platforms often generates more process timeouts than migration to a local server. This can cause problems particularly when migrating quantities of large messages (usually due to large attachments). Quest recommends using the default WatchDogMinutes=180 for connections to Office 365, to make the migration program “forgiving.” A substantially lower setting of WatchDogMinutes=30 might be better suited to migration to a local server, where shorter and higher-quality transmission paths make timeouts less common.

IMPORTANT: If you set the MessageRetry parameters to values higher than the defaults, consider adjusting the WatchDogMinutes parameter. 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 (MessageRetryCount x MessageRetryWait).

If you still encounter timeouts with a higher WatchDogMinutes value, you can disable the feature by setting WatchDogMinutes=0. Be careful with this option, however, because it tells the program to wait indefinitely for activity, rather than reporting a fatal error after some period of time.

Configure SetUserAccountControl and UserAccountControl

In the Global Defaults: If you intend to provision Office 365 from local AD (only), Quest recommends you set the following parameters:

Configuring Migrator for Notes to Exchange to accommodate Office 365 Wave 15 throttling

The 4.7 release of Migrator for Notes to Exchange (MNE) improved support for Microsoft PowerShell throttling in Office 365 Wave 15, and introduced two new program parameters pertaining to PowerShell connections for Wave 15. If you are migrating to O365 Wave 15, you can improve Migrator for Notes to Exchange performance by setting these two parameters in the [PowerShell] section of Global Defaults and Task Parameters:

Prepare customattrs.tsv file 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 wizard 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 applications can refer to the file to migrate the attributes.

This mapping file must be a Unicode (not ANSI) file named customattrs.tsv located 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 the notesdtapp.exe if you want to migrate Notes custom attributes using the SSDM. Both migrator applications can refer to this file to map the source attributes to free (unused) properties in the MAPI target mailboxes.

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.

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.

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

You can use the Microsoft MfcMapi.exe utility to view the property, and its value, if it has been created. (The utility is a free download from Microsoft; Google "mfcmapi" and visit the www.microsoft.com/downloads link.) Most problems in migrating custom attributes can be diagnosed by these quick tests:

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 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. 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 (such as Quest).