Security Group Migration

Hi All,

I migrated users and security groups some time ago from Domain A (Legacy) to Domain B (Live) as part of a project with a Quest engineer. I believe the a sync was setup to sync User and SG objects from the Legacy Dom to Live. We are seeing more frequently Users who are not seeing all their Security Groups on the Live Domain. Basically there are quite a few individual Users who are missing a number of Security Groups.

I am seeing quite a few unresolved Links where there appears to be individual users in a group that do not come across.

The questions I have are.

1. is there a way of synchronizing or coping users that have an identical User ID on both Domains to manually set up a job to copy the Security groups over to the live Domain. This will ease the pressure of the operations team while we look at what is causing the sync issue.

2. How do I go about trouble shooting this issue. I see no errors only these unresolved link issues.

Any help would be greatly appreciated as we are migrating quite a few users in the next couple of months to the live domain and we need to ensure that the Security Group on the Legacy get replicated to the Live Domain.

Regards and thanks for any help you could provide.

  • Unresolved links are usually group members that have not been mapped by the tool.  - i.e. the tool doesn't know which source object correlates to which target object

    Was the synch setup such that it would be allowed to create new objects in the target domain - i.e. when a new one was created in the source?  Sounds like maybe not.

    You can "force match" users by creating a tab-delimited input file like like this (you need the header row):

    samaccountname<tab>samaccountname
    jsmith<tab>smithj

    ...and processing it with a migration session.  This assumes that you have the "account name" matching rule enabled and that you have sufficient migration licenses remaining.

    If I were you, I would go back to the Consultant who set this all up for you and get them to explain it to you again.

  • Apologies for leaving this out:  The samaccountname fields would be your respective source and target objects.  When an account is successfully matched and mapped, one of the extension attributes of the target object will be stamped with the GUID of the source object.  In Exchange enabled schemas, this is stored in the target object's extensionattribute15 by default.