Chapter 3: Domain Restructure

Article
12/09/2009

Section 1:
Migration Concepts

The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

Introduction

Domain restructure is a process that allows you to redesign the forest according to the needs of your organization. Although restructure can result in any number of outcomes, the typical result is some rationalization of the current structure and perhaps a move to fewer, larger domains.

This chapter will address:

The concepts behind domain restructure.
The supported domain migration scenarios that involve restructure.

Domain Restructure

In the past, a number of third-party directory management tools have provided domain-restructuring support for Microsoft® Windows NT®. Now for the first time, Microsoft® Windows® 2000 provides native functionality to enable domain-restructuring scenarios, namely:

Security principals that can be moved from one domain to another, either destructively or nondestructively, while maintaining pre-move access to resources.
Domain controllers that can be moved from one domain to another without complete reinstallation of the operating system.

Microsoft provides a number of tools to aid restructuring: a free graphical tool to ease domain restructuring, a scriptable Component Object Model (COM) component together with some sample scripts to illustrate how to use the component, and various command line utilities.

These will be useful to many customers implementing the scenarios described below. For customers requiring greater sophistication and graphical tools, Microsoft is working with a number of independent software vendors (ISVs) to ensure that there is also a healthy market for more fully featured third-party tools.

When Should You Restructure?

Restructuring is appropriate in three sets of circumstances:

Postupgrade. The most common time for organizations to perform domain restructuring will be as the second phase of migration to Windows 2000, following an earlier upgrade.

The upgrade will have covered the "easier" migration cases, such as groups of domains where the trust structure is essentially correct, and where there are no administrative implications.

Under these circumstances, restructuring will probably be aimed at reworking other parts of the domain structure to reduce complexity, or to bring resource domains with untrusted administrators into the forest in a secure way.
Instead of upgrade. Some organizations might decide that their current domain structure is unsalvageable, or that they cannot afford to jeopardize the stability of the current production environment during migration. In such cases, the easiest migration path might be to design and build an ideal or pristine Windows 2000 environment separate from the current production environment. Here, the new Windows 2000 forest is intended to become the production environment over time.

Once the new forest has been built, restructuring will begin with a pilot, where a number of users, groups, and resources are migrated to the new environment to act as an advance party, ensuring that business can carry on as normal in the new structure.

On successful completion of this phase, the pilot will transition into a staged migration to the new environment. At some point, Windows 2000 will become the production environment. The old domain structure will be decommissioned, and the remaining resources will be redeployed.
Postmigration. In this case, restructuring takes place as part of general domain redesign in an environment operating only on Windows 2000. This might occur several years down the line, when for some reason—such as organizational change or corporate acquisition—the current structure becomes inappropriate.

The main focus of this chapter is on the initial migration from Windows NT 4.0 to Windows 2000, namely the first two cases. Some of the approaches discussed below might prove useful in the third case, although more complete tools and techniques probably will be developed for future releases of Windows 2000.

Figure 3.1: When restructure can occur

Why Would You Restructure?

You might wish to carry out domain restructuring for a number of reasons, but the major driver is likely to be to take advantage of features on Windows 2000 that allow you to better structure your domains to reflect the requirements of your organization, such as:

Greater scalability. You might have designed your previous Windows NT domain structure around the size limitations of the Security Accounts Manager (SAM) accounts database, leading you to implement a master or multimaster domain model. With the vastly improved scalability of Microsoft® Active Directory™, scaling to literally millions of user accounts or groups, you could restructure your current Windows NT domains into fewer, larger Windows 2000 domains.
Finer granularity of administration. In your current model you might have implemented resource domains to allow delegation of administrative responsibility. Windows 2000 organizational units (OUs) can contain any type of security principal, and administration can be delegated as appropriate. In many instances, converting resource domains into OUs will be a more appropriate method for delegating administration.
Simpler administration. To allow delegation as described above, or perhaps as a result of corporate acquisition, your domain structure might be connected by a complex mesh of trusts. Some of these domains might be better implemented as OUs, thus simplifying administration. Alternately, you could redesign your domain tree and benefit from fewer, bidirectional transitive trusts.

