サポートと今すぐチャット
サポートとのチャット

Migrator for Notes to Exchange 4.16.3 - 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)

[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

 

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:

Type:

Default:

 

New in:

boolean

1 (on-premises) or 0 (Microsoft 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 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).

Type:

Default:

New in:

string

[none]

4.16.1

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.

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

Default: 0

New in ver 4.3

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.

Type:

Default:

New in:

boolean

1

4.16.1

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.

Type:

Default:

 

New in:

boolean

0

 

4.16.0

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.

Type:

Default:

 

New in:

boolean

1

 

4.11

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:

The [Filter] AttachSize parameter corresponds to the Attachment sizes filter on the “Specify Dates and Size Filters” page in the Migrate User Data wizard.

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.

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

Type:

Default:

 

New in:

integer

0

 

4.15.1.172

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.

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

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

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

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:

keyword (single digit 0 or 1)

0

4.16.1

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.

Type:

Default:

New in:

boolean

0

4.16.1

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.

Type:

Default:

New in:

boolean

0

4.16.0

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.

Type:

Default:

New in:

string

Email_Attachments

4.16.1

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.

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

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

Type:

Default:

Occurs in:

New in:

boolean

0

Data Migr

4.16.1

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.

Type:

Default:

 

New in:

string

[none]

 

4.15.1

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.

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

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.

[Filters] section

Type:

Default:

 

 

string

none

 

 

Each line specifies a folder name. The specified folder is excluded from the migration. For example:

[Filters]

Filter0=Folder1

Filter1=Folder2

Folders can be included or excluded by setting [Filters], [FolderTreeFilters], and [IncludeFoldersAndViews]. The precedence order is [Filters] > [IncludeFoldersAndViews] > [FolderTreeFilters].

If a folder is named in both the [Filters] section and the [IncludeFoldersAndViews] section, the [Filters] section takes precedence and the folder or view is not migrated.
If a folder is named in both the [IncludeFoldersAndViews] and the [FolderTreeFilters], the [IncludeFoldersAndViews] sections take precedence and the folder or view is migrated. Since the [FolderTreeFilters] section impacts the sub folders, the sub folders are still excluded if they are not named in the [IncludeFoldersAndViews].

[FolderTreeFilters] section

Type:

Default:

 

New in:

string

none

 

4.15.2

Each line specifies a folder name. The specified folder and all sub folders are excluded from the migration. For example:

[FolderTreeFilters]

Filter0=Folder1\sub1

Filter1=Folder2\sub1

Folders can be included or excluded by setting [Filters], [FolderTreeFilters], and [IncludeFoldersAndViews]. The precedence order is [Filters] > [IncludeFoldersAndViews] > [FolderTreeFilters].

If a folder is named in both the [Filters] section and the [IncludeFoldersAndViews] section, the [Filters] section takes precedence and the folder or view is not migrated.
If a folder is named in both the [IncludeFoldersAndViews] and the [FolderTreeFilters], the [IncludeFoldersAndViews] sections take precedence and the folder or view is migrated. Since the [FolderTreeFilters] section impacts the sub folders, the sub folders are still excluded if they are not named in the [IncludeFoldersAndViews].
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択