Migrations - IntraForest Domain Migration and Collapse

As a consultant, I have specialized in large enterprise migrations for 13 years.  Over that time I have lead the migration effort for over 10 large global enterprises all from complex mixed environments (MS, Unix, Novell, etc).  Below is the methodology I have developed over the years trying to follow all best practices.  This is my first article in a series of "Migration" topics.

The focus of this article is: Performing a IntraForest Domain Migration and Collapse using the free tool ADMT v3 (Active Directory Migration Tool).  This article does not take into consideration Exchange, SharePoint or any other application specifically.  It is a high level migration planning approach to get you started.

Important Concepts

• The domain you are migrating or collapsing should be operating at Windows Server 2003 Functional Level.
• Objects are migrated and no longer exist in the Source location.
• SID history is required.  Using ADMT it will create a new SID but it will use the SID History or SID Walker old tool method to retain the original SID as an Attribute of the object, therefore AD is aware of the old SID.
• Passwords are retained.
• Local Profile Migration
  • Migrating user profiles is a completely separate step from migrating the user account.
  • Be prepared with the manual steps to migrate user profiles manually for ones that didn't work.
  • Users computer must be powered on and accessible on the network prior to the account, profile, and computer migration.
  • For workstations that run the Microsoft Windows 2000 Server operating system and later, local profiles are migrated automatically because the user’s GUID is preserved.
  • For Windows NT 4.0 and earlier you must use ADMT to migrate local profiles.
• You must migrate accounts in closed sets. This means that all users in all groups you are migrating are only in your source domain, and all users that are in a group you are migrating are also being migrated, and all groups a user is in that is being migrated are being migrated. This is the only way the Global Group will be migrated to another Global Group.  If it is an "open set" then ADMT will migrate the Global Group to a Universal Group.  Remember, you don't want to have any more Universal Groups than necessary as they are replicated throughout the entire Trusted Forest structure from Global Catalog Server to Global Catalog Server causing un-necessary traffic over the network.
  • You migrate User Accounts, Global Groups together, and Resources (computers, servers, printers) and Local Groups together. The order you migrate objects is extremely important.  You will migrate Groups right before Users, not after.
  • When you migrate a Global Group it creates a Universal Group in the target domain to migrate the users into until all members of that Global Group have been migrated, and then it changes the Universal Group to a Global Group.  This is another reason it is important to migrate "closed sets".
• Users must decrypt encrypted files before their account migration.

Active Directory Migration Tool

You must use ADMT to perform a domain migration or collapse properly. You can script it, use command prompt or use the Wizard.  Many things can go wrong in a migration using ADMT, especially if you have never performed a domain migration before.  Therefore, for this migration I highly suggest using the Wizard rather than scripting.

You will need to create at least one Migration Service Account that ADMT will use to perform the migration functions.

Object Migration Order

Remember you migrate 2 sets; 1) Groups and Users, and 2) Resources and Local Groups

1. Run the Service Account Migration Wizard to identify all Service Accounts (it does not migrate them)
2. Universal Groups
3. Global Groups (exclude built-in groups)
4. User Accounts that are members of the Global Groups migrated
   1. If you have any NT 4.0 computers then you need to Translate Local User Profiles next.
   2. This is not necessary for workstations > NT 4.0 because SID to GUID mapping will preserve in the registry the profile of the user and then re-associate it to the new SID.
5. Service Accounts
6. Resources - migrated users computers - you must reboot computer immediately afterwards
7. Run Security Translation Wizard on any Software Distribution Points
8. Resources - Printers
9. Resources - File Servers - you must reboot immediately afterwards
10. Resources - Member Servers (and Application Servers) - you must reboot immediately afterwards
11. Resources - Infrastructure Servers (DHCP, DNS, all DCs except FMSO roles) and Domain Local Groups (exclude built-in groups) - you must reboot  immediately afterwards
12. Resources - Infrastructure Server FSMO roles, leave the Root DC for last - you must reboot immediately afterwards

Migration Steps - high level

A domain migration and collapse is no minor task, and if not done in the proper order can orphan objects and lose their ACLs.  If you know me at all, you would know that I like to follow a phased approach for my migrations, as I was taught from my years work with Microsoft Consulting and EDS.

1. Phase I - Preparation
   1. Clean up AD, remove all old user accounts, groups, OUs, computer accounts. 
   2. If you need to rename any accounts, groups or OUs you should do this prior to the migration, not during so that you do not experience naming conflicts.
   3. Identify all Login Scripts in the NTTL domain, track in a List recording what actions it takes.
   4. Identify all Service Accounts in the NTTL domain, track in a List recording; what permissions it requires, groups groups it is in, what GPOs are applied, and what applications and users use it.
   5. Identify all Domain Local Groups and ensure that the Domain Local Groups are NOT used ANYWHERE in the ACLs. 
      1. IMPORTANT:  Most companies do NOT leave enough time for this.  They "assume" that they don't have any or many ACLs using Domain Local Groups...and I have NEVER been to a company where they didn't under estimate this and ended up spending weeks re-ACLing at the last minute because they didn't address it properly.
   6. Identify all applications, scripts and batch files on all servers and workstations to ensure they do not have the fully qualified domain name hard coded anywhere.
      1. Again, I have stressed this to every customer and every customer insists they don't have any hard coded references to the domain names.  And again I have never had a customer that didn't have them.  I have had migrations come to a halt because of many domain references found at the last minute, that needed to be re-worked. 
      2. I suggest you purchase tool that can search the inside of batch files and other script files to search for your domain names.
   7. If there is currently only a one way trust, then create a two-way trust for the migration process as it just makes the steps easier.
   8. Identify all data, and printers on source domain controllers and migrate that data and objects over to other Member Servers if possible.
   9. Create a Service Account for ADMT that has Domain Administrator permissions in both domains.  It must also have delegated permission on the user, group, computer, OUs and the extended right to migrate SID history.
      1. In the TRI domain, delegate permissions on OUs that are targets for resource migration to the ADMT Service Account.
   10. OU Preparation - If you have a different OU structure then you will need to modify TRI to account for all computer, user, and application OUs.  You will need to map out which target OUs the computers and users will be migrated into.
2. Phase II - Closed Set 1 Migration
   1. Use ADMT to migrate the following:
      1. Run the Service Account Migration Wizard to identify all Service Accounts (it does not migrate them)
      2. Universal Groups
      3. Global Groups (exclude built-in groups)
      4. User Accounts that are members of the Global Groups migrated
      5. 1. If you have any NT 4.0 computers then you need to Translate Local User Profiles next.
         2. This is not necessary for workstations > NT 4.0 because SID to GUID mapping will preserve in the registry the profile of the user and then re-associate it to the new SID.
      6. Service Accounts
      7. Resources - migrated users computers - you must reboot computer immediately afterwards
   2. After each number verify migration logs for errors and verify the group types.
3. Phase III - Closed Set 2 Migration
   1. Use ADMT to migrate the following:
      1. Run Security Translation Wizard on any Software Distribution Points
      2. Resources - Printers
      3. Resources - File Servers - you must reboot immediately afterwards
      4. Resources - Member Servers (and Application Servers) - you must reboot immediately afterwards
   2. After each number verify migration logs for errors and verify the group types.
4. Phase IV - Collapse
   1. Use ADMT to migrate the following:
      1. Resources - Infrastructure Servers (DHCP, DNS, all DCs except FMSO roles) and Domain Local Groups (exclude built-in groups) - you must reboot  immediately afterwards
      2. Resources - Infrastructure Server FSMO roles, leave the Root DC for last - you must reboot immediately afterwards
      3. Perform ADMT Security Translation Wizard on Member Servers to clean up ACLs, and to remove the source domain SIDs from the ACLs..
   2. Only after ALL OBJECTS are migrated out of the child domain can you perform the DCPROMO back to a member server.
   3. Ensure all entries for the domain name and domain controllers are cleaned out of DNS, WINS, and Sites and Services properly.

Referenced Material:  Chapter 12 Restructuring Active directory Domains Within a Forest.doc

del.icio.us Tags: Migration Specialists,Active Directory migration,Active Directory Collapse,ADMT

Category: Active Directory;Migration

Published: 6/1/2008 9:11 PM