Lesson 6: Planning and Prioritizing the Migration of Domains

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

• Prioritize the order in which domains are migrated and consolidated.
• Analyze a Windows NT domain arrangement and develop a migration strategy for it based on a given set of migration goals.

Estimated lesson time: 60 minutes

---

Upgrading Account and Resource Domains

A Windows NT environment has four standard domain models:

• Single domain. For a small department or company, a single domain directory can handle both resources and user accounts.
• Master domain. A master domain handles user accounts and has one or more resource domains trusting it.
• Multiple-master domain. Accounts are split among multiple master domains that contain two-way trusts between each accounts domain. All resource domains trust all master domains, enabling resources to be conditionally available to all users.
• Complete trust domain. User accounts and resources are kept in all domains. Every domain has a two-way trust with every other domain. The number of trusts that need to be managed is equivalent to n times (n-1) where n is the number of domains.

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.

Order of Upgrade

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.

Upgrading Account Domains

When considering the order in which to upgrade account domains, keep the following factors in mind:

• Physical access. It might be easier to upgrade account domains where you have good access to the domain controllers. This makes it easy to physically swap machines around if problems occur.
• Minimum risk and disruption. Account domains with the smallest set of users won't cause as many problems as ones with larger numbers, should anything go awry. From this perspective, running parallel Windows 2000 and Windows NT systems is ideal because you can always reassign users to the original environment. If you're performing an in-place upgrade, always have a fully synchronized BDC available (but offline).
• Combining an upgrade with a restructure. Remember that the first domain migrated will be the forest root unless you've already installed a Windows 2000 root placeholder. If you don't have a root placeholder, assess all your account domains to ascertain which one you'd like to use as the forest root—but balance this need with the previous point about first moving the fewest accounts possible to minimize risk.

Upgrading Resource Domains

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:

• User and application requirements. Pay particular attention to applications that require support from downlevel servers and those that will be making use of the new features provided by Windows 2000, as is the case with Microsoft Exchange Server 2000. In general, domains requiring the use of Windows 2000–based applications will need to be migrated first.
• Large-scale upgrades. As soon as you're confident with your upgrade procedures, you should upgrade domains containing large numbers of resources so that you can better control access and management of these resources.

NOTE

---

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.

Additional Considerations

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.

Practice: Evaluating Migration Scenarios

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

Migration Scenario: Company One and Company Two

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 Migration Goals

Company One has set the following migration goals:

• A reduction in the number of domain controllers
• Minimal impact on the employees in the company
• Minimal additional hardware
• A simpler setup for authentication procedures
• A highly scalable platform for expansion of the IT infrastructure throughout the company

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.

1. Consider each of these goals. Specify whether each design meets the goals and then explain why or why not. Assume an in-place upgrade takes place for all systems.
   • A reduction in the number of domain controllers
     
     
     
   • Minimal impact on the employees in the company
     
     
     
   • Minimal additional hardware
     
     
     
   • A simpler setup for authentication procedures
     
     
     
   • A highly scalable platform for expansion of the IT infrastructure throughout the company
     
     
     
2. Determine which domain should be upgraded first and explain why.
   
   
   
3. Determine which domain should be upgraded next and explain why.
   
   
   
4. Identify any points of risk in this migration and how to reduce them.
   
   
   

   Proposed Restructure

   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.

5. Evaluate whether the pristine restructure design will meet the following migration goals and explain why or why not.
   • A reduction in the number of domain controllers
     
     
     
   • Minimal impact on the employees in the company
     
     
     
   • Minimal additional hardware
     
     
     
   • A simpler setup for authentication procedures
     
     
     
   • A highly scalable platform for expansion of the IT infrastructure throughout the company
     
     
     

   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:

   • Fewer domains make the management of operations and hardware simpler.
   • OUs can be deployed in all domains to decentralize administration.
   • An upgrade of a network with a single account domain will impact all the users at the same time.
   • Any kind of phased approach will require additional hardware and network support.
   • It might be sensible to base domains around geographical locations to reduce replication and authentication traffic.
   • Domain-naming issues might restrict how a pristine environment can be deployed.
6. Identify at least six additional questions you would ask the management of this company when deciding the suitability of any Active Directory design.

   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:

7. In general, which domains should be copied into the pristine environment first: resources or accounts?
   
   
   
8. Identify any points of risk in this migration and how they can be reduced.
   
   
   

   Company Two Restructure Migration

   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

9. Explain why the arrangement shown in Figure 5.11 is a poor one in terms of how the authentication of resource access is performed. Suggest how this can be improved and suggest the next step in a phased upgrade involving this configuration.
   
   
   
10. What are the DNS names of each of the domains? How do the names relate to the domain design?
    
    
    

    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.

11. The design shown in Figure 5.12 is quite strange. What additional goals would justify creating the two account OUs and the three resource subdomains?
    
    
    

    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

12. Examine this configuration and explain why this arrangement is poor as a final design. Hint: Consider the trust referrals that will occur during authentication.
    
    
    

    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.

13. One of the IT managers at Company Two wants to make Company One and Company Two separate forests rather than combining them. List as many reasons as you can to support this strategy and then list reasons to refute the strategy.
    
    
    

Answers

Lesson Summary

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.