Archive for the 'Migration Manager for Active Directory' Category

The Decision to migrate has been made. Now What!?!

Oct. 12th 2015

You’re the IT guy and the company has been bought, changed names, or your just simply cleaning up old Ailing domain that should have gone years ago. There are a few things you need to do before seeking out quotes for software and beginning your Active Directory Migration. A few questions to ask:

  • How many users will be migrated?
  • How many mailboxes will be migrated?
    • How much Email Data do you have?
  • How many Domains will be migrated?
  • What time frame you want to complete?

You now have your Software now what do we need to know before we start migrating.

  • What Applications talk to AD and how?
    • Are they LDAP?
    • Can they be configured with multiple domains?
    • Contacting the Vendor sometimes will help with these questions.
  • Do you have a List?
    • Users
    • Groups
    • Computers
    • Users to Computers they use
    • Users to Shared Mailboxes they use

Having these things ahead of time will help you and your consultant move forward faster and more efficient.

Posted by bc-admin | in Migration Manager for Active Directory | Comments Off on The Decision to migrate has been made. Now What!?!

Performing an Intra-Forest migration

Oct. 8th 2015

Performing an Intra-Forest migration is different in many aspects than performing an Inter-Forest migrations. The biggest issue that needs to be watched out for is not having two same accounts with same SIDS in both domains. That is why as soon as possible after migrating the objects they need to be deleted from the source domain. This make having a tested backup extremely important in case there is a need to back out the migration. Careful planning needs to be done when performing an Intra-Forest migration. Below are high level steps to help insure that the migration goes smoothly.

  1. Upgrade source Global groups to Universal
  2. Physically migrate all groups to target Domain.
    1. Migrate groups with Sid History and adding source members.
    2. Delete source groups
    3. Change admin point to target for all groups.
    4. Resource Process workgroup data (i.e., file servers, etc.)
    5. Execute ADPW in all domains to update group membership of Source users
    6. Optional but recommended:  Clean up sidHistory on migrated groups.
  3. Create user “stubs” in target. (i.e., Logically Migrate)
    1. Migrate user accounts, skipping sAMAccountName (migration session)
    2. DO NOT copy SID History, Password, Security Descriptor, and Mailbox.
    3. DO NOT Enable user account
  4. Resource process and move all workstations. (delete the source computer accounts during the physical migration – if QMM Directory Sync is running, be sure NOT to sync deletions)
    1. Exclude serviceprincipalname attribute from computer objects
  5. Resource process servers for ACL only
  6. Migrate users (Physical Migration)
    1. Verify RMAD session ran recently (in case of an object restore requirement)
    2. Migrate selected users with Password, SID History, Mailbox, and sAMAccountName
    3. Run ADPW with custom map to update TARGET ‘Update Group Membership”. Verify migration
    4. If SQL servers present, SQL Wizard run with custom map
    5. Delete source users
  7. Migrate Servers (physical migration)
    1. Resource Process (do not double acl, replace the acl).
    2. Join to target domain
  8. Clean-up
    1. If MS SQL present, re-run SQL Wizard with all objects.
    2. Re-run ADPW, clean up legacy memberships.
    3. Verify RMAD run and user ADPW to cleanup SID History.
    4. Remove source domain.

Note that you may choose to “loop” on step three for sets of users at a time.  You may also choose to loop on step 2 for sets of groups at a time

Posted by bc-admin | in Migration Manager for Active Directory, Migration Manager for Exchange | Comments Off on Performing an Intra-Forest migration

MMAD DSA Will Not Start during Migration Session

Oct. 28th 2014

During a recent migration project, I had a situation that I encountered with a customer where we were performing a migration session with the Dell Migration Manager for Active Directory.  The symptoms were, once the migration session was started, Initialization would complete, but migration would never start.  Upon investigating further, the Quest Directory Synchronization Controller Service was not started, this service is what the migration session should start to accomplish the migration of objects.  I have seen this before during migrations, and usually the response is to start the service and move on with your life, typically you might have to start the service once or twice and the software continues on without a hitch.

This issue was different though.  Not only did the service not start consistently, I was seeing an error in the DSA log as well.

10/06/14 13:18:41 (GMT-06:00)     Common Error 0xe100002a. Statistics service unavailable (Protocol=ncacn_np, NetAddress=, EndPoint=\pipe\dsa\statistics).

RPC error 0x6bf. The remote procedure call failed and did not execute.

After reviewing this error, at first glance, I thought, the statistics service was down or unavailable for some reason.  Then I remembered, this customer did not even want statistics installed, so sure it wasn’t available because it did not exist on the system.  The problem was, this installation had been working correctly up until this point, but the error coincided with each migration session that was ran but the service had failed to start.  After some digging, that specific error did not yield any results within the Dell support knowledge base, but I did come across something that was similar and after some testing, the method I am going to outline below will typically correct this issue.

  1. Stop the Quest Directory Synchronization Controller Service if it is running
  2. Make a backup of your AD LDS or ADAM database
    1. Stop the AD LDS or ADAM Service (Typically named QMM or similar)
    2. Navigate to the installation path for the database
      1. %program files%\Microsoft ADAM\<Service Name>
    3. Copy the <Service Name> folder to another volume or another system for safe keeping.
    4. Start the AD LDS or ADAM Service
  3. Next start ADSI Edit
  4. Open the Migration Manager console
  5. If you are connected to your project, record your project name (noted in parenthesis beside Migration Project node in the tree node view)
  6. 1
  7. Right Click on ADSI Edit and click Connect to…
  8. 2
  9. Enter the Connection Settings
    1. Name : Whatever you want to name this, it is fairly irrelevant
    2. Connection Point: Select the radio button for ‘Select or type a Distinguished Name or Naming Context’ and enter CN=<project name> (recorded in step 5, in this example, my project name is QMM)
    3. Computer: Select the radio button for ‘Select or type a domain or server’ and type localhost if the AD LDS/ADAM service is running on the same server, or enter the server name where AD LDS/ADAM is running.
    4. Click OK
    5. 3
  10. Once the AD LDS/ADAM context opens in ADSI Edit, Expand as shown below, the hash container will probably contain another string in it, but if you only have one project in Migration Manager currently, you should only see one container that looks like a hash within the Projects container.
  11. 4
  12. (Optional) If you have multiple domain pairs within this project, you will see multiple hash containers within the Projects container. If this is the case, you will need to locate which container corresponds with the domain pair you are having issues with. To do this, right click on each hash container under projects and look for aelita-AMM-Name in the attribute list for the domain pair identification. Once you locate the container that represents the domain pair you are having issues with, continue with step 10. (Note the container name in the title of the below image and where it is located in the tree in the above image in step 11)
  13. 5
  14. Notice in the expansion of the container above, there are two other containers below that appear as hashes as well. These two represent your DirSync and Migration services within Migration Manager and in the case of this issue, we need to identify which one is for the Migration Sessions.
  15. Right click on the first one and search for aelita-AMM-Name in the attribute list and look at the value of this attribute. In the image below, this one is for Migration and is the one we are looking for.   for the example of this issue, if the aelita-AMM-Name attribute was populated with Synchronization, that container would be for DirSync. (Note the container name in the title of the below image and where it is located in the tree in the above image in step 11)
  16. 6
  17. Now that we have identified this container is for Migration, scroll up in the attribute list and look for aelita-AMM-CurrentState. If the service is stopped and no migration sessions are running, it should be at 0. What I have found that even though nothing is running, this may be erroneously set to 1 or 2, just edit the value and set it to 0.
  18. 7
  19. Scroll down in the list and look for aelita-AMM-StartOperation. If it is not set to FALSE, edit it and toggle the state to FALSE.
  20. 8
  21. Check the value for aelite-AMM-StopOperation as well. If it is not set to FALSE, edit it and toggle the state to FALSE as well.
  22. 9
  23. After the setting changes have been made, close ADSI Edit (Settings are applied and saved as soon as they are made in ADSI edit).

These changes set the migration session states back to stopped and have taken care of the issue listed above and consequently, can also solve or correct the issue with the DirSync saying it is ‘Stopping’ and all other attempts to correct this issue have failed. The steps above would be the same with the exception of step 9, there you would want to look for the hash container where aelita-AMM-Name was Synchronization.


Russ Burden, Technical Architect, LeadThem Security

Posted by bc-admin | in Migration Manager for Active Directory | Comments Off on MMAD DSA Will Not Start during Migration Session