One of the key aspects of your migration is determining the order in which to migrate Windows NT domains. You might also want to combine some Windows NT domains prior to or during their migration to Windows 2000 domains. This lesson explains how to develop a strategy for deciding which domains to upgrade first and when consolidation is warranted. You will also analyze several domain migration designs to develop an appropriate Windows 2000 Active Directory design.
After this lesson, you will be able to
Estimated lesson time: 60 minutes
A Windows NT environment has four standard domain models:
Apart from the single domain model, each domain model uses a combination of account domains and resource domains. When planning the sequence of upgrading domains, make sure that objects in the resource domains remain accessible during the migration. As you'll see in Chapter 8, Lesson 3, "Types of Restructure," resource domains can be kept accessible during the migration using a Windows 2000 feature known as SIDhistory.
In general, if you have account domains and resource domains, you should upgrade the account domains first. An upgraded domain will result in a Windows 2000 domain controller that will perform PDC emulation so that the server can still interact with downlevel systems in other domains. The destination domain should have an appropriate trust relationship with the resource domains so that migrated objects can still have permissions on (and therefore access to) objects in the resource domain.
When considering the order in which to upgrade account domains, keep the following factors in mind:
Although you might find reasons not to consolidate account domains, resource domains are ideal for consolidation. Therefore, you need to decide whether you'll consolidate resource domains into OUs within account domains or into their own domain. Wherever possible you should try to consolidate your resource domain into the accounts domain, unless there are technical or political reasons why you cannot do this. There are several schools of thought on whether to migrate your largest or smallest resource domains first. If continuity of service is a priority, you should consider migrating smaller resource domains first in case a disaster occurs. You will also be able to gain some experience from the smaller migration that can be applied to the migration of the larger resource domains. When you're considering the priority for upgrading resource domains, the following factors are significant:
There is no one rule of thumb or perfect way to perform migration. Your resource and account domain migrations will also be dictated by political factors, application requirements, and user needs. For example, you might decide to migrate a large resource domain first because it is operating so poorly that any change would be beneficial for the users.
The previous rules apply to pure account and resource domains. However, your Windows NT structure might not fit so easily into these categories. For example, in the case of a complete trust environment, you'll have domains that have a mixture of users and resources. In this case, try to migrate the domain with the fewest users and resources first, and then work your way up as your team becomes more experienced with the challenges associated with your organization.
You might also have domain dependencies caused by line-of-business or other distributed applications. This might force you to migrate the account domains and their associated resource domains before you can migrate other account domains. In particular, look at applications that require reliable network transactions with servers in other domains. Examples include warehousing database applications that require publishing and subscription-type services and domains containing corporate messaging systems that regularly replicate such information as global address lists and routing information between them.
The remainder of this lesson is a practice that presents various migration scenarios for a company with a particular domain configuration. You'll design the best configuration based on specific migration goals. Remember that the optimal solution might be an evolving process that you finally reach by making a different set of compromises than originally envisioned. Answers to the practice questions are contained in Appendix A, "Questions and Answers."
Consider the following migration of a fictitious corporation that has a distributed IT network. In this scenario, the corporation has been formed from the merger of two fictitious companies we'll designate as Company One and Company Two. Assume that Company One has facilities in Europe, America, and Asia, and assume that Company Two has facilities in Europe and America. Figure 5.8 shows the domain arrangement for the two companies before their merger and before their migration to Windows 2000.
Figure 5.8 Windows NT domains used by companies before migration
Company One uses a single-master domain model with one account domain and multiple resource domains. User accounts are held in the ACCOUNTS domain and the resources are held in EUROPE RESOURCES, AMERICA RESOURCES, and ASIA RESOURCES domains. Each of the resource domains has a one-way trust relationship with the account domain so that users from the ACCOUNTS domain can be given access to resources in any domain.
Company Two uses a multiple-master domain model, with two account domains organized by business function. One set of accounts is for use by management and the other is for use by the production divisions.
In this scenario Company One and Company Two have completely separate domains and management, reflecting their separate origins. Management wants to preserve the two divisions as separate entities because they sell into different market sectors; therefore, management has asked the IT departments of each division to prepare proposals for the upgrade.
Company One has set the following migration goals:
Company One Proposed Upgrade
In this scenario the IT support division at Company One has proposed to perform an upgrade to their domains, as shown in Figure 5.9.
Figure 5.9 Windows NT domain upgrade plan
The Active Directory tree for Company One contains four domains organized as shown. The parent domain has three child domains, each of which reflects the geographical location of the company resources. The root of the domain uses the company's registered DNS name, which will be represented in this example as microsoft.com. The child domain names are the relative name of the parent with the geographical location added. The child domains are the old resource domains and the parent domain is the old account domain.
All the domains in the tree share the same Active Directory schema and global catalog. The explicit one-way trusts created in the Windows NT domain arrangement are replaced by automatic Windows 2000 transitive trusts. Note that because the trusts are now two-way, the distinction between account and resource domains no longer holds because resources in any domain can potentially be accessed by accounts in any other. This potential security loophole must be addressed during the upgrade.
As an alternative to the upgrade scenario, the Company One IT support division has also designed a domain restructure plan. Figure 5.10 shows a restructured Windows 2000 domain with four OUs. Note that each of them could have been set up as separate OUs with no parent OU. However in this case a parent OU has also been created.
Figure 5.10 Plan for a single-domain restructure with several OUs
The OU structure shown makes it possible to have managers (in the Account OU) who can control user accounts in any of the territories, as well as to have managers in particular geographical OUs who each control his or her own region.
Note that collapsing the domains into one domain as done here has implications for the naming of objects. In the configuration given in Figure 5.9, objects could only be placed in the asia.microsoft.com domain if they're physically located in Asia. This is because each domain represents a particular area of the namespace.
In the configuration in Figure 5.10, the only namespace is microsoft.com. An OU is a mechanism for decentralizing control, but the OU doesn't have any bearing on the physical location of its objects. Therefore, resources physically located in Asia could be placed in the Asia, Europe, or America OUs. It is essential to have naming standards to ensure that objects are named appropriately. Microsoft suggests that standards must be set such that servers located in Asia have the prefix AS. This policy is to be applied to both resources and accounts.
Deciding Between the Upgrade and Restructure Scenarios
The two scenarios just described represent both extremes of a migration. In the upgrade design, the original structure is retained as much as possible; in the restructure design, it's completely discarded. When deciding which approach to take, consider the following:
Implementing the Migration Scenario
Presume that after discussion within the management, it is decided to adopt a single-domain configuration as shown in Figure 5.10. It's also decided to perform the migration by creating a pristine environment into which the objects will be migrated. Consider the following questions:
Company Two has set the same migration goals as Company One. One of the problems for Company Two is whether to create a placeholder root domain or to use one of the account domains as the Active Directory root—and, if the latter, which account domain should be used. Answer the following questions as you review some of the possible designs.
Making One of the Account Domains the Active Directory Root
Figure 5.11 shows a design in which the MANAGEMENT ACCOUNTS domain has been upgraded to be the Active Directory root, and the PRODUCTION ACCOUNTS domain is now beneath it in the tree.
Figure 5.11 Using one of two Windows NT account domains as the Active Directory root
Adding a New Active Directory Root
In Figure 5.12, a new account domain has been created at the root of the Active Directory tree that contains the user accounts from the original Windows NT MANAGEMENT ACCOUNTS and PRODUCTION ACCOUNTS domains. These have been divided into two OUs. This consolidates two domains while allowing the delegation of management as before. The three resource domains remain as three separate domains.
Figure 5.12 Adding a new root domain containing OUs
The consolidation could have been performed by making one of the Windows NT account domains the root of the Active Directory tree and moving objects from the other account domain into it, or by creating a pristine environment at the root of the forest and copying objects from both account domains into it.
Adding a Placeholder Domain at the Root
In Figure 5.13, the domain msn.com has been created as the root, and all the other domains have been created beneath it at the same level in the directory tree.
Figure 5.13 Adding a new account domain as the Active Directory root
Arriving at a Final Design for Company Two
The final design should evolve from the previous designs, giving consideration to all the issues just mentioned. The optimal design might be to create a new, pristine environment that forms the root of a new tree and migrate as many of the domains as possible into an OU structure that might include Management and Production as first-level OUs. You could then have London, Paris, and New York OUs reporting to the Management OU, and you could have another set of London, Paris, and New York OUs reporting to Production OU.
In this lesson, you learned that when planning a migration, account domains should generally be upgraded before resource domains. You investigated several ways to migrate two Windows NT corporate domain structures to an optimal Windows 2000 design. You also learned that each domain should be upgraded as part of a phased-in design during which the migration goals are always kept in mind. For further in-depth scenario-based migration examples, see the Domain Migration Cookbook on the Supplemental Course Materials CD-ROM.