Chat now with support
Chat with Support

Migrator for Notes to Exchange 4.16 - Program Parameters Reference Guide

About the Migrator for Notes to Exchange documentation Introduction Parameters for Admin Components Parameters for the Self-Service Desktop Migrator (SSDM)

[Categories] section

These [Categories] parameters are all auto-set parameters (see GUI-set and other “auto-set” parameters) that define the Outlook categories that correspond to various English equivalents. The Setup program automatically sets these parameters to their English defaults. If a default is not correct for your locale, be sure to change it before you run the SSDM.

Type: string

Default: Clients

 

See the explanatory note at the beginning of this [Categories] section. The English equivalent (default) for this parameter is: C=Clients

Type: string

Default: Holiday

 

See the explanatory note at the beginning of this [Categories] section. The English equivalent (default) for this parameter is: H=Holiday

Type: string

Default: Projects

 

See the explanatory note at the beginning of this [Categories] section. The English equivalent (default) for this parameter is: P=Projects

Type: string

Default: Phone Calls

 

See the explanatory note at the beginning of this [Categories] section. The English equivalent (default) for this parameter is: PC=Phone Calls

Type: string

Default: Travel

 

See the explanatory note at the beginning of this [Categories] section. The English equivalent (default) for this parameter is: T=Travel

Type: string

Default: Vacation

 

See the explanatory note at the beginning of this [Categories] section. The English equivalent (default) for this parameter is: V=Vacation

[ErrorsToIgnore] section

Type: keyword

Default: [none]

 

Each Error<#> parameter identifies a single particular runtime error that the program should ignore when documenting its activities and outcomes in its log file. Each parameter value:

For example:

The digit(s) appended to an Error<#> key name arbitrarily differentiate one parameter from another. Multiple Error<#> parameters need not appear in numerical order, need not form an uninterrupted numeric sequence, and need not begin at 0. But the SSDM will read only Error<#> parameters whose differentiating digits are within the range 0-99 inclusive.

[Exchange] section

Type: boolean

Default: 1

New in ver 4.15.1.315

When the SSDM migrates an archive to a PST file, the SSDM by default registers the PST file in the Outlook profile that was selected for the migration. To prevent the generated PST file from being registered in the Outlook profile, set this parameter to 0.

Type:

Default:

 

New in:

boolean

1

 

4.15.1

In Notes and iNotes, when users set a task reminder to X days, hours, minutes before or after the task start date, the alarm notification is triggered X days, hours, minutes before or after 12:01 PM of the task start date.

When this parameter is set to the default value (1), after migration the alarm notification is triggered X days, hours, minutes before or after 12:00 AM instead of 12:01 PM.

To retain the Notes task alarm behavior and trigger the alarm before or after 12:01 PM, set this parameter to 0.

Type: boolean

Default: 1

New in ver 4.4.1

Determines whether HTML information in the Description field of calendar appointments and tasks will migrate. The default:

… tells the SSDM to migrate such information. The feature can be disabled by AllowHTMLCalendarBodies=0.

Type: boolean

Default: 0

 

Tells the SSDM whether to automatically write the display names of Notes' email 2 and email 3 in the form Display Name (SMTP Address)— e.g., Joe Example (joeex@email.com). This feature, intended to make the type-ahead feature easier to use, can be enabled by

… but is off (0) by default.

Type: boolean

Default: 1

 

This setting applies to data being migrated to a PST file. It tells the Data Migration Wizard to do an Exchange GAL lookup of attendees of migrated items to retrieve their Exchange addresses. Successfully resolved attendees are migrated to the target using their Exchange addresses instead of their SMTP addresses. This is required for free-busy lookups to succeed.

This feature can be disabled by setting the parameter to 0. For example, to migrate data to PST files without connecting to the Exchange server, set:

... and also, in the [General] section:

Type:

Default:

 

New in:

boolean

1 (on-premises) or 0 (Office 365)

 

4.16.0

The Exchange Autodiscover service can return two sets of URLs in its query responses:

If this parameter is not configured, MNE selects the URL that is appropriate to the location of the mailbox. If the mailbox is on an on-premises Exchange server, MNE gives preference to the internal URLs. If the mailbox is an online mailbox in Office 365, MNE gives preference to the external URLs.

The default behavior can be overridden by setting this parameter to 1 (prefer internal URL) or 0 (prefer external URL).

Type: keyword (single digit 0, 1 or 2)

Default: 0

New in ver 4.3

Specifies the method the SSDM should use to process a recurring meeting series that contains more occurrences in Notes than the 999 maximum allowed by Exchange. Without this new control, attempts to migrate such meetings to Exchange 2010 would fail when the number of recurring instances exceeded the Exchange maximum. For example:

... tells the SSDM to convert the item to a recurring series with no end date, which migrates cleanly.

The parameter value is a keyword that must be one of these single digits:

A migrated appointment will appear in Outlook with the same number of occurrences as in Notes, until the recurrence pattern is edited by the user, at which time it will assume the option set by this parameter.

Specifies the method the SSDM should use to process a recurring meeting series that contains more occurrences.

Type:

Default:

 

New in:

boolean

0

 

4.16.0

When connecting to the target mailbox, MNE must authenticate with the Exchange Server or Office 365. MNE automatically selects the correct type of authentication to use based on the authentication mechanisms that are enabled on the server. If the server supports Modern Authentication, it is selected as the preferred authentication mechanism.

Disable Modern Authentication by setting DisableModernAuthentication=1. When disabled, MNE will fall back on another one of the mechanisms supported by the server (e.g. Basic Authentication).

Modern Authentication is primarily used when migrating to Office 365. Microsoft does support using Modern Authentication with on-premises Exchange servers in a Hybrid Authentication configuration. However, MNE has not been validated for use with Hybrid Authentication. If you run into issues, you may need to disable Modern Authentication using this parameter.

Type:

Default:

 

New in:

boolean

1

 

4.11

Enables or disables the option of extracting images from Notes messages and replacing them with OLE Device Independent Bitmap object attachments. This option makes images renderable in both OWA and the Office web client, and also improves image compression by a factor of two. The feature is enabled by default (1), or set ExtractEmbeddedImages=0 to disable it.

If the OLE Device Independent Bitmap uses significantly more storage than the original source image, you may be able to reduce the storage requirements by using the parameter MaxExtractedImageArea.

Type:

Default:

 

New in:

integer

The value specified by the [Exchange] MessageRetryCount parameter

 

4.15.1.257

This parameter is used only when migrating using Outlook MAPI. Most migrations will use the MNE MAPI/HTTP library instead. For more information, see [Exchange] UseMneMapiHttpLib=<#> .

Determines the number of additional attempts that MNE will make to recover from a MAPI API function that fails with one of the errors listed in the MAPIErrorsToRetry parameter. If a MAPI retry error occurs, MNE waits for the amount of time specified by the MessageRetryWait parameter, and attempts to execute the MAPI API function again.

If the API function continues to fail and returns MAPI retry errors, once the MAPIRetryCount limit is reached MNE makes a new attempt to store the message using a new MAPI session, as described by the MessageRetryCount parameter.

If this parameter is not set, it defaults to the value that is specified by the MessageRetryCount parameter.

Type:

Default:

 

New in:

integer

0

 

4.15.1.172

This setting is applied when [Exchange] ExtractEmbeddedImages is enabled.

During migration, images that are extracted from emails are converted into BMP images before being stored in Exchange as message attachments. Converting an image to BMP format can often result in an image whose data size is many times larger than the original image. Unfortunately, due to technical limitations of the RTF format, it is not possible to use other, more efficient image formats that support data compression.

To mitigate the impact to the target mailbox size of emails that contain large embedded images, the MaxExtractedImageArea setting can be used to specify the maximum allowable image area, in pixels, of the generated BMP image. During the conversion, if the limit would be exceeded, the embedded image is removed from the body of the email and it is replaced with the original image from the Notes source stored to the migrated message as a standard file attachment.

For example, to specify that all images lager than 640 x 480 (307200) pixels should be removed from the email body and migrated as file attachments, set MaxExtractedImageArea=307200.

By migrating the source image in its original format, the source image’s data compression can be retained with no loss in image quality. While the image will no longer be displayed in the body of the email in Outlook or OWA, it is still possible to open the images from the email client to view the content of the image.

When MaxExtractedImageArea=0, the image is migrated to Exchange with no size limit applied.

Type:

Default:

 

New in:

integer

5

 

4.16.0

When MNE fails to connect to the target mailbox due to an error that might be transient (such as a network communication fault), MNE will make additional attempts to connect to the target mailbox. This parameter imposes a limit on the amount of time that MNE will spend retrying to open the connection.

The maximum time is specified in minutes. If the connection cannot be established within the amount of time specified, the migration to the target mailbox will be aborted.

Type:

Default:

 

Updated in:

integer

20

 

4.15.1.257

This parameter is used only when migrating using Outlook MAPI. Most migrations will use the MNE MAPI/HTTP library instead. For more information, see [Exchange] UseMneMapiHttpLib=<#> .

Determines the maximum number of times that MNE will attempt to reconnect the MAPI session if a message fails to migrate due to one of the errors that are specified by the MAPIErrorsToRetry parameter. MNE pauses between each reconnect attempt for the number of seconds specified by the MessageRetryWait parameter.

If MNE is unable to open a new MAPI session after MaxSessionReconnectCount attempts, the migration is aborted.

Type:

Default:

 

Updated in:

integer

2

 

4.15.1.257

This parameter is used only when migrating using Outlook MAPI. Most migrations will use the MNE MAPI/HTTP library instead. For more information, see [Exchange] UseMneMapiHttpLib=<#> .

If a message fails to migrate due to one of the MAPI errors specified by the MAPIErrorsToRetry parameter, this parameter determines the maximum number of additional attempts that MNE will make to store the message. When MNE fails to store a migrated message to the target mailbox due to a MAPI retry error, MNE closes the existing MAPI session, opens a new session, and then attempts to store the message again.

If MNE is unable to open a new MAPI session, it continues to make additional attempts to connect with MAPI, as described by the MaxSessionReconnectCount parameter. MNE pauses between each reconnect attempt for the number of seconds specified by the MessageRetryWait parameter.

If MNE is able to successfully open new MAPI sessions, but attempts to store the message continue to fail and the MessageRetryCount limit is reached, MNE logs the MAPI error and the failure to migrate the current message. MNE then proceeds to the next message to be migrated.

Type:

Default:

 

New in:

integer

30

 

4.6

Sets the delay (in seconds) between retry attempts for MAPI API functions that fail with one of the errors specified by the MAPIErrorsToRetry parameter, as documented by the MAPIRetryCount parameter.

The parameter also specifies the delay (in seconds) between MAPI session reconnect attempts, as documented by the MessageRetryCount parameter.

Type: boolean

Default: 1

New in ver 4.13

Determines whether the SSDM will migrate the FYI attendees of a Notes meeting to the bcc field in Exchange, where they will appear as Resources, instead of to the cc field. This option keeps FYI attendees hidden if the organizer later changes the meeting, since Exchange sends notifications of such changes, and those notices would otherwise disclose the FYI attendees as Optional Attendees.

By default (MigrateMeetingFYIAsResource=1), the SSDM migrates FYI attendees of a Notes meeting to the bcc field in Exchange. You can disable the feature (0) to make the SSDM migrate FYI attendees to the cc field.

Type:

Default:

 

New in:

integer

30 (minutes)

 

4.16.0

This parameter replaces the obsolete [PowerShell] PropagationDelay parameter. It specifies the maximum number of time (in minutes) to keep retrying mailbox logons when the logon fails with an Access Denied error.

When migrating to Office 365, MNE checks at the beginning of the migration to ensure that the migration account has Full Access rights on the target mailbox. If it does not, MNE uses PowerShell to grant access. It is common for there to be a delay between granting these permissions and the logon to the target mailbox succeeding. Occasionally, this delay can be significant, taking many minutes for the permission change to take effect.

When MNE logs onto an Office 365 mailbox, if the logon fails with a permission denied error, MNE automatically retries the logon after 30 seconds. It keeps retrying the logon every 30 seconds until the logon succeeds, or the O365MaxMailboxConnectionWaitTime has been exceeded.

Type: boolean

Default: 0

 

... tells the SSDM to clear the contents of Personal Address Books in Exchange before migrating corresponding PABs from Notes—useful if, for example, you had already migrated PABs, but then wanted to migrate them again. The default PurgePABS=0 disables the feature, so no PABs are cleared. This feature clears only Exchange PABs that correspond to Notes PABs about to be migrated, and will not clear any other existing Exchange PABs.

keyword (single digit 0, 1 or 2)

Default: 1

New in ver 3.2

Tells the Data Migration Wizard which of two methods to use, to avoid creating duplicate items in Exchange when an item that has already been migrated to Exchange is queued to migrate again. For example:

... tells the wizard to delete the Exchange copy of the item and then remigrate it from Notes.

The parameter value is a single-digit integer, which must be one of these three valid values:

The RemigrateMode parameter also impacts how folder permissions are migrated when a mailbox is migrated again. The following rules apply to the migration of folder permissions regardless of the RemigrateMode parameter setting and how many times the migration has been performed:

The RemigrateMode parameter affects the migration of folder permissions in scenarios where a user exists in both the Notes mail file ACL AND the Exchange Folder ACL. The RemigrateMode setting values affect the migration as described below:

Type: keyword

Default: 0

 

A single digit, 0–7, that specifies which (if any) of migrating mail, appointment and task items the SSDM should pass through Microsoft’s rich-text converter—which in many cases will refine the exported compound document format from Notes’ own converter. The parameter value must be one of these digits:

0: None
1: Mail Only
2: Appts Only
3: Mail + Appts

4: Tasks Only
5: Mail + Tasks
6: Appts + Tasks
7: Mail + Appts + Tasks

Type:

Default:

Occurs in:

New in:

integer

3

Data Migr

4.16.0

When migrating mailbox content, MNE also migrates mail file permissions to the folders within the target mailbox. The permissions are migrated to provide equivalent access in Exchange depending on the type of data contained within the folder. For example, mail folders are assigned permissions equivalent to the access granted to mail data in the source mail file.

Outlook provides a mechanism for opening up folders within other user’s mailboxes. This mechanism only requires access to be granted on the specific folder being opened. For example, to view another mailbox’s Inbox, a user only requires access to the Inbox within that mailbox. However, this mechanism is limited to specific well-known folders, such as the Inbox, Calendar, etc.

To browse other custom folders within another user’s mailbox, you must add the target mailbox to the Outlook Profile. Browsing the folders in this manner only works if permissions are granted on the mailbox’s root folder. Since the root folder does not contain any specific content, it is difficult to determine exactly what level of permissions to grant users on the root folder. There are pros and cons to each approach. This setting can be used to select the approach that is appropriate for each customer’s needs. The following values are supported for this parameter.

