Chapter 7: The Desired Structure and Migration Goals

Section 2:
Migration Scenarios

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.

On This Page

Introduction
DNS Architecture
Designing the Windows 2000 Domain Structure
OU Structure
Steps to Get to the Desired Structure

Introduction

This chapter describes the various decisions made by Hay Buv Toys about its desired Microsoft Windows 2000 environment and how it plans to carry out its migration.

This chapter covers the following areas:

• The planned Domain Name System (DNS) architecture

• Designing the Windows 2000 domain structure

• The proposed organizational unit (OU) structure

• The high-level migration steps

DNS Architecture

The Domain Decision

Hay Buv Toys has a centralized DNS team that mainly administers the hay-buv.com domain that the company already has registered as the public Internet name for Hay Buv's external Internet services. A few internal servers use the hay-buv.com namespace, as well as a few private subdomains for internal servers throughout the company. For example, the mfg.hay-buv.com domain is the largest subdomain that holds many of the UNIX servers for the manufacturing business unit located in Los Angeles and Mexico City.

Hay Buv Toys decided that hay-buv.com would not be the Microsoft Active Directory forest root for the following reasons:

• The hay-buv.com domain was running BIND version 4.9.7 of DNS, which does not support dynamic updates.

• There were no plans for upgrading the current environment in the timeframe necessary for Windows 2000.

• The hay-buv.com namespace has been based on business units rather than geography, and DNS has been successfully running this way for years. The Active Directory implementation will not follow the same rules.

• The configuration of the proxy service for Internet browsers requires more attention if the internal and the external DNS namespaces are the same.

As a result, the Active Directory team decided to bring up its own private root and create the hay-buv.tld domain as the Active Directory forest root.

Designing the Windows 2000 Domain Structure

Deployment Without Disruption

Hay Buv's first goal for the deployment is to deploy Active Directory as soon as possible without disrupting the end-user population. This will allow the administrators to build an OU structure to delegate authority and begin applying user-based group policy for those Windows 2000 Professional workstations that have been deployed.

The ability to delegate administration is necessary to get buy-in from the MANUFACTURING management to consolidate their domain, since they want to maintain complete control over all of their resources.

During the discussions of the new Windows 2000 domain structure, two designs were considered: a single domain for all of the enterprise or multiple domains.

Single Domain

The most positive features of a single domain design are as follows:

• Easily administered. This structure has only one domain to administer and no trusts to manage, and it truly models a central point of authority and management. Security policies like password strength and lifetime can be set in a single location, and then applied to the whole company.

• Easily reorganized. No migrations are necessary when everyone is in one domain because moving users between OUs and renaming OUs is trivial.

Moving to a Single Domain

The biggest drawback to the single domain model is that a very large population, if not everyone, would need to be migrated to the new domain.

This could be done in the following ways:

• Upgrade the largest domain and migrate into it.

  It would be possible to upgrade the largest domain as the forest root domain and migrate everyone else to this domain, but the downlevel network basic input/output system (NetBIOS) name and the DNS name would not match, for example, the HB-ACCT NetBIOS name versus the hay-buv.tld DNS name. This, while not a technical showstopper, could cause confusion for administrators and users.

• Create a new, "pristine" target domain and migrate into it.

  This left the choice of migrating everyone in the enterprise to the new, pristine single domain, which did not meet the team's first deployment goal: to deploy Active Directory as soon as possible without disrupting the end users. However, starting with a pristine domain, upgrading some domains to Active Directory, and restructuring those domains later provided a fast track for the community that wanted to move to Active Directory as quickly as possible.

Multiple Domains

To avoid the effort involved in remigrating the entire organization to a new domain structure, this design performs in-place upgrades of the existing account domains.

In-place Upgrade

In-place upgrade was a very attractive choice for the HB-ACCT and HB-ACCT-ROW domains because these are the two master account domains to which the information technology (IT) group has been moving users and groups in the past year, and they are relatively satisfied with this domain model.

Advantages of In-place Upgrade

In-place upgrades of the account domains have a big advantage over migrating users because there is no change in security identifier (SID) for user and group objects. As a result, an in-place upgrade alleviates the following migration issues:

