ADMT—The Road to Migration

As Windows 2000 starts to permeate the IT marketplace, more companies are considering migrating their Windows NT 4.0 environments. When you decide to migrate your network from NT 4.0 to Win2K (i.e., do an interforest migration), you can choose to perform a domain upgrade or implement a domain restructure.

A domain upgrade, or in-place upgrade, involves migrating an NT 4.0 domain's PDC and BDCs from NT Server 4.0 to Win2K Server. This approach is the most common migration method and the easiest, least risky route to take. (For information about in-place upgrades, see Douglas Toombs, "Migrating Domain Controllers to Windows 2000," February 2000.)

A domain restructure, or domain consolidation, involves creating a Win2K forest and migrating your existing NT 4.0 domains to it. This migration method lets you design an ideal forest and consolidate or collapse your NT 4.0 domains as needed. The domain restructure also lets you fall back to the existing NT environment at any time because this method establishes a parallel environment for migrating your network. You can therefore continuously develop your Win2K structure while preserving your existing NT production environment.

Until recently, the majority of migrations were in-place upgrades. The domain restructure alternative often produced concerns regarding the smooth migration of users and groups between domains. However, Microsoft has successfully addressed these concerns with its introduction of the Active Directory Migration Tool. ADMT provides an easy-to-use set of task-based migration wizards that make implementing a domain restructure a breeze.

The Right Tool for the Job
To implement a domain restructure, you can use a combination of scripting and command-line tools (e.g., Netdom, ClonePrincipal, SIDWalker, MoveTree) from the Microsoft Windows 2000 Resource Kit. However, when you use ADMT for a domain restructure, the migration process from NT 4.0 to Win2K is quicker and easier than the scripting-based approach. ADMT's primary purpose is to deliver an easy and secure migration path from NT 4.0 to Win2K's Active Directory Server (ADS).