The scenarios this chapter describes are not predicated on completion of an initial upgrade.

Implications of Domain Restructure

The fundamental enablers for restructuring scenarios are, as mentioned above, the ability to move security principals and domain controllers between domains. This section will examine the implications of these features and the impact they have on planning your restructure.

The Effect of Moving Security Principals on SIDs

Chapter 1 looked at the domain-relative nature of security identifiers (SIDs). A consequence of this is that when you move a security principal such as a user or a group between domains it has to be issued with a new SID for the new domain.

As the chapter on upgrade shows, access to resources in the Windows NT security model is carried out by the operating system, which looks at the user's access token and evaluates the user's primary SID, and the SIDs of any groups to which the user belongs, against the discretionary access control list (DACL) on the resource's security descriptor. DACLs are made up of lists of SIDs indicating approval or denial of access to the resource for the security principals that the SIDs identify. Thus, changing the SID has far-reaching implications.

To illustrate these implications, here is an example based on Windows NT security. "Bob," an employee of Hay Buv Toys, has an account in the Windows NT 4.0 master domain HAYBUV-ACCT. Bob is a member of the global group Finance Analysts in the same domain.

Hay Buv Toys uses a financial application based on Microsoft® Win32® that runs on a number of Windows NT Server machines in a resource domain HAYBUV-RES1. In order to make use of the fact that local groups created on the primary domain controller (PDC) are shared among all domain controllers in the domain, the servers on which the application runs are running as backup domain controllers (BDCs) in the domain. A shared local group called Financial Resources has been created on the PDC and is used on DACLs on the files that the application uses. The global group HAYBUV-ACCT\Finance Analysts is a member of HAYBUV-RES1\Financial Resources.

Bob also has access to a file server, FIN_FILES1, in the resource domain. FIN_FILES1 is simply a Windows NT Server computer running as a member server. FIN_FILES1 uses a local group called Finance Files on the DACLs of files relating to Bob's group. HAYBUV-ACCT\Finance Analysts is a member of FIN_FILES1\Finance Files. Bob works on some private projects and has a directory on FIN_FILES1 that is protected so that only he can access the files in that directory. This directory has a DACL that contains a single entry allowing Bob full control of the directory.

Figure 3.2: Resource access example

Moving Security Principals

As indicated earlier in this chapter, moving a security principal between domains changes the security principal's SID.

You can appreciate the implications of moving security principals by tracing what would happen if Bob's account were moved to another domain as part of a migration involving domain restructuring of two Windows NT domains. Prior to the release of Windows 2000, the only way to "move" security principals between domains was to create new objects in the target domain.

Effects of the Move on Bob's Global Group Membership

HAYBUV-ACCT \Bob is a member of the global group HAYBUV-ACCT\Finance Analysts. Because a global group can only contain members from its own domain, Bob's move to the new domain would result in his new account not being able to be a part of this group, which would mean he would lose access to resources available to this group.

Assuming sufficient trust existed between the new domain and the resource domain, it would appear that you could fix this in a number of ways:

Adding Bob's new SID to resource DACLs. You could maintain access to resources by adding Bob's new SID to the DACLs on all the resources he formerly had access to as a member of the group. This would be time consuming and messy for a number of reasons:
Many domain-restructuring operations will be carried out incrementally over a period of time, and during this transitional period there is no guarantee that new resources would not be created for the finance analysts group. Because of this, you would have to continue to regrant permission during the migration periods while the two groups coexisted.
Microsoft recommends that groups, rather than individuals, be used in DACLs. This is because the memberships of groups carrying out specific job functions can change over time, and it is easier to take a user out of a group than it is to change the DACLs of numerous resources that reference the user. What would happen if Bob's job function changed and he no longer needed to be a member of the finance analysts group?
Moving the group. You could move the group itself to the new domain. You would have to do an exercise similar to the first option, this time regranting permission to resources to refer to the SID of the new group.
Creating a parallel group in the target domain. If you were to move the group, a problem would occur if the migration plan did not envisage moving all the group members in one transaction. This would mean that you would have to maintain the group in the old domain and create a new parallel group in the new domain. You would maintain resource access for the original group and its members, but you would need to regrant permission to resources to grant access to the new group. Again, you would have to continue to regrant permission while the group existed in both domains.

Effects of the Move on DACLs Directly Referencing Bob

Our example employee Bob is also granted access to some resources on the member server FIN_FILES directly. His SID appears on DACLs on that computer. It is acceptable to add users to DACLs on resources, but one effect of Bob's move would be a requirement to regrant permission to any resources on that server, adding his new domain SID.

Microsoft has always advised the use of groups rather than individuals in resource DACLs. Many organizations might not have enforced this, resulting in a requirement to seek out and update all references to a moved user in all DACLs on resources across the organization.

SIDHistory

In Windows 2000 the position is made considerably easier as a result of a new Windows 2000 directory attribute called sIDHistory.

SIDHistory is an attribute of Active Directory security principals and is used to store the former SIDs of moved objects such as users and security groups.

When you move a user or group using new Win32 application programming interfaces (APIs) or tools and support utilities provided by Microsoft and built on top of them, you update the sIDHistory attribute of the object representing it in Active Directory with its former SID as part of the operation. When the user then logs on to the system, the system retrieves the entries in the user's sIDHistory as well as the user's group memberships and adds them to the user's access token.

Because groups can be moved, the system also retrieves the sIDHistory attributes of all the groups the user is a member of and adds these to the user's access token.

These sIDHistory entries in the token look to the system like normal group memberships during authorization checks, so they can grant appropriate access even on earlier version systems without requirements for additional software.

Note: You can update the sIDHistory attribute only in native mode Windows 2000 domains, which has the effect of requiring all migration operations relying on sIDHistory to have a native mode target for restructure.

Figure 3.3: Resource access granted through sIDHistory

Taking Advantage of SIDHistory: Moving vs. Cloning

Moving security principals can be regarded as a destructive operation because the source object no longer exists as a result of its move.

Moving security principals is not desirable in these situations:

You want minimum disruption to the production environment. While many customers want to restructure their domains in the course of migrating to Windows 2000, they have indicated that they want to do this without affecting their existing production environment. In this case, the desired approach is to create the new "pristine" Windows 2000 forest separate from the production environment, and then populate it with users and groups. In this scenario, the users and groups continue to exist in production for the purposes of fallback.
You plan an incremental migration. As you saw in the context of migrating users prior to Windows 2000, restrictions on group memberships and the need to maintain resource access make incremental migration difficult with move operations. Moving users without their global groups "orphans" users from their resource access. To avoid the same situation while moving global groups means you must move their memberships at the same time.

For the above reasons, Windows 2000 also allows a nondestructive or cloning approach to migrating security principals while taking advantage of sIDHistory. In most instances cloning will be the preferred approach to migration.

Note: Cloning is possible only between domains in different forests ("interforest"), while moving objects while updating sIDHistory is possible only between domains in the same Windows 2000 forest ("intraforest").

Cloning Security Principals

Microsoft provides support for cloning operations in three ways:

For developers. Cloning is made possible by a Win32 API called DsAddSidHistory, which takes the primary SID of a user or group in the source domain and adds it to the sIDHistory of an object of the same type in the target domain.
For administrators. Microsoft has licensed domain migration technology from Mission Critical Software of Houston, Texas. This is provided in the form of a tool, the Active Directory Migration Tool (ADMT), designed to support the migration scenarios described below. This should be sufficient for most migration requirements.
For administrators with complex requirements. In some complex environments, ADMT will not cover the migration scenario—for example, where custom scripting is required. In these circumstances, you can modify ClonePrincipal, a set of sample Microsoft® Visual Basic® scripts, to provide a custom solution.

Cloning Constraints

Because cloning is a security-sensitive operation, the DsAddSidHistory API imposes a number of constraints on the operation:

The SID of the source account must not already exist in the target forest either as a primary SID or in the sIDHistory of any security principal.
The first constraint has the effect of requiring the source and target domains to be in different forests.
To execute ClonePrincipal, the user must have administrator privileges in both the source and target domains. (For detailed instructions, please see chapters 9, 10, and 11.)
Auditing must be switched on in both the source and target domains.
User passwords are not preserved and must be re-created in the target domain.

Moving Security Principals

Microsoft provides two tools to support move operations using sIDHistory:

Active Directory Migration Tool. As well as supporting cloning operations, ADMT's user and group migration wizards support moving users and groups intraforest.
MoveTree. MoveTree is a Windows 2000 support tool. MoveTree will move objects such as OUs, groups, and user accounts.

Constraints on Moving Objects with SIDHistory

Some constraints on moving objects while maintaining sIDHistory are:

The domain from which the object is being moved (source) must be a Windows 2000 mixed or native mode domain.
Source and target domains must be in the same forest.
Populated global groups cannot be moved.
Objects must be moved in closed sets. The meaning of the term depends on whether you are referring to the movement of users and global groups, or the movement of computers, which might use shared local groups in the case of Windows NT domain controllers, or domain local groups in the case of Windows 2000 domain controllers, servers, and workstations in a native mode domain.
User passwords are preserved.

Closed Sets and Moving Users and Global Groups

As explained earlier, a global group can only contain members from its own domain. When a user moves between domains, any global groups to which the user belongs must also be moved in order to maintain access to resources protected by DACLs referring to global groups. A corollary of this is that if a global group is moved, its members must also be moved.

In this instance, a closed set of users and global groups is a set where each user's global groups are moved with the user, and each group's members are moved with the group.

If the source domain is a native mode domain, global groups can also contain other global groups, in which case each nested group's members and all global groups to which its members belong must be moved.

Closed Sets and Moving Computers

Shared local groups and domain local groups only have scope within the domain in which they were created. If such a group moved, you would be unable to resolve any references to the group in DACLs in the source domain.

In this instance, a closed set of computers and shared or domain local groups is a set in which each such group's computers in the domain containing DACLs referencing the group are moved with the group. Also, for each computer being moved, all shared or domain local groups referenced in DACLs on its resources are also being moved.

Ways Around Closed Sets

The restrictions on the movement of populated global groups and closed sets are particularly onerous. Depopulating and repopulating large global groups can be time consuming, and in some cases the smallest closed set you can achieve will be the whole source domain.

In such cases, there are three possible approaches to solving the problem:

Parallel groups. This approach creates parallel global groups in the target domain for each group to be moved, then locates all resources in the enterprise containing DACLs referencing the original group and regrants permission for them to include reference to the parallel group.

In the case of moving global groups, where the group could be referenced on resources in any trusting domain, or domain local groups from native mode source domains where domain local groups can be used on any computer in the domain, this is likely to be a large undertaking.
Universal groups. This approach switches the source domain to native mode, then changes the group type of the groups to be moved to universal. Because universal groups have scope across the entire forest, changing the groups to universal groups means that they can safely be moved while still maintaining access to resources left behind.

This approach requires some caution because, as explained earlier, the membership of universal groups is stored in the global catalog (GC), which has implications for GC replication traffic.

Because of this, you might want to use this approach as a transitional strategy while you migrate users and groups to the new domain. Then, once you complete the migration, you can change the groups back to their original types.
Cloning. This approach clones groups from the source domain into the target domain while retaining sIDHistory. This technique has some constraints, which are examined in the section "Cloning Constraints."

SIDHistory Considerations

SIDHistory provides a convenient mechanism for migrating users and groups while maintaining resource access. Some factors that you must consider if you intend to use sIDHistory to migrate are:

The implications of cloning on SID resolution.
Establishing trusts.
Moving servers.
Account deletion and cloning local groups.
Windows NT 3.51 and sIDHistory.
Profiles and sIDHistory.

Note: Special attention should be paid to the following section on "The Implications of Cloning on SID Resolution." It could determine your strategy for SID cleanup and whether to use sIDHistory.

The Implications of Cloning on SID Resolution

Perhaps the most important considerations to keep in mind when formulating your domain restructure plan relate to the way SIDs are resolved to usernames. In some circumstances when a user tries to look at the security properties of a file or folder on a Windows NTFS file system (NTFS) partition, the SIDs of users and groups that have been cloned may not be resolved and will be labeled as Unknown User. This could cause management problems because administrators might hesitate to edit DACLs for fear of preventing legitimate resource access.

To understand this problem, it helps to look at the way the API attempts to resolve SIDs. The API attempts resolution in the following order:

It attempts to find a name for the SID by first checking a list of well-known SIDs.
If the SID does not correspond to a well-known SID, the function checks built-in and administratively defined local accounts.
Next, the function checks the primary domain.
Next, the function attempts to check the SID against the SIDs of all accounts in all domains in the Windows 2000 forest, including SIDs that appear only in the sIDHistory field of an account in the forest. To look these up, the function needs to be able to query the GC of the forest.
The function checks SIDs not recognized by the primary domain or GC search against the trusted domains corresponding to their SID prefixes.

This has a number of implications:

To be able to resolve the name without querying the GC, the account that was cloned needs to be in a trusted domain, and needs to still exist.
To resolve the name as described in step 4 above, however, the computer from which the function attempts the check must either be running Windows 2000 and be a member of the target forest, or be in a Windows 2000 native mode domain that is a member of the target forest.

To avoid this problem, you should consider:
Migrating all workstations to the target forest as soon as possible after users have migrated.
Translating security on resources across the enterprise to remove references to old SIDs.
Maintaining the source account in the old domain until security on resources has been translated and all references to the old SIDs have been removed.

Establishing Trusts

In cloning scenarios, where the source and target domains are in separate forests, establishing the trusts necessary to guarantee resource access will be one of the first steps.

ADMT provides a wizard for copying trusts to and from the source domain.

Netdom.exe is another support tool provided on the Windows 2000 Server CD to carry out such tasks as enumerating domain trusts and establishing new trusts.

Moving Servers

In the previous example, Bob has access to some resources on the member server FIN_FILES1 via DACLs referencing a computer local group FIN_FILES1\Finance Files and referencing his domain account directly.

You now know that moving domain controllers requires you to maintain shared local groups and domain local groups, but what about the implications of moving a member server such as FIN_FILES1 or a workstation?

Assuming that the server was moved to a domain with trust to Bob's new account domain, sIDHistory would ensure that Bob could access resources with DACLs referencing him directly. DACLs referencing the machine local group would also continue to function because the group exists in the local machine's account database. Thus, it is unaffected by the move, and its SID would not need to be changed.

Account Deletion and Cloning Local Groups

Cloning local groups as part of domain migration may not always maintain resource access if you have decommissioned some of your source domains or removed security principals from the source domain. This arises from the way Windows NT handles local group membership cleanup—that is, what Windows NT does to a security principal's group memberships when that principal is deleted.

As a result, you should bear in mind the order in which you delete accounts or decommission account domains and clone local groups. This section will look at local group (hereafter referred to as "group") membership cleanup and its implications.

Windows NT 3.51 and SIDHistory

When planning a domain restructure, you should be aware of a known problem related to the use of Windows NT 3.51 in Windows 2000 domains.

The problem concerns authentication and authorization—specifically, the way access tokens are constructed in Windows NT 3.51. When a user is authenticated, either interactively at a Windows NT 3.51 workstation, or over the network at a Windows NT 3.51 server, the token is built using only SIDs relative to the user's account domain and local groups from the server or workstation where authentication is taking place. The result is that Windows NT 3.51 access tokens cannot contain universal groups from outside the account domain, or domain local groups from the resource domain. Since by definition entries from the user's sIDHistory, or the sIDHistory of any groups to which the user belongs, will be from domains other than the account domain, these will also be excluded from the token.

The implication of this is that with Windows NT 3.51, SIDs from domains other than the account domain of the user logging on are ignored when evaluated for access control.

In most cases, this results in denial of access, although this might not be the desired result.

Profiles and SIDHistory

When formulating your domain restructure plan, you should be aware of the implications of migrated users having new SIDs on profile use.

When a user logs on to a Windows NT workstation, the system loads a profile for that user containing user-specific configuration information. The system locates this profile by picking up the user's SID and looking in the registry under the key HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileList for a key named after the string representation of the user's SID.

An implication of this behavior is that users logging onto their workstations after migration might lose access to their logon profiles, because their primary SIDs will have changed and their old profiles will be stored under their old primary SID.

When a user has been moved between Windows 2000 domains in the same forest using a tool such as MoveTree, this will not be a problem because MoveTree preserves the user's globally unique identifier (GUID). A new feature of the profile handling code in the Windows 2000 client takes advantage of this invariance of the GUID, so that on failure to find a user's SID in the ProfileList key, the system will retrieve the user's GUID and look in the registry under the key HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows NT\CurrentVersion\ProfileGuid for a key named after the string representation of the user's GUID. If it finds such a key, it will search it for a value called the SidString, which provides a fallback mapping of the user's GUID to the user's SID. The system can then look under the ProfileList key for the SID contained in SidString, and if it finds it, rename the key to the string representation of the user's new SID. The system will in this case also change the SidString value.

From the above description, you can see that you could lose profiles in the following cases:

A user has been cloned from a Windows NT 4.0 domain.
A user has been cloned from a Windows 2000 domain.
A user has been cloned from a Windows 2000 domain, but is logging on at a Windows NT 4.0 workstation.

The following section describes some options for handling these cases.

Profile Migration

There are two basic methods of making a profile available to the migrated user while at the same time allowing a fallback route:

Shared profiles. Make the same profile available to the user's original account and the new account. One copy of the profile is accessed and updated by both accounts
Copied profiles. Copy the original profile from its current location under the key named after the user's original SID to a key named after the user's new SID. Each account is associated with its own, separate copy of the profile. Updates to one are not reflected in the other.

Both approaches have their advantages and disadvantages.

Advantages and Disadvantages of Sharing Profiles

Advantages	Disadvantages
Updates to the profile (for instance, changes to My Documents, shortcuts, and so on) while logged onto one account are accessible when subsequently logged on to the other account	When moving between the old and new accounts, results are currently unpredictable. An example would be a new Windows 2000 account profile, perhaps containing group policy references, is used when falling back to a source account where different group policy (or no group policy) is deployed.
Conserves disk space because only one copy of the profile is stored
Makes a utility available to enable profile sharing

Advantages and Disadvantages of Copying Profiles

Advantages	Disadvantages
Behavior is more predictable, and because data is not shared between the profiles, there is no chance of "polluting" the profile of one account with data appropriate only for another account in a different domain and forest.	There may be unpredictable "fallback" results with application deployment policy in the new domain. Even though the old account profile is not altered by destination account activity, applications deployed on the desktop by destination domain group policy may try, under certain circumstances, to uninstall themselves or do other unpredictable things.
	Storing two profiles consumes extra disk space.

ADMT will copy user profiles as a part of migration.

Third-Party Applications and Profiles

Whichever approach you use when migrating profiles, you should be aware that applications use profiles in a number of ways to store user-specific application state. Core user customization information such as desktop layout, Start menu contents, and so on should be easy to preserve, but you should become familiar with the actions of any third-party applications you might have installed, and how they use the profile.

Specific instances of profile-related actions you should look for are:

SID persistence. Here the application itself stores a reference to the user's SID in the profile. If the application is aware of sIDHistory, this might not be a problem. If it isn't, however, this could cause issues such as the application losing state information since the user's SID will have changed.
Locations of server or share. Here the application stores pointers to specific servers or shares where it might store data or retrieve data from. The viability of this approach will depend on the location of the server or share and its accessibility, which in turn will be governed by trust relationships.

Migration Scenarios

Microsoft provides a number of tools to help you restructure your domains during migration; this section will look at the migration scenarios for which Microsoft has designed these tools.

Domain Migration Scenarios

Microsoft has documented three migration scenarios, which will meet most customers' restructuring requirements. The scenarios are aimed at facilitating the movement of users and computers from Windows NT source domains to Windows 2000 targets. The scenarios are:

Migrating users incrementally to Windows 2000 (interforest). This scenario involves migrating users incrementally from a Windows NT source domain or Windows 2000 source forest to a Windows 2000 target forest.
Migrating resources incrementally to Windows 2000 (interforest). This scenario involves migrating resources incrementally from a Windows NT source domain or Windows 2000 source forest to a Windows 2000 target forest.
Moving users between Windows 2000 domains (intraforest). This scenario involves moving users between Windows 2000 domains in the same forest.

Migrating Users Incrementally to Windows 2000 (Interforest)

The aim of this scenario is to describe the steps and the basic utilities that an organization requires to migrate its users incrementally to a pristine Windows 2000 target forest without impacting its Windows NT production environment. This scenario is an interforest migration scenario using cloning, but the source can be a different Windows 2000 forest.

The implication of not impacting the current production environment is that the environment must remain untouched during the migration. A consequence of this is that during the migration the customer can always fall back to the old production domain should the need arise.

Once the migration is complete, the organization can decommission the old account domain and reassign the domain controllers.

Scenario Steps

The scenario steps are as follows:

Create the pristine Windows 2000 forest. Use standard procedure to create a new Windows 2000 destination forest that reflects the requirements and structure identified in the customer's namespace planning activities. Domains created in the new forest will be native mode Windows 2000 domains.
Establish trusts to maintain resource access. Use ADMT or Netdom to query what trusts currently exist from any resource domains to the Windows NT source domain, and then to establish any trusts that do not already exist.
Clone all source global groups in the target domain. As discussed earlier, most resources will be protected using DACLs that reference global groups, usually indirectly via shared or machine local groups. Once trusts have been established, the next task is to ensure that the relevant global groups are available in the target domain.

The simplest way to achieve this is to clone all global groups using ADMT or ClonePrincipal.
Identify and clone sets of users. Once the source global groups have been cloned to the target domain, the task of migrating users can begin.

Because in most instances the customer will want to move sets of users incrementally, this will be an iterative task—identifying the sets of users to migrate and then using ADMT or ClonePrincipal to clone the source users in the destination domain.

As part of this task, you will have to add each migrated user to the destination clone of any global groups in which it was a member in the source domain.
Decommission the source domain. When all users and groups have moved permanently to the destination forest, the final task will be to decommission the source domain, which involves powering off and removing the source domain BDCs, and finally the source domain PDC.

If the intention is to reassign these domain controllers in the new forest, then they can be upgraded to Windows 2000 and either promoted to domain controllers or left as member servers as described earlier.

Each step in the scenario should be tested, particularly during the user migration phase. It might be prudent to test logon for certain users during each migration. If an error occurs at any stage prior to decommissioning, you can suspend the process and continue work in the source production domain.

Figure 3.4: Migrating users incrementally to Windows 2000 (interforest)

Migrating Resources Incrementally to Windows 2000 (Interforest)

The aim of this scenario is to describe the steps and the basic utilities that an organization requires to consolidate a number of resource domains into an OU in a native mode Windows 2000 domain. Typically, the impetus for this is to reduce the costs of administering complex trusts.

As part of this scenario, the application servers will become member servers in the target OU. It is assumed that the application servers in each domain will be making use of shared local groups. It is also assumed that the domains may contain some member servers and workstations.

Once the restructuring is complete, the organization can decommission the old domains.