• No change in security on positions (re-ACLing). In-place upgrades do not require the re-ACLing of resources. When you change the SID of a user or group object, you will need to update all of the security discretionary access control lists (DACLs) for the user and group object on all of the resources to reflect the new SID, which can be a sizable task.

• Preservation of user profiles. Again because users' SIDs don't change, they will not get new user profiles for Microsoft Windows NT when logging on after the migration. This is not the case when moving user objects to a new domain because Windows NT 4.0 user profiles are resolved by checking only the primary SID in the access token. So, even sIDHistory does not fix the problem of the user getting a fresh, new user profile when logging on to a new domain for the first time. In order to save the user's profile, the user's workstation must have a software agent applied to the computer in order to re-ACL and save the local profile. Tools such as the Active Directory Migration Tool (ADMT) allow translating the SID that is used for the profiles.

• Easy fallback. If problems do occur with the domain upgrade or when the upgraded domain is running in mixed mode, fallback to the Windows NT 4.0 domain is possible by removing all Windows 2000 domain controllers and promoting a Windows NT 4.0 backup domain controller (BDC) to the primary domain controller (PDC).

Using a Placeholder Domain

The hay-buv.tld domain would be established as a placeholder domain, and the current HB-ACCT domain and HB-ACCT-ROW domain will be upgraded in place as children of the hay-buv.tld domain.

The placeholder domain offers an extra security benefit over a single domain, since the Enterprise Admins and Schema Admins group would exist only in the hay-buv.tld placeholder domain. Because this domain would have very few accounts, and very few domain administrators to keep track of, it would help alleviate the problem of domain administrators adding themselves into either of these groups, which have a lot of power over modifying the Active Directory structure.

Consolidating the MANUFACTURING Domain

The second goal of the Active Directory deployment is to consolidate the MANUFACTURING domain into the new domain structure. The team considered an in-place upgrade of the MANUFACTURING domain into the hay-buv.tld domain tree. This approach would be used after the upgrade into the forest. The MANUFACTURING user and group objects would be migrated into the HB-ACCT domain later. Given the timeframe of consolidating the MANUFACTURING domain, the team determined that an interforest migration would be an easier path. Intraforest migrations are more difficult for the following reasons.

• Migrating user and group objects within the domain tree (intraforest migration) results in a destructive move, rather than a nondestructive "clone" that occurs when migrating from Windows NT 4.0 to Windows 2000 (interforest migration). This is because the user and group sIDHistory attribute must be a unique SID forest-wide, which requires an object move, rather than a copy or clone (SID would not be unique within the forest).

• Problems with intraforest migrations occur when global groups must be migrated in order to maintain access to resources. Global groups in intraforest migrations must be moved (rather than cloned), which means all of the members within that global group must be migrated at the same time in order to maintain membership within that group. On top of that, all users within each user's group memberships must be moved in order to preserve group membership. Finding this "closed set" of users and groups could be as big as every user and group in the whole domain, which would make incremental intraforest migrations very difficult.

Consolidating the Resource Domains into OUs

The third goal of the deployment is to consolidate all of the resource domains into OUs in order to eliminate trust and domain management overhead, reduce the number of domain controllers, and begin applying computer-based group policy for Windows 2000 computers and servers.

The Active Directory team determined that resource domains were no longer necessary in the Hay Buv environment with Windows 2000. Resource domains were created in Windows NT 4.0 mainly as a way to delegate authority and to avoid problems with the size of the Security Accounts Manager (SAM) database. Placing the computer accounts in separate domains from the user and global group left more room in the SAM database in the account domains for user accounts.

The Active Directory architecture does not have these issues since delegation of authority can occur by creating OUs within the domain, and the Active Directory database can scale to millions of objects without problems.

The question of keeping one resource domain still remains. The HB-MESSAGING domain may be the only resource domain that continues to exist because a major impact to the messaging system would cause too much disruption to the organization. The Active Directory team does not have enough information on how difficult it would be to consolidate the whole HB-MESSAGING domain into the new domain structure. This decision has been postponed until more information is available on what it takes to migrate the existing messaging system to the new domain, and what the Exchange 2000 migration strategy will be.

