Orphaned objects in ADAM Directory – Quest Migration Manager for AD (QMM)

During a directory synchronization with Quest Migration Manager for AD QMM, orphaned objects can be created in the ADAM database.

I have repeatedly reported about the handling of Quest Migration Manager for AD (QMM AD).
So far, we finished the directory synchronization (DSA) in our current project.
The DSA agents stopped as well. Now I want to clean out the orphaned objects in the ADAM Directory.

Background – Orphaned objects in ADAM

Every synchronized pair of objects is created as a MAP-object in the QMM ADAM directory. In case a certain object was deleted in the target domain and migrated again later, there will be two pairs for the source-object in the QMM ADAM directory.
This fact is not a problem for the synchronization. But will turn out to be a problem, if resources are moved with Quest Resource Updating Manager RUM.

RUM creates a file VMOVER.INI from the data in the ADAM Directory, containing SID-pairs [source-SID <> target-SID].

During the reACLing-process the VMOVER.EXE searches for the source-SID and enters the target-SID contained in the VMOVER.INI. If there are several entries for one source-SID, all target-SIDs will be entered.

In our example one of the two SIDs does not exist in the target-domain anymore.
This leads to an orphaned entry in the ACL of the resource (e.g. NTFS ACL).

How to avoid orphaned entries in ACL lists?

To avoid orphaned entries in ACLs, Quest Support offers a script which can erase them in the QMM ADAM Directory.

Download Link

How to find objects in the ADAM directory?

On the ADAM server you can find the entry [ADAM ADSI Edit] under [Start – Program – ADAM]. Important is the DN (Distinguished Name). It is the project name which is used In the QMM console. E.g. cn=QMMAD

Objects in the ADAM directory are set up in a very flat structure which makes manual search almost impossible.
A LDAP query with ADSI-Edit helps here. To save the information of source and target object in a MAP-object, Quest came up with new attributes.
The SamAccountName for example is saved in two attributes:

Source-domain: aelita-Amm-SourceSamAccountName
Target-domain: aelita-Amm-TargetSamAccountName

A LDAP query for an account could look like this:

Name:                         any desired name
Root of Search:           CN=QMMAD
Query String:              (aelita-Amm-TargetSamAccountName=”name of the object”)

Mark objects as deleted

The script of Quest Support Remove QMMMapInvalidEnrtries.vbs searches for the entries in the ADAM directory in the target-domain.

In case the object does not exist anymore, the attribute aelita-Amm-Deleted is set on TRUE.
The LDAP query can be adopted as follows:

Searching for existing objects: (aelita-Amm-Deleted / Not set)

(&(aelita-amm-targetsamaccountname=“Name“)(!aelita-Amm-Deleted=*))

Searching for deletes objects: (aelita-Amm-Deleted=TRUE)

(&(aelita-amm-targetsamaccountname=“Name“)(aelita-Amm-Deleted=TRUE))

Quest Support published a short video explaining the ADSI-connection to the ADAM directory:

Link to the Video (Quest)