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

The Most Important Aspect of a Notes Migration

Aug. 21st 2013


There are some aspects of a Lotus Notes Migration to Exchange that are more important than others, but they probably aren’t what you would expect.

Over the past five years of doing these mail migrations I’ve found that the most successful migrations come down to three common factors:
1) Good Analysis
2) Extensive Planning
3) Appropriate Expectations

That may seem like a given but sadly it’s far from it.

Good Analysis gives you a true understanding of what your source data is. This lets you plan how long your migrations will take, how many migration machines you need to setup and what kinds of data your actually migrating. In the end, understanding what you have will better prepare you for supporting what you migrate.

Planning seems like it should be easy enough from the start of a migration project. You only need some servers, and the software right? We all wish it were that easy. The reality is that yes, you need the servers and software, but you need to plan for:
• Migration space and expansion for growth on your Exchange server.
• You need to plan for when you need to be done with your migration and how many people per day you need to migrate.
• You need to know how much data you need to migrate per person.
• What kind of data you need to migrate. Do you need only calendar, mail, both?
• How are users going to connect to their new Exchange mailbox? OWA? Outlook Clients?
• How are you going to support your users after they are migrated? What kind of call volume can your support desk handle?
• Can you migrate during the day or will that impact your production servers too much? This is a limiting factor on how quickly you can migrate.
• Do you need coexistence?

These are just some examples of the common things to put a plan in place for. These are just the tip of the questions you need to ask and investigate before you start your migration. A rich plan will make your migration go much more smoothly.

And finally, setting appropriate expectations is probably the most important of all. Migrations are a translation from one system to another not a copy and paste. Knowing the limitations of a migration will help to control the support calls after the migration.

Starting with those three basic migration concepts will get you far in the start of your migration.

Author: Dave Cook, LeadThem Security  Notes Architect





Posted by bc-admin | in Notes Migrator, Uncategorized | Comments Off on The Most Important Aspect of a Notes Migration