Migrator for Notes to Exchange 4.17 - Program Parameters Reference Guide

[ArchiveData] section

Determines whether the program will migrate calendar data among the archives. For example:

... tells the program to not migrate archive calendar data. By default (MigrateCalData=1), the program will migrate archive calendar data.

Determines whether the SSDM should attempt to migrate the encrypted portions of encrypted messages in the source user archives. This feature can also be applied to encrypted messages in the source server, by this same parameter name in the [ServerData] section of notesdtapp.ini. The feature is also available for the Data Migration Wizard (same parameters in the same sections, but in Migrator for Notes to Exchange's Global Defaults and Task Parameters), but in the wizard the default is 0.

The SSDM can migrate the encrypted portion of an encrypted message if it has the access credentials of the user who is authorized to decrypt the encrypted portion. This is the typical case in most organizations who use the SSDM, where individual users run the SSDM under their own login credentials, to migrate their own data. But in the rare case where the access credentials for a user's encrypted data are different from the credentials of the user running the program, this parameter lets you control how the SSDM should handle encrypted data. If the program attempts to migrate an encrypted message but lacks the necessary credentials, it can migrate the unencrypted portions, skip the encrypted portions, and insert text notices to explain that the encrypted portions could not be migrated. On the other hand:

… tells the SSDM to not even attempt migrating the encrypted portions, but to just migrate the unencrypted portions and insert the notice text. If MigrateEncryptedMessages=1, the program will attempt to migrate the encrypted portions, and will succeed or fail depending on whether the account running the SSDM has the necessary credentials. If it fails, the SSDM will migrate the message, skip the unencrypted portion and insert the notice—the same outcome as for MigrateEncryptedMessages=0.

A related Migrator for Notes to Exchange parameter lets you tell the SSDM to skip an entire message (both encrypted and unencrypted portions) if the program is already configured to skip the encrypted portion (only) by MigrateEncryptedMessages=0. See SkipEntireEncryptedMessage in this same [ArchiveData] section for more information.

This value corresponds to a GUI element in the SSDM: the Migrate archive check box of the Specify Data for Migration screen. The SSDM writes this value to notesdtapp.ini from the user's GUI entry; Quest recommends you do not manually enter or change this value except at the direction of Quest Support.

Determines whether the program will migrate task data among the archives. For example: MigrateTaskData=0 tells the program to not migrate archived tasks. By default (MigrateTaskData=1), the program will migrate archived tasks.

... tells the program to not migrate the trash folder if the Specify Data for Migration screen does not appear, or sets the associated check box in that screen to be unmarked by default. The default setting (MigrateTrashFolder=1) tells the program to migrate the trash folder if the screen does not appear, or sets the associated check box to be marked by default. The most common use of this parameter is to provide the necessary entry value when the program is configured to hide the Specify Data screen. Chapter 4 of the Migrator for Notes to Exchange Scenarios Guide explains how this parameter relates to others used to customize the SSDM.

Determines whether and how the SSDM will migrate archive items that occur within Notes views. For example: MigrateViews=1 tells the SSDM to migrate items only from the first view in which they are found. Valid parameter values are:

Note that the SSDM will initialize this parameter to 1 if it is omitted from notesdtapp.ini, even though technically the program default is 1. You must explicitly include the parameter in notesdtapp.ini if you want the SSDM to run with MigrateViews=0 or MigrateViews=2.

Determines whether the SSDM, when migrating archives to a different target folder, will add a keyword to the archive message that identifies the message’s original folder name. For example, a different target folder would include subfolders under a pseudo root (with [ArchiveData] UsePseudoRoot=1) as compared to the primary Outlook mailbox (the main root).

... tells the program not to add the keyword in the format of "Folder: ArchiveTitle\\OriginalFolderName" to the archive message when migrating it to a different target folder. By default (1), the program adds the keyword to the migrated archive message.

Determines whether the SSDM will skip entire encrypted messages (skip both encrypted and unencrypted portions) in the source user archives if the SSDM is already configured to skip the encrypted portions by MigrateEncryptedMessages=0 (also in this [ArchiveData] section).

… tells the program to skip any encrypted messages in their entirety if MigrateEncryptedMessages=0. This SkipEntireEncryptedMessage parameter is irrelevant and ignored if MigrateEncryptedMessages=1.

For more information about how encrypted messages are migrated, and how this SkipEntireEncryptedMessage parameter helps control how the SSDM processes encrypted messages, see the parameter notes for the MigrateEncryptedMessages parameter earlier in this [ArchiveData] section.

[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.

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

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

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

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

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

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

[ErrorsToIgnore] section

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

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.

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.

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.

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.

Applies to data being migrated to a PST file. It tells the program 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. You can disable this feature 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:

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

NOTE: if the Autodiscover service returns only a single URL, internal or external, that URL is used regardless of this setting.

Identifies the registered application client ID for the Microsoft Azure portal. This setting is updated by the Migration Console when the Apply button is clicked on the Exchange Server page after the user has performed an App Registration and successfully registered Migrator for Notes to Exchange with the Microsoft Azure portal.

To migrate oversized attachments or messages, this parameter is required when [Exchange] MigrateOversizedAttachments is enabled so the tool can access and upload large attachments to the OneDrive store owned by the mailbox user.

Specifies the method the SSDM uses to process a recurring meeting series that contains more occurrences in Notes than the 999 maximum allowed by Exchange. Without this control, attempts to migrate such meetings to Exchange 2010 would fail when the number of recurring instances exceeds 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 the following values:

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.

This parameter is used only when migrating using MNE MAPI/HTTP. For more information, see[Exchange] UseMneMapiHttpLib=<#> .

Tells the SSDM to check if the Notes items are already migrated to Exchange based on the folder level or mail store level. This parameter allows you to avoid creating duplicate items in Exchange by using the [Exchange] RemigrateMode parameter.

For example, the default (CheckMigratedItemsOnFolderLevel=1) tells the SSDM to check if the Notes Items have already been migrated based on the folder level. CheckMigratedItemsOnFolderLevel=0 tells the SSDM to check if the Notes Items have already been migrated based on the mail store level.

When connecting to the target mailbox, MNE must authenticate with the Exchange Server or Microsoft 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 Microsoft 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.

Enables or disables an option to extract images from Notes messages and replace and migrate the images as OLE Device Independent Bitmap object attachments -OR- migrate the original images to a OneDrive store. Original images are migrated to OneDrive when the following conditions are met:

This option makes images renderable in both OWA and the Office web client and is enabled by default (1). To disable the option, set ExtractEmbeddedImages=0.

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 run 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.

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

During migration, images that are extracted from emails are either converted to BMP images before being stored in Exchange as message attachments -OR- the original images are uploaded to the user's OneDrive store.

Converting an image to BMP format can result in an image that has a data size many times larger than the original image. Due to the technical limitations of 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 by emails that contain large embedded images, you can use the MaxExtractedImageArea setting to specify the maximum allowable image area, in pixels, of the generated BMP image. During the conversion, if the limit is exceeded, the embedded image is removed from the email body and is replaced with the original Notes image stored as a standard file attachment on the migrated message.

For example, to specify that images larger than 640 x 480 (307200) pixels should be removed from the email body and migrated as file attachments, set MaxExtractedImageArea=307200. However, if you set extracted images to be migrated to a OneDrive store, the parameter is ignored.

By migrating the source image in its original format and storing it in Exchange as a message attachment, the source image data compression is retained with no loss in image quality. Though the image is no longer displayed in the email body in Outlook or OWA, users can open the images from the email client to view the image content.

Original images are uploaded to OneDrive if the Migrate Oversized Attachments option is enabled for Microsoft 365 mailbox migration and the extracted image sizes exceed the limit specified by the [Filter] AttachSize parameter.

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

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 abandoned.

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 abandoned.

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 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 proceeds to the next message to be migrated.

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.

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.

Used only when migrating with the MNE MAPI/HTTP library, which is used when the [Exchange] UseMneMapiHttpLib parameter is set to the default setting of 1 as in [Exchange] UseMneMapiHttpLib=1.

Tells the SSDM whether to migrate an oversized message or an oversized message attachment when target is Microsoft 365. For example:

... tells the wizard to skip migrating the message attachment or the message that exceeds the size limit (such as 25 MB for message attachments or 150 MB for messages) to the Exchange Online target.

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

NOTE: The maximum size limit for attachments is set in the SSDM on the Select Date and Size Filters screen. You can modify the maximum attachment size on that screen but the size should not exceed the maximum attachment size allowed by Microsoft 365.

Determines whether MNE converts Notes RTF (rich text format) to HTML format when migrating a Notes message body in RTF. MNE uses a Notes built-in API to convert RTF to HTML. The feature is off (0) by default. The following limitations apply:

MNE will export Notes RTF to MS RTF if MNE fails to convert Notes RTF to HTML or the feature is disabled.

Some special Notes Databases contain a Topic field which works the same as the Category field (Keywords attribute) in Exchange. Currently the SSDM will migrate the Topic as Subject in Exchange causing multiple messages to have the same Subject value but it is actually the Topic value.

By default (MigrateTopicAsCategory=0), the SSDM does not change the logic as the source does not contain a Topic field in most cases, If you set this parameter to 1, the SSDM migrates the Topic as Category, and does not migrate the Topic as Subject. Quest recommends you enable the parameter only when you encounter the issue in which the Topic field is incorrectly migrated as Subject for a special Database.

Specifies the folder path relative to the mailbox user’s OneDrive store root to which oversized attachments will be uploaded. The folder name can be separated with / or \ but cannot contain any of the special characters (such as ~ " # % & * : < > ? / \ { | } that are not allowed by OneDrive.

If the specified folder path is found to be invalid when the SSDM is uploading oversized files, an error is logged and the store root is used as the target folder instead. By default, the SSDM uses Email_Attachments as the folder path for oversized attachments.

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

Tells the SSDM 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 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:

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:

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.

This setting applies to data being migrated to a server mailbox (either primary or archive). It tells the SSDM 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.

Tells the SSDM whether to migrate an oversized message attachment using a method that modern Outlook (Outlook 2016 or later) or an OWA client can render correctly or to revert to an attachment type that legacy Outlook 2013 or earlier can render.

The default value 0 migrates attachments for modern Outlook and value 1 migrates attachments in the way that legacy Outlook supports.

When migrating to on-premises Exchange or Microsoft 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.

NOTE: If errors occur during the parsing of the HTML, NME migrates the message with no modification.

UpdateHtmlWithMismatchedCharset=UTF-16

UpdateHtmlWithMismatchedCharset=US-ASCII

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 Microsoft 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 Microsoft 365 think that everything is proper, and prevents Microsoft 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 Microsoft 365, but it could potentially be introduced in a later update to on-premises Exchange.

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: