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.

You can leave a response, or trackback from your own site.