Lesson 4: Preparing for an Inter-Forest Restructure | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

In this lesson, you'll investigate the tools required to prepare for an inter-forest restructure.

After this lesson, you will be able to

Identify the tools required to build the Active Directory design for your pristine forest.

Estimated lesson time: 20 minutes

Implementing a Given Site Topology Plan

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.

click to view at full size.

Figure 9.4 Active Directory Sites And Services administrative tool

NOTE
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.

Setting Up Trusts as Appropriate

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.

Creating OUs

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.

click to view at full size.

Figure 9.5 OU hierarchy of trainkit.microsoft.com

Implementing Group Policies

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.

NOTE
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.

click to view at full size.

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.

Practice: Preparing for an Inter-Forest Migration

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.

Configuring DNS

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.

Configuring Trust Relationships Using Netdom

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.

Exercise 1: Allowing Administrator Access Between the Domains

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.

Log on to trainkit1.trainkit.microsoft.com and also log on to MIGRATE; in both cases, log on as Administrator with the password secret.
On trainkit1.trainkit.microsoft.com, open Active Directory Users And Computers.
Click the Builtin node beneath trainkit.microsoft.com.
Right-click Administrators in the right pane and select Properties from the shortcut menu.
In the Administrators Properties dialog box, select the Members tab and click Add.
The Select Users, Contacts, Computers, Or Groups dialog box opens.
In the Look In text box at the top of the dialog box, select MIGRATE.
In the Name list, select Domain Admins, as shown in Figure 9.8.

Figure 9.8 Selecting Domain Admins from the MIGRATE domain
Click Add and then click OK.
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
Click OK and then close Active Directory Users And Computers.
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.
On MIGRATE1, open User Manager For Domains.
In the lower portion of the window in the Groups section, double-click Administrators.
Click Add.
In the Add Users And Groups dialog box, select TRAINKIT in the List Names From box. TRAINKIT is the downlevel name of the Windows 2000 domain trainkit.microsoft.com.
Select Domain Admins from the Names list box and click Add.
Click OK in each dialog box and then close User Manager For Domains.

Exercise 2: Configuring Auditing

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.

On MIGRATE1, open User Manager For Domains.
From the Policies menu, select Audit.
Select Audit These Events, and then place a check mark in both the Success and Failure columns for the User And Group Management item, as shown in Figure 9.10.

Figure 9.10 Windows NT Audit Policy dialog box
Click OK.
Click anywhere in the lower portion of the User Manager For Domains window within the Groups section, and then select New Local Group from the User menu.
Name the group migrate$$$. Ensure that there are no users listed in the group and then click OK.
This group is required by the migration tools for auditing purposes.
Close User Manager For Domains.
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.
On trainkit1.trainkit.microsoft.com, open Active Directory Users And Computers.
Double-click the trainkit.microsoft.com folder to open it and then right-click Domain Controllers.
From the shortcut menu that appears, select Properties to open the Domain Controllers Properties dialog box.
Select the Group Policy tab and then select Default Domain Controllers Policy in the Group Policy Object Links list.
Click Edit to open the Group Policy editor.
In the left pane of Group Policy, expand Default Domain Controller Policy, Computer Configuration, Windows Settings, Security Settings, and Local Policies, and then click Audit Policy.
In the Audit Policy details pane on the right, double-click Audit Account Management to open the Security Policy Setting dialog box.
Set all three check marks, next to Define These Policy Settings, Success, and Failure, and then click OK. The Group Policy window should now appear as shown in Figure 9.11.

Figure 9.11 Audit settings for the destination Windows 2000 domain
Now click User Rights Assignment, which is immediately below Audit Policy in the left pane of Group Policy.
In the right pane, find the Log On Locally policy option.
Double-click Log On Locally and then click the Add button.
In the Add User Or Group dialog box, click Browse and find the Authenticated Users group in trainkit.microsoft.com.
Select Authenticated Users, click Add, and then click OK.
Click OK in the open dialog boxes to return to the Group Policy window.
This setting will allow you to log on at your Windows 2000 domain controller using your migrated users' user names.
Close the Group Policy editor window.
Click OK in the Domain Controllers Properties window, and then close Active Directory Users And Computers.
You must now force the policy update to be applied to the TRAINKIT domain.
Open a command prompt on trainkit1.trainkit.microsoft.com and type secedit /refreshpolicy machine_policy.
You'll be told that the policy propagation has started and that you should check the Application log for any errors.
Open Event Viewer from the Administrative Tools folder and check that the Application log shows no errors.

Exercise 3: Configuring the Windows NT Source Domain

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.

Ensure that you are logged on to MIGRATE1 (PC2) as Administrator.
You are now about to edit the registry, so be careful.

TIP
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.
From the Start menu, select Run, type Regedit in the Open box, and then click OK.
Expand Hkey_Local_Machine, System, CurrentControlSet, and Control, and then click LSA.
From the Edit menu select New, and then click DWORD Value.
In the right pane, type the name of the new value as TcpipClientSupport.
Double-click the new TcpipClientSupport entry, enter the number 1 in the Value Data box, and then click OK.
Close Registry Editor.
Restart MIGRATE1 so the new registry settings will take effect.

Lesson Summary

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.