Migrating Custom Attributes

Please note that this document is a guide only and can continue in much more depth. You should have access to the tool Mfcmapi.exe or another MAPI property viewer application. Customer attributes can be migrated from Noted to Exchange MAPI properties. A good scenario is by which there is an archiving product that assigns a custom message attribute to all messages, and this is required to be migrated.The ‘attrs’tsv’ file i location within the install directory of ‘X:\Program Files\Quest Software\Quest Notes Migrator for Exchange’ and is the file that would need to be modified in order to add your custom message type.

Below there is an example of a scenario which a customer attribute is to be migrated and how it is migrated. In this example we will call the custom attribute ‘Custom01′. In order to migrate this from Notes to an Exchange mailbox we need to add this mapping. Essentially we need to map the source attribute to a free property in the MAPI target mailbox(s) that is not in use.To do this you must create (or modify and backup) the unicode (NOT ANSI) file ‘attrs.tsv’. In the example further below, we want to migrate the ‘Custom01′ attribute in Notes to Exchange mailboxes to a random (free) target property of ‘0×4801′ STRING value type. When the migration is run, it automatically looks at the mappings within that file to determine the source and target attributes/properties. If during migration this does not work, below is a list of reason why and what can be done to troubleshoot this:·         

·         Confirm that the target property does not already exist and confirm that the target property specified in the ‘attrs.tsv’ file is of the correct format. Please see further below for more information regarding this.·           

·         Use MFCMAP to troubleshoot or view if the property has been created and also if the value has been created of the property.·       

·         Confirm the TSV file is UNICODE and NOT ANSISample file is here:

……

ID,SourceProperty,TargetPropertySet,TargetProperty,TargetPropertyType

Custom01,FavoriteColor,,0×6700,STRING

…….

Here is some more information regarding MAPI properties but it is brief.

An unnamed property’s name is a 16-bit integer in the range 0×0001 to 0×7FFF. That 16-bit integer is valid in all mailboxes. An example of a used property would ne 0×0070, this is used by MAPI so you could not use this.

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 0×8000 to 0xFFFF is assigned to the named property by MAPI. That alias is mailbox-specific. A custom property can be unnamed or named. If it is unnamed, you must select a 16-bit integer TargetProperty in the range 0×0001 to 0×7FFF 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 do not have to worry about IDs already being in use because there will not be any. If you want unnamed custom properties, samples to try include 0×48xx, 0×58xx, or 0×78xx range. There are few, if any, properties already in use in those ranges. If you want named custom properties, you should use the PS_PUBLIC_STRINGS property set GUID, (PS_PUBLIC_STRINGS) being an alias for {00020329-0000-0000-C000-000000000046}), and using string IDs with a prefix that is unique to your application (like “Quest-”).