Post-Migration Cleanup

The final goal of the migration is to clean up any remnants of the old domains or retired servers resulting from the migration. These are items such as irresolvable SIDs in any of the resource DACLs, the sIDHistory attribute in all of the user and group objects that were migrated to the target domain, any broken trusts that might still be part of the domain, or old WINS entries or DNS entries that can be removed.

Proposed Structure

Eventually, the model that promised the lowest cost of ownership, the single domain model, made the race. The following diagram depicts the structure of the desired Windows 2000 domain structure.

Figure 7.1:

OU Structure

Setting Up a Hierarchy

As discussed earlier, the current resource domains will be collapsed into OUs. The OU structure is based upon the current administration of the Hay Buv network. The idea behind the OU hierarchy is to provide structure so that the design does not get out of hand and become confusing. However, the design should not be so rigid that it does not allow local administration to take advantage of and make efficient use of the new delegation and group policy features.

The migration team creates a top-level OU for the location of the main group of administrators. For example, the Los Angeles (LA) OU will be created for the administrators in Los Angeles. The LA administrators also maintain and administer the Phoenix and Seattle sites. Therefore, the Phoenix and Seattle OUs will exist below the LA OU in the hierarchy. Each OU will contain USERS, COMPUTERS, SHARES, and PRINTERS containers by default, but the administrators of the site OU can customize the structure below their OU as necessary, such as the FACTORY container in the MEXICO CITY OU that contains the factory users and resources.

The following diagram is an initial view of how the OU structure will be created. This diagram is not meant to be a full representation of the whole OU structure.

Figure 7.2:

Steps to Get to the Desired Structure

Create the Target Environment

In order to get maximum buy-off from the end users and acceptance of the project, the design team presented the desired environment and surveyed the users for their priorities: moving to Active Directory as quickly as possible, or migrating slowly with fallback in mind.

The results were different. While most users in America opted for the slower migration with fallback, the majority of the user community in Europe and Asia wanted the benefits of Active Directory as soon as possible. Therefore, two different migration strategies were chosen for the two big account domains:

• The users and groups from the HB-ACCT domain, where the American users live, will be migrated to the new domain.

• The HB-ACCT-ROW domain will be in-place upgraded as soon as the root domain hay-buv.tld exists, and then added to the forest. The users and groups from this domain can later be restructured to the hay-buv.tld domain.

The third domain that holds user accounts, the MANUFACTURING domain, will also be migrated to hay-buv.tld. However, because this domain is a hybrid that contains both accounts and resources, special care has to be taken in order to make sure that users will always have access to their resources. Therefore, this domain is chosen as the last restructure target. The more experience the team has before this critical domain is touched, the higher are the chances of a successful migration.

Consolidate Resource Domains into OUs

Another goal of the deployment is to consolidate the resource domains into OUs in order to eliminate trust and domain management overhead, reduce the number of domain controllers, and begin applying computer-based group policy for Windows 2000 computers and servers. This will accomplish the following:

1. Delete old machine accounts in the resource domains and eliminate unused/rarely used servers so that unnecessary migrations are reduced.

2. Use the ADMT to migrate computer accounts from the resource domains into OUs. These migrations consist of simple computer moves between domains.

3. Use the ADMT to migrate member servers into OUs and re-ACL the computers by replacing the old SIDs with the new SIDs.

4. Demote any resource domain BDCs that need to be moved to the hay-buv.tld domain by upgrading them to Windows 2000.

Post-Migration Cleanup

Although the use of sIDHistory will guarantee that users will have access to their resources at any stages of the migration, sIDHistory is seen as a transitional tool. Once the environment is in a stable state after the migration, the correct domain structure should be used for granting access control rights. Therefore, at some point after the migration, the team will change all access control lists applied to resources so that the access control entries now point to the primary SIDs of users and groups in the hay-buv.tld domain.

Also, removing SIDs from the sIDHistory attribute will shrink the size of the users' access tokens.