In this lesson, you'll learn how to migrate the domain controllers, member servers, and workstations into the pristine environment after the inter-forest or intra-forest restructure strategy has been decided and planned. You'll also consider the issue of local groups in a migration.
After this lesson, you will be able to
Estimated lesson time: 15 minutes
The final aspect of a restructure is to move the member servers and workstations into the pristine environment.
A member server is a system that has joined a domain. It doesn't take part in security authentication, but any domain global groups and users in the domain of which it is a member can have access to resources contained on the member server. Unlike a Windows NT domain controller, a member server can be moved from one domain to another simply by registering the computer account in the new domain.
You can't clone workstations and member servers because you might find yourself in problem situations where components such as duplicate computer names exist on the network. The technique used here is to move the computer to the destination Windows 2000 domain using the ADMT or Netdom migration tools or by manually configuring the computer to join the new domain. The manual method can be time-consuming if you have a substantial number of workstation clients to move.
Prior to moving your member servers and workstations via Netdom, ADMT, or a third-party migration utility, ensure the following:
Upgrading a Windows NT member server to a Windows 2000 server makes the movement of the resources into the new target domain much easier. Once the upgraded member server is part of the Active Directory domain, it can remain as a member server or be promoted to a domain controller.
The security boundary of a member server's local group is different from that of a domain local group. The security boundary for a member server's local group is the server (or workstation) that it is created on because it's held in the local system's security database. You can't move or clone local groups held on workstations or member servers. The only way to move them into a new domain is to migrate the entire computer.
When you migrate the computer to a new domain, access to the resources on the computer could be affected if the local groups on the system contain members from domains that were trusted by the source domain. For example, if a domain called FINANCE trusts a domain called EUROPE and has global groups from EUROPE contained in some of its local groups, when the member server is moved to a destination domain called trainkit.microsoft.com, the local group will have no understanding of the global groups from EUROPE, as shown in the diagram in Figure 8.13. You can avoid this situation if the destination domain already has an identical trust relationship established with trainkit.microsoft.com.
Figure 8.13 Effects of a migration on access to resources
When a Windows NT BDC is upgraded, the Active Directory installation wizard will allow you to select the target domain for the upgrade. You can direct the upgrade to the original domain if an in-place upgrade is being performed, or it can be a pristine environment if the domain is being restructured.
To move a Windows 2000 domain controller, it must first be demoted to a member server in the source domain so that it takes no part in the Active Directory. You can do this via the Dcpromo utility. Dcpromo alternates the state of a server, promoting member servers to domain controllers, and demoting domain controllers to member servers. The member server can then be moved into the target domain in the same way as any other member server. Once it's part of the Active Directory domain, it can be reinstated as a domaincontroller for the new domain by running Dcpromo again. You'll see how this works in Chapter 10, "Post-Migration Tasks."
The first controller upgraded in a Windows NT domain must be the PDC.
In this lesson, you learned the following: