Logo
CAR REVIEW
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
PREGNANCY
 
 
Windows Server

Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Multiple Domain Consolidation Migration (part 1)

3/3/2011 10:24:33 PM
There are cases when it is better to migrate to a new forest and domain, rather than bring along the baggage of a legacy Active Directory. This includes needing to consolidate names, concerns with the legacy Active Directory schema, or simply to consolidate Active Directory services. The consolidation migration allows an administrator to, in effect, start fresh with a clean installation of Active Directory. Figure 1 shows an example of the migration scenario used in this section, where the companyabc.com and asia.companyabc.com will be consolidated to a new forest with the domain companyxyz.com.
Figure 1. CompanyXYZ forest.

However, this can be disruptive to the users and applications if not handled carefully. Migrating to a new domain and forest results in changes to the security identifiers, which can impact access. It can also result in password changes, making it difficult for users. However, there are tools and techniques, which are explored in this section, to mitigate the impact to the users and applications.

The introduction of Windows Server 2008 coincided with improvements in the Active Directory Migration Tool, a fully functional domain migration utility. ADMT version 3.1 allows Active Directory users, computers, and groups to be consolidated, collapsed, or restructured to fit the design needs of an organization. In regard to Windows Server 2003/2008 migrations, ADMT v3.1 provides for the flexibility to restructure existing domain environments into new Windows Server 2008 R2 Active Directory environments, keeping security settings, user passwords, and other settings.

Understanding ADMT v3.1 Functionality

ADMT is an effective way to migrate users, groups, and computers from one domain to another. It is robust enough to migrate security permissions and Exchange mailbox domain settings. ADMT is composed of the following components and functionality:

  • ADMT migration wizards— ADMT includes a series of wizards, each designed to migrate specific components. You can use different wizards to migrate users, groups, computers, service accounts, and trusts.

  • Low client impact— ADMT automatically installs a service on source clients negating the need to manually install client software for the migration. In addition, after the migration is complete, these services are automatically uninstalled.

  • SID History and security migrated— Users can continue to maintain network access to file shares, applications, and other secured network services through migration of the SID History attributes to the new domain. This preserves the extensive security structure of the source domain.

Note

One unfortunate change in ADMT v3.1 is the removal of the test migration and rollback functionality that was present in ADMT v2. Microsoft had numerous difficulties with it and chose to deprecate the feature rather than resolve the issues.


ADMT v3.1 installs very easily but requires a thorough knowledge of the various wizards to be used properly. In addition, best-practice processes should be used when migrating from one domain to another.

The migration example in the following sections describes the most common use of the Active Directory Migration Tool: an interforest migration of domain users, groups, and computers into another domain. This procedure is by no means exclusive, and many other migration techniques can be used to achieve proper results. Subsequently, matching the capabilities of ADMT with the migration needs of an organization is important.

Using ADMT in a Lab Environment

You can develop the most effective lab by creating new domain controllers in the source and target domains and then physically segregating them into a lab network, where they cannot contact the production domain environment. The Operations Master (OM) roles for each domain can then be seized for each domain using the NTDSUTIL utility, which effectively creates exact replicas of all user, group, and computer accounts that can be tested with the ADMT.

ADMT v3.1 Installation Procedure

Install the ADMT component on a Windows Server 2008 domain controller in the target domain, where the accounts will be migrated to. To install, follow these steps:

Note

As of the writing of this book, ADMT 3.1 does not support installation on Windows Server 2008 R2. To utilize the tool, install it on a Windows Server 2008 server. After migration, decommission the Windows Server 2008 server.


1.
Download ADMT 3.1 from the Microsoft Download site.

2.
Choose Start, Run. Then browse to the download location, select admtsetup31.exe, and click Open. Click OK.

3.
Click Run to launch the setup.

4.
On the Welcome page, click Next to continue.

5.
Accept the end-user license agreement (EULA), and click Next to continue.

6.
On the Customer Improvement Program page, click Next

7.
Accept the default database selection, and click Next to continue.

8.
Leave the default No, Do Not Import Data from an Existing Database (Default). Click Next to continue.

9.
After installation, click Finish to close the wizard.

ADMT Domain Migration Prerequisites

As previously mentioned, the most important prerequisite for migration with ADMT is lab verification. Testing as many aspects of a migration as possible can help to establish the procedures required and identify potential problems before they occur in the production environment.

That said, several technical prerequisites must be met before the ADMT can function properly. These are as follows:

  • Create two-way trusts between source and target domains— The source and target domains must each be able to communicate with each other and share security credentials. Consequently, it is important to establish trusts between the two domains before running the ADMT.

  • Assign proper permissions on source domain and source domain workstations— The account that will run the ADMT in the target domain must be added into the Builtin\Administrators group in the source domain. In addition, each workstation must include this user as a member of the local Administrators group for the computer migration services to be able to function properly. Domain group changes can be easily accomplished, but a large workstation group change must be scripted, or manually accomplished, prior to migration.

  • Create the target OU structure— The destination for user accounts from the source domain must be designated at several points during the ADMT migration process. Establishing an organizational unit (OU) for the source domain accounts can help to simplify and logically organize the new objects. These objects can be moved to other OUs after the migration and this OU collapsed, if you want.

Other -----------------
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 4) - Upgrading Domain and Forest Functional Levels & Moving AD-Integrated DNS Zones to Application Partitions
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 3) - Moving Operation Master Roles & Retiring “Phantom” Domain Controllers
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 2)
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 1) - Migrating Domain Controllers
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Big Bang Migration
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Beginning the Migration Process
 
 
Most view of day
- Managing Windows 7 : Managing Multiple Monitors
- System Center Configuration Manager 2007 : Network Design - Use of BITS
- Microsoft Exchange Server 2013 : Creating new mailboxes (part 1)
- Maintaining Windows 7 : Delete Unnecessary Files
- Windows Phone 8 : Designing for the Phone - Microsoft Expression Blend
- Microsoft Visio 2010 : Creating Web Pages from Visio Drawings (part 3) - Fine-tuning Web Pages and Battling Bugs - Customizing Web Page Output
- SQL Server 2008 R2 : Performance Monitoring Tools (part 12) - Viewing Data Collector Set Results in Performance Monitor
- Managing Windows Small Business Server 2011 : Adding a Terminal Server (part 2) - Installing the Remote Desktop Services Role
- Sharepoint 2013 : Service Application Fundamentals (part 3) - Connecting Across Farms
- Client Access to Exchange Server 2007 : Getting the Most Out of the Microsoft Outlook Client - Security Enhancements in Outlook 2007
Top 10
- Windows Phone 8 : Scheduled Tasks - Scheduled Task API Limitations
- Windows Phone 8 : Scheduled Tasks - Updating Tiles Using a Scheduled Task Agent
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 5) - Editing an Existing To-Do Item
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 4) - Creating the To-Do Item Shell Tile, Saving a To-Do Item
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 3) - Debugging Scheduled Tasks
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 2) - TodoService, TodoItemViewModel
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 1) - TodoItem,TodoDataContext
- Windows Phone 8 : Scheduled Tasks - Using Scheduled Tasks
- Windows Phone 8 : Scheduled Tasks - Background Agent Types
- Windows Phone 8 : Windows Phone Toolkit Animated Page Transitions - Reusing the Transition Attached Properties
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro