Migrator for Notes to Exchange 4.15.2

If a MAPI call fails with one of the errors listed in the MAPIErrorsToRetry list, the API call is made again after pausing for the number of seconds specified by MessageRetryWait. MNE keeps retrying for a maximum of MAPIRetryCount times.

If MNE cannot recover from the MAPI error by simply repeating the API call within the maximum number of retries, it attempts to close the MAPI session and open a new one.

If the attempt to open a new MAPI session fails, MNE waits for the number of second specified by MessageRetryWait and tries opening a new session again. MNE keeps trying to reconnect for a maximum of MaxSessionReconnectCount times.

If MNE cannot reconnect within the maximum number of reconnect attempts, it aborts the migration.

If MNE was able to open a new MAPI session (in step 2), it attempts to store the migration object again (i.e. message, task, folder, contact, etc.).

MNE attempts to migrate each object using the algorithm above up to a maximum of MessageRetryCount times. If MNE reaches the MessageRetryCount limit, it assumes that there is something wrong with the object itself and it proceeds to the next object to be migrated.

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 (shown in the sample above) 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 their defaults, consider also adjusting the WatchDogMinutes parameter as described in the next Important note below.

Note that the MAPIErrorsToRetry parameter may contain multiple error codes, separated by commas, as in this example:

MAPIErrorsToRetry=80040115,80040125

This example would tell the program to retry a MAPI call that returns either the default error 80040115 or 80040125. In most cases, the default errors alone should be sufficient.

•

WatchDogMinutes parameter

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

[General]
WatchDogMinutes=180

... specifies the number of minutes of inactivity an Migrator for Notes to Exchange Wizard will wait before concluding that a data connection has encountered a fatal error and aborting 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). We recommend 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 (see above) to values higher than their defaults, consider also 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 could 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


	Conditional Substep: This substep applies only if you will provision Office 365 from a local AD.

In Migrator for Notes to Exchange’s Global Defaults: If you intend to provision Office 365 from a local AD (only), Quest recommends you set these parameters as suggested here:

[Active Directory]
SetUserAccountControl=1
UserAccountControl=512

Configuring Migrator for Notes to Exchange to accommodate O365 Wave 15 throttling


	Conditional Substep: This substep applies only if you are migrating to Office 365 Wave 15.

The 4.7 release of Migrator for Notes to Exchange improved support for Microsoft's PowerShell throttling in O365 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 new [PowerShell] section of Global Defaults and Task Parameters:

•

Configurable limit for PowerShell connections: This parameter lets an admin specify a per-server limit for the number of concurrent PowerShell connections Migrator for Notes to Exchange can open. For example:

[PowerShell]
MaxPowerShellConnections=2

The parameter should be used to eliminate the possibility of Migrator for Notes to Exchange exceeding the PowerShellMaxTenantConcurrency allowed by Microsoft for the tenant. The default for this throttle is 9 simultaneous runspace connections (remote PowerShell). To calculate the recommended setting for MaxPowerShellConnections:

R / S

... where R is the number of simultaneous runspaces allowed by your tenant (9 by default), and S is the number of migration servers you will use. If the quotient is not a whole integer, round down to the next lower whole integer for the MaxPowerShellConnections parameter value. For example, if your limit is 9 runspaces and you intend to use one migration server, then 9/1 = 9, and MaxPowerShellConnections=9. Or for a 9-runspace limit with 2 migration machines: 9/2 = 4.5, so MaxPowerShellConnections=4.

The default MaxPowerShellConnections=0 is interpreted as "no limit," effectively turning off this limiting feature.

•

Configurable "wait" for idle remote PowerShell connections: This parameter lets an admin specify how long (in seconds) Migrator for Notes to Exchange will hold open an idle remote PowerShell connection before closing it. The default:

[PowerShell]
IdleConnectionTimeoutSeconds=30

... will be suitable for most environments. Note that this feature applies only to the duration of an idle state during a connection. Each command execution resets this timer to zero, so a series of commands with only short idle periods between commands could keep the connection open indefinitely. IdleConnectionTimeoutSeconds=0 would tell Migrator for Notes to Exchange not to wait (wait 0 seconds) for a second command after a first, so every PowerShell connection would close immediately after only one command.

Prepare customattrs.tsv file to migrate Notes custom attributes


	Conditional Substep: This substep applies only if you intend 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. Migrator for Notes to Exchange’s 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 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.

To create and prepare the customattrs.tsv file:

Use a text editor to open attrs.tsv, and save the open copy under the new name customattrs.tsv. Make sure you save customattrs.tsv as a unicode (not ANSI) file, in the folder(s) as noted above, and delete any data rows that may appear in the copy.

Enter a data row for each custom attribute you want to migrate, like this:

•

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 row(s) 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:

PS_PUBLIC_STRINGS
PS_MAPI
{hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh}

... where each "h" is a hexadecimal character, with letters uppercased.

If the TargetPropertySet value is PS_PUBLIC_STRINGS or PS_MAPI, 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.

Also, "PT_" may be prepended to any of the five types above, so valid values include PT_STRING, PT_MV_STRING, etc.

Save and close the updated customattrs.tsv file.

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


ID Attr1 Attr2 Attr3 Attr4 Attr5	SourceProperty EV26C5E2CCF2B9267C.ArchiveId EV26C5E2CCF2B9267C.ArchivedDate EV26C5E2CCF2B9267C.SaveSetId EV26C5E2CCF2B9267C.RetentionCategory EV26C5E2CCF2B9267C.HasAttachments	TargetPropertySet {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428} {D0F41A15-9E91-D111-84E6-0000F877D428}	TargetProperty Archive ID Archived Date Saveset ID Retention Category EVLotus_HasAttachments	TargetPropertyType STRING STRING STRING STRING STRING

Troubleshooting problems in migrating Notes custom attributes

You can use Microsoft’s MfcMapi.exe utility to view the property and its value, if they have 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:

•

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 row(s) 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.

About MAPI properties

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

Please select your product:

To serve you better, please complete the Purpose of your Chat:

Recommended Solutions for Your Problem

Migrator for Notes to Exchange 4.15.2 - Scenarios Guide

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

Configure SetUserAccountControl and UserAccountControl

Configuring Migrator for Notes to Exchange to accommodate O365 Wave 15 throttling

Prepare customattrs.tsv file to migrate Notes custom attributes