Microsoft licensed ADMT from Mission Critical Software and offers the migration utility at no cost. (Go to http:// www.microsoft.com/windows2000/ downloads/deployment/admt/default .asp to download a copy.) ADMT installs as a Microsoft Management Console (MMC) snap-in that includes several task-based wizards. These wizards support the migration of users, groups, and computers without requiring many of the operational intricacies that using scripting or command-line migration utilities does.

ADMT also greatly simplifies migrating from earlier NT versions. For example, you can undo the most recently performed user, group, or computer migrations. You can also migrate service accounts, such as the Exchange Service Account, and easily recreate trust relationships from your source domain to your target domain. You can restructure existing groups or merge multiple groups into one group in the target domain. ADMT lets you collapse existing NT 4.0 resource domains into Win2K organizational units (OUs) to simplify network resources management. You can also use ADMT to collapse multiple domains into fewer larger domains within an existing Win2K environment.

ADMT's most appealing feature is that it lets you perform trial migrations in a parallel environment. ADMT logs migration events so that you can analyze your migration's impact (e.g., user and group creation, group memberships) before and after your actual migration process. You can also review and control how ADMT processes user accounts, passwords, computers, groups, and security details during migration.

Source and Target Domain Requirements
ADMT requires two domains for migration—the source domain and the target domain. ADMT further requires that the source domain run Service Pack 4 (SP4) or later on the PDC. ADMT runs only on Win2K computers, and the target domain must be running Win2K in native mode (i.e., all domain controllers in the domain must be Win2K domain controllers).

The Earth Satellite Company Scenario
Let's use an example to demonstrate the steps you follow when you use ADMT to implement a domain restructure. Figure 1 shows that the Earth Satellite Company has one NT 4.0 master domain (i.e., the Earth domain) for storing accounts and two resource domains, Earth-Res1 and Earth-Res2. Table 1 and Table 2 define the Earth domain's users and groups.

The company wants to migrate the users and groups from the Earth domain (i.e., the source domain) to a new parallel Win2K environment that the company created. The target domain is the moon.base.com domain (or the Moon domain, to downlevel clients). ADMT requires a two-way trust between the source and target domains, which Figure 2 shows.

Preparing a test environment. As the Earth Satellite Company's systems administrator, you must establish a suitable test lab environment that accurately mirrors the company's current production environment before you migrate the domains. A good practice is to clone your production PDC and move the clone to a physically separate test lab environment. (You can perform the same procedure for BDCs to create an accurate copy of your production domain for migration testing.)

You also need to build clone servers to represent a reasonable sample of the application or member servers that your real production environment uses. I strongly recommend that you fully test migration procedures in an isolated test environment before you implement them.

Ensuring that the target domain is in native mode. The target domain must be in Win2K native mode for the migration process. To change to native mode on the target domain, perform the following three steps:

1. Open the MMC Active Directory Domains and Trusts snap-in, then right-click the moon.base.com domain in the Tree pane.
2. Choose Properties from the context menu, then click Change Mode on the General tab.
3. Click Yes to confirm the change to native mode, and close the Properties dialog box.

Switching to native mode is a manual process—Win2K doesn't automatically initiate the change. After you enable native mode, you can't reverse this step. Support for downlevel replication and downlevel domain controllers ceases, and you can't add more BDCs to the target domain. At this point in the migration process, the Earth-PDC server, which was the PDC during migration, is no longer the domain master. In native mode, all domain controllers are peers.

Ensuring that auditing is enabled on the source and target domains. ADMT requires you to enable auditing for account management (i.e., success and failure events) in the source and target domains. (Remember that in NT 4.0, account management is known as User and Group Management.) To enable auditing in the source domain, complete the following five steps:

1. Ensure that you are logged on with administrative privileges.
2. Select Start, Programs, Administrative Tools, and open the User Manager for Domains.
3. Select the Policies menu, and click Audit.
4. Click Audit These Events.
5. Select both the User and Group Management Success and Failure events.

To enable auditing in the target domain, perform these eight steps:

1. Log on to the domain with administrative rights.
2. In the MMC Active Directory Users and Computers snap-in, double-click moon.base.com.
3. In the left pane, right-click the Domain Controllers OU and select Properties from the drop-down menu.
4. On the Properties window, select the Group Policy tab.
5. Select Default Domain Controllers Policy, then select Edit to launch the MMC Group Policy snap-in.
6. The Group Policy window will appear on your screen. Under Default Domain Controllers Policy, choose Computer Configuration, Windows Settings, Security Settings, Local Policies, and Audit Policy.
7. Select Audit Account Management, then choose Define These Policy Settings.
8. Select Success and Failure, then click OK. Close all opened windows.

Configuring trusts between the source and target domains. The two-way trust between the source and target domains establishes the access rights that ADMT requires to migrate the security principals across domains. To configure this trust, complete the following five steps:

1. In the target domain, select the Active Directory Domains and Trusts snap-in.
2. In the Active Directory Domains and Trusts snap-in window, select the target domain and right-click the domain object.
3. Select Properties, then select the Trusts tab. Click Add to complete your selections for Domains trusted by this domain and Domains that trust this domain to configure the trust to the source domain, as Figure 3 shows.
4. In the source domain, open User Manager for Domains.
5. Select Policies, then select Trust Relationships. Click Add to configure the trust to the target domain, as Figure 4 shows.

After you establish the domain trusts, make sure that you have administrative rights in the source and target domains. You'll need administrative rights on each computer you migrate, as well as on any computer that you want to translate security on. To perform the migration, you also must have administrative rights on any computer that ADMT installs an agent on. Because ADMT can install and remove agents on separate machines, it always assumes the presence of default administrative shares on those machines.

Configuring destination containers on the target domain. Before you migrate the users and groups from the source domain, you need to create a destination container in the target domain. Destination containers are OUs within Active Directory (AD). If you don't create a new container, ADMT will place all users and groups that you migrate in the default users container in the target domain.

To create the Moon Users and Groups OU (i.e., the destination container) in the moon.base.com domain, complete the following three steps:

1. Open the Active Directory Users and Computers snap-in.
2. Select and right-click the moon .base.com domain, then select New, Organizational Unit.
3. Enter Moon Users and Groups in the text box, then click OK.

Figure 5 shows the Moon Users and Groups OU you created in the moon.base.com domain. You can follow the same process to create any OU groupings you choose, such as separate OUs for users, groups, and computers.

Using ADMT to Migrate Domains
After you configure your migration prerequisites, you can use ADMT to migrate selected users and groups from the source domain to the target domain. For the Earth Satellite Company, let's migrate all users and groups in one operation.

Installing ADMT. The first step is to install ADMT. To do so, complete the following eight steps:

1. Download the ADMT.msi file from Microsoft's Web site at http://www .microsoft.com/windows2000/downloads/ deployment/admt/default.asp.
2. Log on with administrative privileges in the target domain.
3. Run the admt.exe utility to extract the ADMigration.msi program file.
4. Click Next on the Welcome window.
5. Review the terms of the License Agreement, click I accept the License Agreement (if you agree with the terms), and click Next.
6. In the dialog box that appears, specify where you want to install ADMT, then click Next to display the Start Installation window.
7. Click Next to install ADMT.
8. After the ADMT installation is completed, click Finish.

Migrating. Now you can use the ADMT User Migration Wizard to migrate users and groups from the source domain to the target domain. To migrate users and groups, perform the following 14 steps:

1. Select Start, Programs, Administrative Tools, and open the MMC Active Directory Migration Tool snap-in.
2. Select Active Directory Migration Tool from the snap-in's window's Tree (left) pane. Right click and choose the User Migration Wizard option.
3. Click Next in the User Account Migration Wizard Welcome window.
4. Choose the Migrate Now option, and click Next.
5. In the Domain Selection window, select the Earth domain as the source domain and the moon.base.com domain as the target domain. Click Next.
6. In the User Selection window, click Add, then select all users in the Earth domain. Don't choose built-in local groups from the Earth domain because the SIDs for these groups are identical in every domain. Click Next.
7. In the Organizational Unit Selection window, click Browse, then choose the destination container (which is the Moon Users and Groups OU in our example) for the migrated users and groups. Click Next.
8. In the Password Options window, choose Complex Passwords to automatically generate complex passwords for each migrated user. ADMT creates and stores the passwords for you in a text file, and you can distribute these passwords to your users later. The default location for this file is \%program files%\active directory migration toollogs\passwords. Click Next.
9. In the Account Transition Options window, click Migrate User SIDs to Target Domain to add the migrated accounts' SIDs to the new user account SidHistory attribute in the target domain. (You also can disable source accounts on the source domain PDC at this point, but don't choose this option unless you want to do a full migration practice.) Click Next.
10. In the User Account window, enter your source domain username and password that have administrative authority in the source domain. Click Next.
11. In the User Options window, select Translate roaming profiles, Update user rights, and Migrate associated user groups, as Figure 6 shows. This step associates a user's roaming user profile with the new user account in the target domain. These selections also assign the same user rights in the target domain as in the source domain, as well as migrate source domain groups that the migrated users are members of. If you performed multiple migrations, you might want to select Update Previously Migrated Objects to ensure that all user groups are correctly updated. Click Next.
12. In the Naming Conflicts window, select the account name conflict resolution you need. The default is Replace Conflicting Accounts. Click Next.
13. In the Completing User Account Migration Wizard window, click Finish.
14. You can now choose to view the log files or to continue. Select Close. The ADMT User Migration Wizard has now migrated all selected users and groups from the source domain to the target domain.

Landing on the Moon
To confirm that you successfully migrated all users and groups from the source domain to the target domain, confirm that you're logged on to the target domain with administrative rights. In the Active Directory Users and Computers snap-in, double-click the moon .base.com domain to open it. In the Tree pane, select the Moon Users and Groups OU. The snap-in window's right pane displays the users and groups from the source domain, as Figure 7, page 96, shows, which signifies that the migration was successful.

To confirm that the migrated groups retained their properties from the source domain, right-click a group in the window's right pane, and select Properties to display general property information. Several tabs provide information about the group (e.g., the group's assigned members, who performs group management, general group security). For example, right-click the Apollo group, select Properties, and choose the Members tab. Figure 8, page 96, shows that the migrated Apollo group retained the same group members from the source domain.

Analyzing Migration Events
ADMT supplies a rich set of features for monitoring your migration process. You can use the standard Win2K and NT Event Viewer to view migration events, review automatically generated ADMT logs that show all the ADMT migration actions, or execute the ADMT snap-in's ADMT Reporting Wizard to get detailed migration summaries. ADMT lets you perform several trial migrations (which don't change your environment) to fine-tune your actual migration. ADMT also lets you undo the most recently performed user, group, or computer migrations.

If you encounter problems during migration or if you want to review the operations that ADMT conducted, the ADMT-generated log files provide an accurate snapshot of all migration activities. Each time ADMT performs a migration operation, it generates in the log file an entry that details the operations ADMT has carried out. ADMT generates the log file to the \%program files%\active directory migration tool\ logs folder by default. The name of the log file is migration.log. This file is extremely important because it chronicles all migration events, as well as describes successes and failures.

Figure 9 shows a portion of the log file that the migration process from the Earth Satellite Company generated. The log shows that ADMT identified that it will copy users, global groups, and local groups from the Earth source domain. The log's next entry tells that ADMT created the user Aldrin and the SID History attribute. ADMT then created the global group Apollo and regenerated the SID History attribute. The log's next line shows that ADMT set Aldrin's password and placed it in the password file. Finally, ADMT added the user Aldrin to the Apollo group and ensured that Aldrin retains its properties from the source domain.

Smooth Migrating
ADMT makes using the domain restructure approach for migrating to Win2K an attractive option. The reason is that the tool lets your developing Win2K structure and your NT production environment happily coexist. Although you can use the scripting-based approach to migrate your network, you might find ADMT's instant and powerful migration capabilities an attractive alternative.

As always, detailed planning and testing are the keys to a smooth migration project. However, ADMT makes the road to migration less bumpy.