SQL Server Magazine

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.

   Prev. page   [1] 2 3     next page