Chat now with support
Chat with Support

Migrator for Notes to Exchange 4.16 - 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 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 app knows which properties in the target correspond to which attributes in the source. Therefore, the migration of custom attributes requires that these 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.

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:
Save and close the updated customattrs.tsv file.

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









Archive ID
Archived Date
Saveset ID
Retention Category


Troubleshooting problems in migrating Notes custom attributes

You can use Microsoft’s MfcMapi.exe utility to view the property and its value, if they have been created. (The utility is a free download from Microsoft. You can search in Google for "mfcmapi" and visit the link.) Most problems in migrating custom attributes can be diagnosed by these quick tests:

Verify the target property specified in the customattrs.tsv file does not already exist, and that the target property is in the correct format. See About MAPI properties below for more information about this.
Verify that the customattrs.tsv file is UNICODE, not ANSI.
Verify that the last line in the customattrs.tsv file is followed by a line feed and carriage return (achieved by positioning the cursor at the end of the last line and pressing Enter).
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.

About MAPI properties

A named property's name is a property-set GUID and an ID that is either a 32-bit integer or a string. A 16-bit integer alias in the range 0x8000 to 0xFFFF is assigned to the named property by MAPI. That alias is mailbox-specific.

An unnamed property's name is a 16-bit integer in the range 0x0001 to 0x7FFF. That 16-bit integer is valid in all mailboxes. Examples of unnamed properties are 0x0070 (i.e., PR_CONVERSATION_TOPIC) and 0x6656, both of which happen to be used by MAPI. So these two examples cannot be used as target property values for message attributes since they are already used, although they may be used to map Notes contact attributes to Exchange.

A custom property can be unnamed or named. If it is unnamed, you must select a 16-bit integer TargetProperty in the range 0x0001 to 0x7FFF that is not already in use by MAPI. If it is named, you can select any property-set GUID. If you select a property set that is already in use, you must choose a 32-bit integer or string ID that is not already in use in that property set. If you select a brand new property-set GUID, you need not worry about IDs already in use because there will not be any.

If you want named custom properties, Quest recommends you use the PS_PUBLIC_STRINGS property-set GUID, (PS_PUBLIC_STRINGS being an alias for {00020329-0000-0000-C000-000000000046}), and use string IDs with a prefix that is unique to your application (like "Quest-").

How do I customize the placeholder message that the Data Migration Wizard substitutes for encrypted messages?

Since the Data Migration Wizard does not migrate encrypted messages, it will substitute placeholder messages for encrypted messages in your users’ Exchange mailboxes. The Self-Service Desktop Migrator will then replace the placeholder messages with the real messages as it de-crypts and migrates them.

You can customize the content of this placeholder message by creating a simple text file of the content, and then editing the Global Default Settings to specify the use and location of the file. The message can be a simple notification, or may include instructions for launching and running the Self-Service Desktop Migrator to migrate the encrypted message bodies. For information about customizing the user interface of the Self-Service Desktop Migrator, see How to customize the SSDM (in the Migrator for Notes to Exchange Scenarios Guide).

After you create the text file, edit the Global Default Settings (see How do I add or edit program parameters?):

In the [General] section, set UseFilteredBodyMsg=1, and set an appropriate parameter value for BodyLostDueToEncryptionMsg (the full path and filename of the customized text file). For example:

Then use Notepad or some other text editor to open the notesdtapp.ini file, set the same two parameter values in the [General] section of that file, and save the changes to notesdtapp.ini.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating