In this lesson, you'll investigate the tools required to prepare for an inter-forest restructure.
After this lesson, you will be able to
Estimated lesson time: 20 minutes
In Chapter 5, "Active Directory Design and Migration," you looked at how to plan the site topology as part of the Active Directory planning process. You saw that a given site is placed within a subnet and links between sites are created and that these links are identified by their slow link connections and different subnets. It is then possible to configure the amount of replication data transferred, the rate at which it takes place, and the time it's transferred. The Active Directory Sites And Services administrative tool is used to create sites, subnets, and links as appropriate. Figure 9.4 shows the Active Directory Sites And Services tool in use. A number of sites have been created to implement the topology of the imaginary Chaico corporate network.
Figure 9.4 Active Directory Sites And Services administrative tool
For detailed coverage of site design, consult Chapter 9, "Designing the Active Directory Structure," in the Microsoft Windows 2000 Server Deployment Planning Guide volume of the Microsoft Windows 2000 Server Resource Kit.
Your Active Directory site plan might also include the addition of site policies. These are managed from the Active Directory Sites And Services tool and should be applied prior to performing the restructure.
If you're performing an intra-forest restructure, the source and destination domains will already be connected by the Windows 2000 Kerberos transitive trusts. If you're performing an inter-forest restructure, a unidirectional trust must be created between the source and destination domains.
In Windows NT, trust relationships are managed by the User Manager For Domains administrative tool. In Windows 2000, the trust relationship is managed by the Active Directory Domains And Trusts tool, as was shown in Figure 9.3. The figure shows how a domain called trainkit.microsoft.com has two external one-way trusts with another domain called migrate. An external trust is one that has been manually created with another domain using the Active Directory Domains And Trusts tool or another tool such as the Netdom utility you actually used to create these trusts in the previous lesson.
When accounts and resources are migrated into a domain, they can be restructured into an OU hierarchy as defined in the Active Directory design. In Chapter 5, you saw how OUs are created using Active Directory Users And Computers. Figure 9.5 shows the OU hierarchy created in the trainkit.microsoft.com domain. The parent OU is Europe, with several OUs underneath that might reflect resource domains from an initial Windows NT configuration.
Figure 9.5 OU hierarchy of trainkit.microsoft.com
Windows NT allows the setting of policies on users and groups by means of the System Policy Editor and the Ntconfig.pol file. Windows 2000 has a much more powerful and flexible policy scheme. Policies can be applied at a number of levels, and they are also used to help with deployment and management of applications and service packs.
Remember that policies are applied via a group policy object (GPO) in the LSDOU model—in other words, Local+Site+Domain+OU.
Figure 9.6 shows properties for a Publicity OU.
Figure 9.6 GPOs for a Publicity OU
The property information for a GPO is accessed from Active Directory Users And Computers. In Figure 9.6, the GPOs TV, Press, and All Publicity Users have been applied to the Publicity OU. The assignment mechanism is similar for sites and domains because their properties also contain an entry for GPO assignments.
Settings in Press and All Publicity Users might conflict. In this case, the ordering of the policy objects in the list is used to determine precedence. The higher objects have the highest precedence, so in Figure 9.6, the settings for Press will override those for All Publicity Users.
When a user logs on, each GPO is located and applied. It is therefore advisable to limit the number of GPOs that are used at each level.
During the Active Directory design phase, the settings to be enforced and actions to be performed by each of the GPOs will be planned. During the restructure, you'll be required to create the objects and assign them according to this design. The properties of a GPO are edited using the Group Policy snap-in. Figure 9.7 shows the Press GPO being edited.
Figure 9.7 Editing the Press GPO
Note the wide range of options that can be configured for this object. It's also possible to configure logon and logoff batch files and control the installation of software for a particular user.
In this practice, you'll prepare for a migration of users from the MIGRATE domain into the trainkit.microsoft.com domain. This is an inter-forest restructure because users will be cloned from the source domain into the destination. If MIGRATE represented a Windows 2000 domain, to enable a copy operation, the MIGRATE domain would need to be in a separate forest from the trainkit.microsoft.com domain. However, because MIGRATE is a Windows NT domain, it is considered to be in a separate forest. (Ironically, Windows NT itself doesn't understand the concept of being part of a forest.)
To perform an inter-forest restructure, a two-way trust is required between the source and destination domains, auditing must be configured, and the source and destination domains must conform to the specifications laid down in Chapter 8, Lesson 4, "Inter-ForestRestructure." The destination is the trainkit.microsoft.com native-mode Windows 2000 domain. The source is the MIGRATE Windows NT 4.0 domain. A number of settings must be made correctly for the ADMT and ClonePrincipal migration tools to work. Be sure to perform each of these steps correctly on the proper server.
The DNS service must be configured and reverse lookup must be enabled if ADMT is to work correctly. The DNS server on trainkit.microsoft.com will be used for both the trainkit.microsoft.com and the migrate.microsoft.co.uk domains. You should have completed these steps in the practice in Lesson 2.
For ADMT to work, there must be two-way trust relationships between the source and destination domains. These settings need to be set up only if an inter-forest restructure is being performed. In the case of an intra-forest restructure, the source and destination domains are in the same forest and are therefore already connected via Kerberos transitive trusts.
To establish the trust for an inter-forest migration, the machines MIGRATE1 and trainkit1.trainkit.microsoft.com must both be running and be joined by an appropriate network connection. You should have completed these steps using the Netdom tool in the practice in Lesson 3. An alternative method to creating the trust relationships would have been to use the User Manager For Domains tool on the Windows NT domain and the Active Directory Domains And Trusts tool on the Windows 2000 domain.
These exercises lead you through the steps necessary for the administrators in the TRAINKIT domain to perform administrative actions on the MIGRATE domain and vice versa. First, you'll configure administrative access for both the MIGRATE and trainkit.microsoft.com domains.
The Select Users, Contacts, Computers, Or Groups dialog box opens.
Figure 9.8 Selecting Domain Admins from the MIGRATE domain
You will see the MIGRATE Domain Admins group listed with the other administrators in trainkit.microsoft.com, as shown in Figure 9.9.
Figure 9.9 Administrators group members for trainkit.microsoft.com
Now you'll add trainkit.microsoft.com's Domain Admins group to the MIGRATE Administrators group, to enable the trainkit.microsoft.com administrators to administer the MIGRATE domain and perform migration duties.
Because cloning users can be misused to breach security (for example, an unscrupulous administrator could clone a privileged user and use the user's original account to access private data), the ADMT and ClonePrincipal tools won't function unless user account management auditing is enabled on both the source and destination domains. You'll now set up user account management auditing for both the Windows 2000 and Windows NT domains.
Figure 9.10 Windows NT Audit Policy dialog box
This group is required by the migration tools for auditing purposes.
Now you'll set Audit Account Management in the Default Domain Controllers security policy on trainkit1.trainkit.microsoft.com for the destination domain, trainkit.microsoft.com.
Figure 9.11 Audit settings for the destination Windows 2000 domain
This setting will allow you to log on at your Windows 2000 domain controller using your migrated users' user names.
You must now force the policy update to be applied to the TRAINKIT domain.
You'll be told that the policy propagation has started and that you should check the Application log for any errors.
In this migration scenario the source domain, MIGRATE, is running Windows NT. A number of settings need to be made in MIGRATE for the inter-forest restructure tools to work correctly.
You are now about to edit the registry, so be careful.
If you find it difficult to edit the registry, you can double-click the Tcpipclient.reg file in the C:\Tools folder to make the changes and skip steps 2 through 7.
In this lesson, you learned that the site topology, trust relationships, OUs, and group policies must all be configured in the Windows 2000 target configuration. Each of these steps will carry out the Active Directory design discussed in Chapter 5.
Sites are configured using the Active Directory Sites And Services administrative tool. Trust relationships are configured using the Active Directory Domains And Trusts administrative tool, and the Active Directory Users And Computers tool provides access to OUs and GPOs.
When the target configuration is created, the Windows 2000 policies to be applied at each of the LSDOU levels must be implemented. Policies are applied by means of GPOs that are assigned to one or more sites, domains, or OUs. In addition to the policy mechanisms provided by Windows 2000, it might be necessary to consider how Windows NT policies provided by Ntconfig.pol are affected by the restructure.