Chatee ahora con Soporte
Chat con el soporte

Migrator for Notes to Exchange 4.16.1 - Administration Guide

About the Migrator for Notes to Exchange documentation Notes Migration Manager NABS Discovery Wizard Internet Domains Discovery Wizard Directory Export Wizard Collection Wizard Groups Provisioning Wizard Notes Data Locator Wizard Provisioning Wizard Send PAB Replicator Wizard Data Migration Wizard SSDM Statistics Collection Wizard The Log Viewer Using the Qsched.exe task-scheduling utility SSDM Scheduling Administration utility Office 365 Admin Account Pool utility PowerShell cmdlets for Migrator for Notes to Exchange Appendix A: How do I ...?
Post-installation configuration Pre-migration preparations Batch-migration process Other features

How do I specify per-user locations for Notes source data?

Per-user locations for users’ source data are (if necessary) specified in the SQL database. To edit the contents of that database, you must export the data to a .tsv (tab-separated-values format) file, then edit the contents of the table, and then import the edited .tsv file back into the SQL database.

For PABs: To designate the locations of user PABs, enter the appropriate per-user values into one of these columns (not both):

PABPaths column: The specific UNC path and filename for a user's Notes address book(s). Multiple address books can be designated by separating them with a pipe ( | ) character. Ordinarily the full path and file name are given, and file ownership is not checked. If a directory (only) is specified, all PABs found in the directory are assumed to be owned by the user. Examples:
SharedPabDirs column: A file system directory or Notes server directory that contains NSF files for multiple users. This column can be used to specify a more specific set of directories to scan for a user's data, so the application can scan a subset of a larger shared directory structure and determine the owner based on profile documents and/or ACLs. This is useful if a group of users to be migrated shares a directory structure and you can't be certain that all address books belong to one user. If a file system path is specified here, ownership is checked based on the profile documents and/or ACLs. Examples:

For Archives: To designate the locations of user archives, enter the appropriate per-user values into one of these columns (not both):

ArchivePaths column: The specific UNC path and filename for a user's Notes archive file(s). Multiple archives can be designated by separating them with a pipe ( | ) character. Ordinarily the full path and file name are given, and file ownership is not checked. If a directory (only) is specified, all archives found in the directory are assumed to be owned by the user. Examples:
SharedArchiveDirs column: A file system directory or Notes server directory that contains NSF files for multiple users. This column can be used to specify a more specific set of directories to scan for a user's data, so the application can scan a subset of a larger shared directory structure and determine the owner based on profile documents and/or ACLs. This is useful if a group of users to be migrated shares a directory structure and you can't be certain that all address books belong to one user. If a file system path is specified here, ownership is checked based on the profile documents and/or ACLs. Examples:

For Mail Files: To specify per-user locations and filenames for users’ source mail files in the SQL database rather than from entries in the Data Migration Wizard, enter the appropriate per-user values into this column:

MailFilePath column: The specific path and NSF filename to a user's mail file, used when an administrator knows the specific path and NSF file name for each user. Example:
If the MailFilePath column does not exist or is left empty, the program will look for the user's mail file in the path entered in the Notes Data Locator Wizard (on the Specify Notes Mail File Directories screen).

How do I specify per-user destination locations for users' PST files?

Per-user destination locations for users’ new PST files are (if necessary) specified in the SQL database. To edit the contents of the SQL database, you must export the data to a .tsv (tab-separated-values format) file, then edit the contents of the table, and then import the edited .tsv file back into the SQL database.

To specify per-user destinations for users’ new PST files in the SQL database rather than from entries in the Data Migration Wizard, enter the appropriate per-user values into this column:

PSTdir column: The directory where PSTs are stored for the user, used if each user's PST will go to a separate directory. Normally the admin would specify a central location for the wizard to create all PSTs, and the wizard would create a subtree under that. If the admin would rather put each PST in each user's home directory, then each user's home directory can be added here. Example:

How do I specify whether to migrate to a single PST file (per user) or multiple PST files?

When migrating to .pst files, a program parameter in the Global Defaults and Task Parameters lets you specify whether the Data Migration Wizard should migrate all data into a single .pst file per user, or to multiple .pst files. The boolean parameter that controls this option is UseSeparatePSTs. By default (1), data is migrated to multiple .pst files. But:

... tells the wizard to migrate all data into a single .pst file per user.

If you are unfamiliar with the procedure to edit program parameters, see How do I add or edit program parameters? elsewhere in this Appendix.

How do I migrate Notes custom attributes?

A Notes message contains several standard attributes such as the From, To and Subject fields, and can also include user-defined fields. The 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 application knows which properties in the target correspond to which attributes in the source. The migration of custom attributes requires that the source-to-target attribute associations be mapped in a tsv data file before the migration so that Migrator for Notes to Exchange (MNE) can refer to the file to migrate the attributes.

The attribute-mapping file must be a Unicode (not ANSI) file named customattrs.tsv located in the default installation folder for the Data Migration Wizard (typically C:\Program Files\Quest\Migrator for Notes to Exchange), or in the folder containing notesdtapp.exe if you want to migrate Notes custom attributes via the SSDM. MNE 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.

1
Use a text editor to open attrs.tsv, and save the open copy under the new name customattrs.tsv. Ensure you save customattrs.tsv as a unicode (not ANSI) file, in the folder(s) as previously specified. Delete any data rows that may appear in the copy.
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 rows remain in the original attrs.tsv file, ensure that no ID value in customattrs.tsv is the same as any ID value in attrs.tsv. Custom attributes will not migrate correctly if any ID value appears in both files.
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:
If the TargetPropertySet value is PS_PUBLIC_STRINGS, 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 following) 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 is 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 are 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: Data type of the MAPI property, which must logically correspond to the data type used in Notes. Valid values are:
3
Save and close the updated customattrs.tsv file.

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

ID

SourceProperty

TargetPropertySet

TargetProperty

TargetPropertyType

Attr1
Attr2
Attr3
Attr4
Attr5

ArchiveId
ArchivedDate
SaveSetId
RetentionCategory
HasAttachments

{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}

Archive ID
Archived Date
Saveset ID
Retention Category
HasAttachments

STRING
STRING
STRING
STRING
STRING

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación