NME: The Merge Process

 

The merging process for Notes Migrator for Exchange simply takes the mail-enabled contact and copies & pastes the attributes onto a designated matching AD user object. Why would you need to do this? In a scenario by which you’ve installed the Microsoft Connector for Lotus Notes, the Transporter, or an identity integration package like Microsoft identity Integration Server. This allows for users from both the Notes and Exchange environment to view both orgs from their GAL/Address Book. The idea behind the merge with our tool is that you specify a value from within our database (which comes from the Notes Address Book) to match to their associated AD user object. Think of it as if you’re creating a mapping between the users in the NAB and the AD user Object. Do not think about the contact, we can find the contact as long as we’re told you use the Notes or SMTP addressing of the contacts.

What do we exactly do when we merge?

-          We build a list of run-time attributes from parameters which we know are going to merged. Some are hard-coded, such as the proxyaddresses and TargetAddress

-          If you’re using the 2003 Connector for lotus Notes, we run a query to find the contact, using this syntax:

(&(objectClass=contact)(proxyAddresses=notes:User name/Domino@Domino))

-          If you’re using the Transport for 2007 Exchange or simple SMTP, we run a query to find the contact, using the same LDAP query, but against an SMTP address because 2007 Transporter uses SMTP now, not Notes style addressing

-          If a contact is not found, we do an LDAP search using the TargetAddress as a last resort. If a matching address is not found then the we error out

-          If a contact is found we dump the attributes of the contact into memory

-          We then LDAP the AD user object using an LDAP query:

(&(objectClass=user)(sAMAccountName=User.Name))

-          The contact is then stripped of its attributes

-          The AD user is then mail-enabled, NOT mailbox-enabled pending a PowerShell success return

-          A delay is enabled to wait for the removed attributes from the contact to be confirm following replication

-          Once this is confirmed the attributes are written to the AD user objects which are essentially copied from the contact, pending the acceptance of Exchange validation requirements

-          The contact is then deleted

 

How do I decide what I should select for the merge?

 

-          The first thing is to look at the information on the Notes side of things. So, on the ‘View Summaries’ screen, select the User and resource details as shown below. This will let you view and/or export the data from our database, which is basically the data from the Notes NAB, so you can look at this and think about the merge. You can even just open Domino or Notes and view this information also!

 

 

 

-          Next you should open up an AD user, is there a common match?

  

Scenario: An example of a merge

 

-          First let’s take a look at a random AD user and open up in ADSIEDIT, we look and simply see a DisplayName, then also the employeeNumber attributes are populated. You could user AD users & Computers but ADSIEDIT is better! You can download this from here:

 http://www.computerperformance.co.uk/Logon/LDAP_attributes_ADSIEdit.htm

  

-          Now let’s take a look at the same user’s Notes information. We can do this via looking at our database or via the Notes Client. Here we see the Display Name and also the Employee ID value.

  

 

 

  - Within our Quest GUI we see the Display name and again the Employee ID.

  

-          From this we can see that we have the option to either use the Display Name or the Employee ID to match them. Which ever value is the most precise is the value you should use, so this would most likely be Employee ID. So during the merge we would select the following GUI values

  

We select this because the EmployeeID value within Notes, is the same as the EmployeeNumber

within Active Directory.

 

 

Frequently Asked Questions

 

The merge takes a long time?

 

-          The DC we get is the DC call from Microsoft, meaning, the first to respond is the one we use

-          2007 PowerShell calls have an added delay not previously seen in 2003 architecture

-          Open the File – Edit Global Defaults, change the ‘LogLevel=’ value to be that of ‘LogLevel=3’ then mail this to support.

-          Mostly this is because the environment is slow

 

When running the merge, the list of AD attributes which I can match does not display the attribute I wish to merge with?

  

 

An example of when this might be used is if you have a value within the database, that is the same as the AD User Object’s ‘DisplayName’ attribute, but by default the ‘DisplayName’ attribute is not available within the drop-down. I will use the ‘DisplayName’ attribute in this example. Please remember that the numbering must be contiguous, so if there are other attributes you must continue with the naming/numbering structure:

  [ActiveDirectoryMatchList]

Count=27

ADML0=cn

…..

ADML25=extensionAttribute15

ADML26=CustomAttributeAD

 

Remember that you must change the ‘Count=’ value. The count value was 26, but is now 27 as we have added the ‘ADML26=CustomAttributeAD’ value. (This is including the count of the ‘0’ value) 

  

I want to prevent some attributes form being merged, how can I do this?

 You may have a value on the source AD user object of which you do not require to be merged with the Target Object user.

 For example, If you want the merge process to ignore the ‘company’ attribute, you must use an ‘-‘ dash symbol to preceed any value. So as seen below, it reads ‘Attr2=-company’.

 [ActiveDirectory]

Attr0=c

Attr1=co

Attr2=-company

Attr3=countryCode

…

 This will mean that upon merge the company attribute will be ignored. Some attributes, only the proxyaddresses and TargetAddress are hard-coded and cannot be ignored.

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

 

Below is a migration checklist for the tool. These are things which should be completed prior to migration and during.

Task	Yes/No?
Environment Tasks
·         Download & Install the Exchange 2003 Connector for Lotus Notes: http://www.microsoft.com/downloads/details.aspx?FamilyID=d9f3a35e-1046-47b5-b09b-bda9de60cd9d&displaylang=en  ·         Download & install the Microsoft Transporter Suite: http://www.microsoft.com/downloads/details.aspx?FamilyId=35FC4205-792B-4306-8E4B-0DE9CCE72172&displaylang=en  ·         Configuring the Exchange 2003 Connector for Lotus Notes: http://support.microsoft.com/kb/883727  ·         Customizing the mapping of attributes with the Connector for Lotus Notes, if required: http://support.microsoft.com/?id=180517  ·         Configuring the Exchange 2007 Microsoft Transporter Suite: Documentation is supplied with the software, also see: http://go.microsoft.com/fwlink/?linkid=80568
·         Confirm Calendar and Mail Routing Coexistence
·         Configure Recipient policies
·         Configure Temporary Sub-Domain
·         Create AD user objects from Connector / Transporter, or by other means
Quest Notes Migrator Tasks
·         Create a computer for the Quest Migration
·         Create Migration Account for Domino Server with admin rights and LocalDomainAdmins membership
·         Create Migration Account for Exchange with receive-as & Send-as rights and NOT a member of Domain Admins
·         Create Migration Account for AD with Domain Admin rights
·         Install Notes Client
·         Install Outlook Client
·         Install PowerShell (2007 only)
·         Install Exchange Admin Tools
·         Exclude Anti-Virus from the migration machine
·         Install SQL (or have a SQL server) with createDB permissions to logon account
·         Download & Install the Quest Tools from:  http://www.quest.com/notes-migrator-for-exchange/
·         Specify SQL Server Config within the Quest Tool
·         Specify Shared Directories Config within the Quest Tool
·         Specify Notes Server Config within the Quest Tool
·         Specify Exchange Server Config within the Quest Tool
·         Specify AD Config within the Quest Tool
·         Run Find NABs
·         Run Find Domains
·         Run Export Notes Directory
·         Modify the Export Directory (if necessary)
·         Create User & Group Collections
·         Confirm Manage Design Classes
·         Run Locate Notes Data Stores
·         Confirm PAB Process by replicating data or sending PAB request
·         Run the Merge Contacts to merge AD user Objects (if required)
·         Set forwarding from Exchange back to Notes after mailbox-enabling objects
·         Confirm migration process & scheduling
·         Start of migration

 

 

 

 

 

 

 

What is MigDBUtil?

 

The Migration Database Utility (MigDBUtil for short) is used in scenarios by which you have replicated mail files from a remote slow connection server, to a more centrally located server in order to improve migration throughout, or simply for preference. When you use Notes Migrator for Exchange is has the Directory Export process that reads the NAB and takes the mail file path address from this and imports that into our database. So the NAB will not reflect the replicated mail file changes, which is where the MigDBUtil tool comes in, which allows us to modify these changes. A screenshot of the tool is below. The tool consists of the following components:

 

    · Add Servers

This component is only used when you have replicated the mail files to a new server which would in no way be within our database and until recently, not have been within the NAB. If you have replicated the mail files to a server that already existed, then this is not required to be run, you can simply run the modify Mail File Paths. By default sample input file is provided within the default installation difrectory named ‘sample_server.csv’

· Modify Mail File Paths

Here we use this by specifying a collection, namely a grouping of users, with an associated input file that contains details of the source path and the now new path. By default a sample input file is provided within the default installation directory named ‘sample_mailfilepath.csv’

· Import/Export Collections

This will not be discussed in detail but is used to back and restore any or all collections you use for the migration

 

 Looking at the Locate Notes Data Stores screen, you may have the following mail file path, which is named as the Domino Server Address column within the NME GUI under the Locate Notes Data Stores menu.

 

 

 

In our scenario we wish to change this path because you have replicated the mail file from the following path of:

Domino65/Wingra!!mail\Folder\gwbush.nsf

To the following new replicated path of:

NewServer/Wingra!!mail\NewFolder\gwbush.nsf

 

Run the Add Servers

Because we have specified a new server we will need to run the Add Servers section of the MigDBUtil and also generate/modify the sample_servers.csv file with the new server name. Below is a screenshot of the template file supplied that has been modified with the new server I will be using.

 

 

Now we save this file and use the Add Servers component to add this server record into our database as seen below.

 

 

Now this record has been successfully added into our database, we can now continue on to modify the mail file path of the user(s) by utilising the ‘Modify Mail File Paths’ component so that when we finally migrate, we are migrating from the newly replicated NSF.

 

Run the Modify Mail File Paths

 

Open the template ‘sample_mailfilepaths.csv’, located in the root install directory. You will need to modify this with Excel (or notepad) and a bit of copy/paste. The original file is below for your reference.

 

 

 

When modified, the resultant file will look like the following:

 

 

The ‘Source Address’ column within our database must match the one within this input file. We gain the ‘Source Address’ column value from a collection we can export from the tool. This is done via the Manage User Collections in the Quest GUI, selecting the collection and then exporting that collection. A snippet of this export is shown below. So we use the ‘SourceAddress’ column as shown, and paste this into the ‘Source Address’ column of the ‘sample_mailfilepaths.csv’.

 

 

Now run the modify Mail File Paths specifying the input file ‘sample_mailfilepaths.csv’ and the result is shown below.

 

 

To confirm this has now worked, the following Locate Notes Data Stores screen will reflect the changes in the GUI.