This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Migrate AD Accounts command line

Can anyone tell me or direct me to documentation of how to migrate our AD accounts with a command line script (and settings file) versus using the console and manually pointing to a csv file that has all the data.... we are trying to automate our provisioning completely and we have 2 child domains where users are created (completely automated) but then we use MMAD to migrate the accounts to our new parent domain linking them via sidHistory....  any help/documents would be appreciated!!

Parents
  • Currently there is no way to automate the migration of AD objects via command-line or PowerShell.
  • Chris, different question....can you tell me when MMAD does a migration of an object from one domain to another, how does it link them together?  I see that it puts the migrating "objectSID" into the destination object's "sidHistory"... from the migration wizard... but in our environement it also links extensionAttributes 10 and 12 with what appears to be some type of hash?  Can you delve into that?

  • Have a look at the following article, https://support.quest.com/migration-manager-for-ad/kb/36805/how-to-change-the-default-extension-attribute-used-by-qmm-dsa.......it may help somewhat.

    If there's only AD, it uses AdminDescription & AdminDisplayName (Attributes) by default
    If there's EX involved also it will use extension attributes 14 & 15  (Attributes) by default

    The above service attributes can be changed for all ObjectClasses.

    During the migration and DirSync process:

    If no match is found it does an LDAP search of the target for the source ObjectGUID in the appropriate “matching attribute” in the domain pair
    If it does not find a match, it will search based on other “object matching” criteria set in the domain pair
    If it finds a match, it will stamp the Target Object Matching Attribute with the source ObjectGUID

    Target objects matched with source by an LDAP search are stamped with corresponding source ObjectGUIDs
    Auxiliary Attribute, In short Quest uses this part for its own purpose (ADAM related) and populates data into the Target object Auxiliary Attribute chosen
    Matching Attribute, In short the SRC ObjectGUID gets populated into the Target object Service Matching Attribute chosen
    Hope this  helps,  If I am off please correct me
    Cheers
Reply
  • Have a look at the following article, https://support.quest.com/migration-manager-for-ad/kb/36805/how-to-change-the-default-extension-attribute-used-by-qmm-dsa.......it may help somewhat.

    If there's only AD, it uses AdminDescription & AdminDisplayName (Attributes) by default
    If there's EX involved also it will use extension attributes 14 & 15  (Attributes) by default

    The above service attributes can be changed for all ObjectClasses.

    During the migration and DirSync process:

    If no match is found it does an LDAP search of the target for the source ObjectGUID in the appropriate “matching attribute” in the domain pair
    If it does not find a match, it will search based on other “object matching” criteria set in the domain pair
    If it finds a match, it will stamp the Target Object Matching Attribute with the source ObjectGUID

    Target objects matched with source by an LDAP search are stamped with corresponding source ObjectGUIDs
    Auxiliary Attribute, In short Quest uses this part for its own purpose (ADAM related) and populates data into the Target object Auxiliary Attribute chosen
    Matching Attribute, In short the SRC ObjectGUID gets populated into the Target object Service Matching Attribute chosen
    Hope this  helps,  If I am off please correct me
    Cheers
Children