Migration merging to the wrong account - serious problem


     We have had multiple migrations. Here is what happened. We have 2 different users in separate domains with the same samaccountname

sfuller - simon fuller - domain A

sfuller - steven fuller - domain B - we changed the samaccountname to sfuller1 before migrating

Simon Fuller (sfuller) was migrated from domain A to domain C.

Steven Fuller (sfuller1) was migrated from domain B to domain C.

The problem is that it merged Steven Fuller from domain B into the existing Simon Fuller in domain C, that was previously migrated from domain A.

Originally when I tried to migrate it gave an error saying "matching rule found an existing object"

So, I changed the custom attribute from 14  and 15 to 11 and 12. This let me migrate the user object. But, it merged them.

Even though we changed the samaccountname it still merged the accounts. This caused a problem with Simon Fuller's mailbox. He now cannot log into Concur.

We have this fixed for the most part, but we have a few more users that have duplicate samaccountnames. Since we changed the samaccountname, how does

Quest match this. If I leave the default attributes to 14 and 15, it won't let me migrate the user at all. But when I change them it merges the accounts.

What does Quest look for when merging existing accounts?

  • Hi Don,

    thanks for this beautiful story. I know that Quest suggests to use a set of different attributes for each domain pair, but your story demonstrates how dangerous this suggestion is. It will make it work flawlessly from technical point of view, but it will cause you grief, as you observed. If you had used the same set of attributes the tool would have helped you an had warned about the conflict.

    To answer your question - by default the tool will match by name (samaccountname), by sidhistory and by e-mail (mail attribute), you will find those settings under domain pair properties.

    To resolve the problem I suggest the following:

    stop dirsync.

    clean up the mismatch - https://support.quest.com/SolutionDetail.aspx?id=SOL32553

    rename the source user, also change the name attribute, and migrate this user and use the option "never merge" and ensure the new target user got created properly.

    you can use an import/renaming file to rename the user on the fly - https://support.quest.com/SolutionDetail.aspx?id=SOL16917

    when done configure dirsync to skip the renamed attributes, or dirsync will change them back (will overwrite the change), if they were not changed in source.

    Here is what I have sent to a user who asked if he should use separate attributes for each domain pair:


    Actually using separate attributes is not a must, you could use the same set, but if there will be a duplicate (account with the same name) then the tool will error out.

    On the other hand this can be seen positively, at least when you get an error you will know that there is a conflict.

    If you use different attributes for each domain pair then the following could happen:

    you have John Doe in source 1 and James Doe in source 2, both have the same samaccountname, so in target you will create JDoe (samaccountname) and source 1 will populate EA 15 and source 2 will populate EA 12, no errors, no conflicts, and you end up with a mismatch.

    It will be your decision, but in order for the tool to keep working (from technical point of view) they suggest to use separate attributes.

    Some thoughts:

    I hope I didn't confuse you with too much information. It might sound confusing, but from a specific point of view using separate attributes for each domain pair causes more trouble than doing good.

  • Hello Wally,

    I am running version 8.10

    I have tested what you have mentioned to a tee.  2 source domains and 1 target domain.  Same exact user in both source domains, they get merged in the target without warning.  Object matching is there from top to bottom (SidHistory, E-Mail, and Account Name).  Service attribute for both target attributes for both source domains are set to 5 and 9.  It should error out?

  • I think the best way is to choose “never merge” in the Quest options. That way it will always create a new account when migrating. You don’t need to do this

    for all migrations, but if there is a duplicate user. We tried renaming the account before migration, but Quest still merged them anyway. So, Quest uses more

    than samaccountname to match AD objects.

    Don McGowen

    Systems Operations Engineer



    Additional Attachments:


  • It should not work that way, it should throw an error.

    I should not need to create a conflict rule either there are three hard coded ones in AD already:

    CN = OU

    SamAccountName = Domain

    UPN = Forest

  • Enrico, we know how matching in QMM works, right? Tool copies the source users GUID and puts this value in target users matching attribute.

    If you use the same attribute for 2 source domains and the same matching attribute then the target user can have only one value, it will be matched with one user only, you will not have 2 source users being synced into one target user. I think in your case it first merged one user, and later the other user... Probably there was no error because you have used one single DSA, the same DSA. You can easily verify by looking up the value, the GUID.

  • Wally right on the money!  I was using only one DSA agent for both domain Pairs.  I have never tested it before but with two DSA the warning wouyld appear?

    Or this article would be best used:


  • Enrico, I would think that even with the same DSA the warning should appear. Can you try it quickly in your lab? It is not only about 2 source domains, it is mostly about the DSA finding the attribute being populated with another value, it should warn you and not just overwrite the value...

  • Wally I cannot test it now, but I will do so tomorrow morning first thing.  I did another test concerning the matter before leaving work:

    Source A : Mergetest

    Source B: Mergetest

    Target C: Mergetest

    I have not checked in the target the matching attributes (source ObjectGUID) value will do so tomorrow, but the sidhistory was populated with both objectsids from the Source A&B domains respectively

  • O.K, so what exactly needs to be changed to migrate the users so they are not merged with an existing user?

    Do I need to change these 3 attributes? Or use a different DSA? This problem only happens when a user in the

    target was previously migrated to the target and the new source object matches that object.

    Like I said, we changed samaccountname prior to migrating. Do we also need to change the below attributes?

    CN = OU

    SamAccountName = Domain

    UPN = Forest

    I’m just not sure what to change.

    Don McGowen

    Systems Operations Engineer



  • Hello Don,

    I have tried 4 seperate tests and everytime I do so the accounts get merged without warning.  To my understanding this should not happen.

    This article does what it is supoosed to do but an account gets created with a SamAccountname that starts with a $ this is detailed in article SOL96391


    Wally any insight on this matter would be appreciated.