None (0): Don’t migrate any permissions to the Root folder. Users can only open specific well-known folders in mailboxes to which they have access using the Outlook Open User’s Folder feature.
Set Folder Visibility Only (1): Users who have access to any kind of content within the Notes mail file are granted Folder Visibility rights on the root folder in the target mailbox. This allows users to browse the folder structure of the root folder. However, the users can only access the content of the child folders to which they’ve been granted access. The downside of this approach is that any folders that are created directly under the root folder after the migration inherit the permissions of the root folder. This could lead to some users having limited access to some of the content within the mailbox. For example, a user who should have access to email content would be able to access the mail folders that were created during migration, but would not have access to the content of mail folders that were created after the migration. Conversely, users that have access to calendar/task/contact data only in the source mail file can view the folder structure of these newly created mail folders. However, they cannot view the content of these new mail folders.
Mail Folder Permission Only (2): MNE configures the permission on the root folder to match all other mail folders (such as the Inbox). The advantage of this approach is that users who have access to email have all of the access that they need in the target mailbox on folders that are created during the migration and also on folders that are created directly under the root folder after the migration (since those folders inherit their permissions from the root folder). The one disadvantage is that users who only have access to calendar/task/contact data can only access that data using Outlook’s Open User’s Folder feature. They cannot browse the mailbox content from the root folder.
Combined Permissions (3): MNE combines the behavior of the previous two settings. Users who have access to mail content are granted equivalent access to the root folder. Users who have access to calendar/task/contact data are granted Folder Visibility permissions on the root folder. There are numerous benefits to this approach. All users who have access to any kind of content can browse the folders of the target mailbox from the root of the mailbox. Users with access to mail content are assured to have access to folders created during the migration and those that are created directly under the root folder after the migration. The one minor downside of this approach is that because folders that are created directly under the root folder after the migration inherit the permission of the root folder, users who have access to calendar/task/contact data are only granted Folder Visibility permissions on those folders. This does not grant these users access to the content within these folders. However, they can view the folder structure under these folders, granting them slightly more access than intended.

Type: boolean

Default: 1

 

This setting applies to data being migrated to a server mailbox (either primary or archive). It tells the Data Migration Wizard to do an Exchange GAL lookup of attendees of migrated items to retrieve their Exchange addresses. Successfully resolved attendees are migrated to the target using their Exchange addresses instead of their SMTP addresses. This is required for free-busy lookups to succeed.

This feature can be disabled by setting the parameter to 0.

Type:

Default:

 

New in:

string

[none]

 

4.15.1

When migrating to on-premises Exchange or Office 365 targets, MIME encoded HTML emails may not display correctly in the email client if there is a mismatch between the character encoding declared in the HEAD element of the HTML message and the character encoding declared in the MIME headers. When a mismatch occurs, the message displays as garbled text.

To correct this issue, enable the parameter by specifying the character set used by the HTML HEAD element that is causing a problem. For example:

UpdateHtmlWithMismatchedCharset=UTF-16

When the parameter is enabled, MNE checks for the character set in the HTML HEAD element and when found, the character set is replaced with the MIME header character set.

The parameter is disabled by default. Only enable the parameter if corrupted characters are observed in migrated messages.

UpdateHtmlWithMismatchedCharset=UTF-16

message 1

UTF-8

UTF-16 changed to UTF-8

message 2

UTF-8

US-ASCII (unchanged)

UpdateHtmlWithMismatchedCharset=US-ASCII

message 1

UTF-8

UTF-16 (unchanged)

message 2

UTF-8

US-ASCII changed to UTF-8

Type:

Default:

 

New in:

boolean

0

 

4.13

MIME encoded HTML emails often have the charset encoding declared in two places. The first is within the MIME headers and the second is within the HEAD element of the HTML message itself. With properly formatted emails, these two charset declarations are identical. Some HTML emails have been found where the charset declaration in the MIME headers and the charset declaration in the HTML message do not match. Typically in these cases, the HTML charset declaration is not in the HEAD element where it is expected, but instead it appears later in the document, possibly in the BODY element. While these emails may not be technically valid, they are still handled properly by most email clients.

A new behavior has been observed in Office 365 where the Exchange server attempts to correct the discrepancy in the charset declarations by removing the HTML charset declaration that conflicts with the MIME header charset declaration, and inserting a new HTML charset declaration in the HEAD element that matches the charset of the MIME header. In these cases the charset declaration will no longer match the encoding of the HTML body and as a result, non-ASCII characters are corrupted in the rendering of the email message.

To correct this issue, enable the UpdateHtmlWithMissingCharset option. With this option enabled, MNE checks for the presence of a charset declaration in the HTML HEAD element during the migration process. If missing, NME inserts a charset declaration using the charset value from the MIME message header. While this charset declaration may not match the encoding of the message, it makes Office 365 think that everything is proper, and prevents Office 365 from removing the correct charset declaration that appears later in the document. The second charset declaration in the body overrides the newly inserted one that is declared in the HEAD element. As a result, the email message renders properly in the email client.

If any parsing errors occur during the parsing of the HTML, NME migrates the message with no modifications.

This option is off by default. This option adds some minimal overhead to the migration process. It should only be enabled if corrupted characters are observed in the migrated messages.

The issue has only been observed when migrating to Office 365, but it could potentially be introduced in a later update to on-premises Exchange.

Type:

Default:

Occurs in:

New in:

boolean

1

Data Migr

4.16.0

MNE no longer uses Outlook MAPI to write data to the target server mailbox. Quest has created its own library that implements Microsoft’s MAPI/HTTP protocol. This library has many advantages over Outlook MAPI and it is now used in almost all migration scenarios that target server mailboxes.

There are limited scenarios where the MNE MAPI/HTTP library is not used:

Use this parameter to force MNE to revert back to using Outlook MAPI to perform the migration. Quest strongly recommends that customers not do this unless directed by Quest support personnel.

The parameter to use the MNE MAPI/HTTP library is enabled by default so parameters that use Outlook MAPI are not used during migration. The parameters that are only used by Outlook MAPI are as follows:

[Filter] section

Type: integer

Default: 20480 for O365 target, or otherwise none

 

This value specifies the max size limit for attachments—that is, the program will migrate only attachments that are smaller than the size designated here, in KB. For example: AttachSize=8000 tells the program to not migrate attachments larger than 8000 KB.

Type: date

Default: [GUI entry]

New in ver 4.5

This value corresponds to a GUI element in the SSDM: the Migrate only calendar data ... dated on or after field in the Select Date and Size Filters screen, which specifies the earliest items that the program will migrate (will migrate only items that are timestamped on or after the designated date). The SSDM writes this value to the Task Parameters from the user's GUI entry; Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Type: date

Default: NONE

New in ver 4.5

This parameter specifies the earliest items that the program will migrate (items that are timestamped on or after the designated date). When set to NONE, all mail and calendar items are migrated.

Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Type: date

Default: [GUI entry]

New in ver 4.5

This value corresponds to a GUI element in the SSDM: the Migrate only messages ... dated on or after field in the Select Date and Size Filters screen, which specifies the earliest items that the program will migrate (will migrate only items that are timestamped on or after the designated date). The SSDM writes this value to the Task Parameters from the user's GUI entry; Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Type: date

Default: [GUI entry]

New in ver 4.5

This value corresponds to a GUI element in the SSDM: the Migrate only calendar data ... dated on or before field in the Select Date and Size Filters screen, which specifies the latest items that the program will migrate (will migrate only items that are timestamped on or before the designated date). The SSDM writes this value to the Task Parameters from the user's GUI entry; Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Type: date

Default: NONE

New in ver 4.5

This parameter specifies the latest items that the program will migrate (items that are timestamped on or before the designated date). When set to NONE, all mail and calendar items are migrated.

Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Type: date

Default: [GUI entry]

New in ver 4.5

This value corresponds to a GUI element in the SSDM: the Migrate only messages ... dated on or before field in the Select Date and Size Filters screen, which specifies the latest items that the program will migrate (will migrate only items that are timestamped on or before the designated date). The SSDM writes this value to the Task Parameters from the user's GUI entry; Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Related Documents