Planning a Domain Upgrade | Microsoft Windows 2000 Server Administrators Companion (IT-Administrators Companion)

[Previous] [Next]

Upgrading a Windows NT domain to a Windows 2000 domain isn't quite the three-click process that you perform when upgrading a single Windows NT 4 workstation. In fact, considerable planning is necessary before you even start Windows 2000 Setup on the first computer. Some computers, such as the PDC and BDCs, must be upgraded in a specific order, with the PDC being upgraded first. Other computers, such as Windows NT member servers and stand-alone servers, as well as client computers, can be upgraded at any time before or after the actual domain is upgraded.

Before you begin upgrading an existing Windows NT domain, it is important to assess the current network and plan the upgrade approach you want to take. This section will help you determine what parts of the existing network you should document, create a recovery plan, plan the first Active Directory tree and the site topology, and come up with a general upgrade strategy.

Documenting the Existing Network

The first step in planning an in-place domain upgrade is to document the current network structure. To do so, you will need to make a note of the existing domain model, the existing trusts, the number and location of the domain controllers, the account and resource domains, the DNS namespaces currently in use, the application servers, and any Windows NT 3.51 servers. The sections that follow describe how to document each of these features.

NOTE
An in-place domain upgrade is a domain upgrade that is performed while leaving the domain intact. Domains can also be upgraded by removing the PDC from the domain, leaving the BDCs to provide services. You upgrade the PDC to Windows 2000, test it, and then bring it back into the production domain.

The Existing Domain Model

The type of domain structure, or model, that the existing Windows NT domains use will determine how you implement the Windows 2000 Active Directory trees and forest. Table 7-2 summarizes the types of domain models that may be in use.

Table 7-2. Domain models available in Windows NT

Domain Model	Description
Single-domain	A single Windows NT domain
Single-master	One account domain and multiple resource domains
Multiple-master	Multiple account domains with two-way trusts between them and multiple resource domains that trust all master domains
Complete trust	Every domain is a resource domain and an account domain, with each domain trusting every other domain

Existing Trust Relationships

Because the trust relationships will be preserved during the upgrade process, it's wise to check and document what trust relationships actually exist.

Location and Number of Domain Controllers

Determine where the PDCs and all BDCs are located. The PDC must be upgraded first. The BDCs can be upgraded after that and obviously cannot serve their intended function during the actual upgrade.

Account Domains and Resource Domains

Record the current number of account domains and resource domains. Also record how these domains are configured, and give some thought to whether you want to perform a domain restructure before or after you upgrade the network to Windows 2000.

DNS Namespaces

If the company has already deployed any DNS, you should carefully document the namespaces currently in use. Domains cannot be renamed once they've been created, and they must be unique on the network, so it's important to have domain names that aren't already in use in the organization.

Servers

A crucial and sometimes forgotten step in documenting a network is to make an inventory of the application servers. This includes all DNS, DHCP, and WINS servers, as well as application servers such as Exchange servers, SQL servers, proxy servers, and so on. DNS is a required service on a Windows 2000 native domain, so some thought should go into determining whether you want to use existing DNS servers for this purpose, deploy new DNS servers, or use the domain controllers as DNS servers, which is what Microsoft suggests.

Also examine any NetWare servers in the environment and determine whether you want to synchronize Active Directory with Novell Directory Services (NDS). You should also check the release notes included on the Windows 2000 Server CD-ROM for any compatibility issues with the version of NetWare. Chapter 20 discusses interoperating with NetWare.

Application servers such as Exchange, SQL, or media servers should also be evaluated for compatibility with the new Windows 2000 domains. Most servers will have no problems, but this is a good opportunity to double-check, as well as to reevaluate these servers' roles and their effectiveness on the network.

Windows NT 3.51 Servers

Windows NT 3.51 servers exhibit problems in a Windows 2000 domain that make them generally unsuitable for use, so your upgrade strategy must allow for upgrading or decommissioning servers running Windows NT 3.51. The problems include Windows NT 3.51 application servers either denying access to user or group logons, or incorrectly granting access to users or groups that have been denied access. These difficulties occur because of the way in which Windows NT 3.51 generates access tokens when a user logs on to the server.

MORE INFO
For more information on the specific problems that Windows NT 3.51 experiences in Windows 2000 domains, see the Microsoft Windows 2000 Professional Resource Kit (Microsoft Press, 1999).

Making a Recovery Plan

After taking stock of the existing network, devise a recovery plan in case something goes wrong during the domain upgrade. If the PDC fails the upgrade to Windows 2000 and you don't have BDCs available, the entire domain can be brought down. For these scenarios as well as others, it is important to have a satisfactory backup plan. This section contains some specific recommendations for ensuring that you're prepared for the worst—just in case.

Make Sure All Domains Have at Least One BDC

You need to be sure that all domains you plan to upgrade have at least one BDC in addition to the PDC to prevent the domain being orphaned if the PDC fails the Windows 2000 upgrade. Also, before you upgrade the PDC, make sure that you synchronize the PDC with all BDCs.

Back Up Each Computer Before Upgrading

It's just common sense to back up the systems before upgrading them. While this is perhaps overly cautious on some Windows NT desktop systems, it really is important on servers, especially domain controllers. Also, make sure that you test the backups; there's nothing more useless than a corrupt backup tape.

Synchronize All BDCs with the PDC

We've already said this, but it's worth repeating: synchronize the PDC with all of its replication partners before upgrading it. If the PDC fails the domain upgrade, you can promote a BDC to the PDC and the domain won't lose any changes.

Take a BDC Offline for Backup

Having freshly synchronized BDCs and new tape backups of the PDC will protect you from most disasters. However, it's good insurance to take a freshly synchronized BDC offline before upgrading the PDC. This provides you with a quickly available, working backup of the domain as it existed before you started the Windows 2000 upgrade process. If the upgraded PDC replicates bad domain information to the BDCs or the domain becomes damaged in some other way, having an offline backup allows you to go back and start over. If you track all changes to the domain after you take the BDC offline, you can even roll back the changes before bringing the BDC back online (if a disaster occurs) and not lose the domain changes.

To prepare a BDC to act as an offline domain backup, synchronize the BDC you want to use with the PDC for your domain, back up this BDC, and then disconnect the network cable to the BDC. If you encounter a major disaster after upgrading your PDC to Windows 2000 and you need to restore your domain to its pre–Windows 2000 state, demote any Windows 2000 domain controllers you have on your network, reconnect your offline BDC to the network, promote your formerly offline BDC to a PDC, and then synchronize it with the rest of your network. This will return your domain to the state it was in immediately before you took your BDC offline.

CAUTION
All changes to your domain performed after taking your backup BDC offline will be lost if you bring the BDC back online and promote it to a PDC.

Relax

Don't let all of these warnings put you off. If you take precautions and the upgrade goes faultlessly, you won't have to resort to restoring backups or using other recovery mechanisms. That's good news. Just remember that no one ever lost a job because of being too prepared.

Plan the Active Directory Tree

There are several steps you should take in planning the Active Directory tree, including defining the DNS namespace and creating the initial tree structure. This section briefly covers these steps. More detailed information on planning the namespace and the domain structure can be found in Chapter 3.

Define the Namespace

When deciding how to implement a DNS namespace, you usually need to decide whether to use an existing DNS namespace and create the root domain with an existing domain name or to create a new root domain and associated DNS namespace. The decision is crucial because the root domain can't be easily deleted or renamed; you're pretty much stuck with it. (You can change or delete the root domain if you really must, but it involves taking down the entire domain—not a whole lot of fun.) Domain names are also highly political in nature, so if you're fond of your job, don't create the domain structure and namespace without first getting the approval of the powers that be.

That said, the following list summarizes the tasks necessary to define and implement the namespace. (The specifics of some of these tasks are given in the sections that follow.)

Decide either that you can use an existing domain name for the root domain or that a new one is necessary.

If you are going to use a new domain name, determine what constraints you have in the name selection process and go through the proper channels to pick the domain name.

Set up the root domain to form the top level of the namespace, with a couple of domain controllers for redundancy.

Set up one or more DNS servers for the root domain tree. The DNS server needs to support the service resource record (the DNS resource record for specifying the location of services) and should ideally support dynamic updates as well. Microsoft recommends installing DNS on each domain controller and storing the zone data in Active Directory—not a bad idea.

Add the other domains as child domains under the root domain. This is an excellent time to perform a domain restructure or to at least consolidate some of the resource domains into OUs.

Create the Initial Tree Structure

Once you've decided on the DNS namespace, you're ready to plan the Active Directory tree in detail. For this chapter, we are going to assume that you have a single-tree forest, with all domains sharing a contiguous namespace. In practice, many companies will need to use a forest with multiple trees, each having its own namespace. However, the process is no different; each tree is constructed and then added to the forest in the same way.

PLANNING
The first domain that you upgrade to Windows 2000 (or create if you're using a multiple-master-domain model that doesn't lend itself to consolidation under one of the current domains) needs to be the root domain. The root domain stores the configuration and schema for the entire Active Directory forest and cannot be renamed or deleted.

Adapt to Specific Domain Models

Four domain models are available in Windows NT.

Single-Domain Model The single-domain model is easy to upgrade: the single domain under Windows NT becomes the root domain in Active Directory under Windows 2000. You can then use OUs to organize the accounts and resources and to delegate some of the administrative burden.

Single-Master-Domain Model If you have a single-master-domain model, make the former master domain the root of the tree and add the resource domains as child domains of the root. If the company has a centralized network structure, you might want to consider restructuring the domains into a single domain after you've upgraded the domain and switched to native mode. You can use OUs either to mimic the resource domains or to organize them more logically, with the accounts and resources grouped and organized according to the company's structure.

Merging the resource domains back into a single domain offers a number of advantages. Because there are fewer domains to manage, the administrative burden is less. You can use OUs to create a detailed network structure without the necessity of dealing with trusts (although switching to native mode will eliminate most of the hassle of managing trust relationships). In addition, you can delegate administrative authority to the OUs, giving you the flexibility to handle the administrative tasks the way you want. Active Directory queries are also performed faster and more efficiently in a single domain. Finally, since OUs don't require domain controllers, there is the potential to free up some underused computing resources for other tasks. Figure 7-1 shows a single-master Windows NT domain converted to a Windows 2000 Active Directory tree.

click to view at full size.

Figure 7-1. A single-master Windows NT domain converted to a Windows 2000 Active Directory tree, with a resource domain converted to an OU after switching to native mode.

A company with a more decentralized organization, or one with different business units, may want to stick with multiple domains but convert its resource domains into full-fledged domains, with both resources and user accounts. (With Active Directory, there is no reason to keep distinct resource domains.) This arrangement allows users to be in the same domain as the resources that they use, reducing traffic and making it easier for users to find and access the resources they need. You should wait, however, until the network has been converted to Windows 2000 native mode before moving the accounts because transitive trusts make moving accounts between domains much easier, and this type of trust is available only in a native-mode domain. Alternately, you can establish a two-way trust between the resource domains and the parent domain, but it usually makes more sense to wait until all domains are running in native mode.

TIP
Third-party solutions can provide much of this organizational flexibility in Windows NT 4, with the intent of permitting companies to restructure their domains in a way that works well with Active Directory before they move to Windows 2000. For example, Fastlane Technologies sells a product called DM Manager, which allows companies to upgrade Windows NT 4 domains into a multimaster structure that is very similar to that provided by Active Directory. Using this product allows a company to restructure its domains into a hierarchical domain structure that can be very easily upgraded to a Windows 2000 Active Directory-based network once the company is ready, while benefiting from many of Active Directory's features in the meantime.

Multiple-Master-Domain Model Because of the flexibility and advantages the single-domain model has to offer, many companies with a multiple-master-domain model choose to consolidate their domains into a single Windows 2000 domain, using OUs to hierarchically structure their network. If you choose to consolidate the domains, you should first perform the domain upgrade just as if you were going to preserve the existing domain structure, and then perform the domain consolidation only after upgrading the network to native mode. After the domains are in native mode, all accounts can be moved into the single domain without the need to reassign permissions on the objects.

If you want to create a single-domain tree (with a contiguous namespace) during the domain upgrade, you can use one of the existing domains for the root of the tree, or you can create a new root domain and add the other master domains as its children, as shown in Figure 7-2. You may want to consider using a structural domain for this root domain. (See the Real World note "Using Structural Domains," in section "Planning the Site Topology.") Upgrade or create the root domain first. Once this domain is up and running with a couple of domain controllers, upgrade the rest of the domains and add them to the tree.

click to view at full size.

Figure 7-2. A multiple-master Windows NT domain converted to a Windows 2000 Active Directory tree, with two resource domains converted to OUs after switching to native mode.

If you want to keep each master domain in an authoritative role, you can create a multiple-tree forest, with each master domain seeded as the root for a new tree in the forest. In this case, it doesn't matter which master domain you upgrade first, but you must upgrade the master domain for each tree before you upgrade the resource domains you plan to add to the tree.

REAL WORLD Multiple-Master Domains and the Case for Domain Consolidation
The Windows NT multiple-master-domain model is widely used in larger organizations for a couple of reasons. First, it allows the network to grow beyond the limitations of the single Security Accounts Manager (SAM) that single domains and single-master domains use. The SAM in Windows NT is stored in the system registry, and once it grows past 40 MB, performance degradation becomes noticeable. This means that the practical limit for a domain is 40,000 objects, with a maximum of 20,000 user accounts. To have more user accounts or objects than this, Microsoft recommends moving to a multiple-master-domain model.
The second reason that companies use multiple-master domains under Windows NT is to allow for physically different network sites that don't possess wide area network (WAN) connections that are fast and reliable enough to allow domain controller replication to take place without consuming an inappropriate amount of the WAN bandwidth. Using a master domain in each site gets around this lack of adequate connectivity, since no replication takes place between master account domains and all of the WAN bandwidth is available for other uses.

The third reason to use a multiple-master Windows NT domain structure is to reflect the company's organization in cases where different parts of the company need to control their own resources and users. Each master account domain can have its own administrator or the administration can be centralized, depending on the desires of the company.

Windows 2000 Active Directory deals with these issues effectively, permitting many companies to move to a single-domain model (or at least to reduce the number of domains) and gain the advantages that that model has to offer. Active Directory stores all domain information in its database (which is external to the registry and free to grow in size), with each domain storing its part of the entire directory instead of one server storing the entire network schema, allowing you to scale the domain to approximately a million objects. No other domain is necessary; all organization can be done with OUs. You can also create multiple physical sites, with a single domain spanning all sites and intersite replication set up to make the best use of slow WAN links.

Complete Trust Model The Windows NT complete trust model is used most often by very decentralized companies or by companies that implemented domains in a piecemeal fashion and gradually connected the domains. The model provides a lot of autonomy and flexibility for each master domain, but it also entails a large administrative burden.

As with the multiple-master-domain model, many companies, when upgrading a domain that uses the complete trust model to Windows 2000, will try to consolidate their domains into a single tree or even a single domain. However, if you want to maintain the autonomy of the current domain structure of the complete trust model, you can set up each current master domain as a new tree or (if necessary) as a new forest. When you create the Active Directory structure like this, you automatically reduce the amount of administration necessary, as all trusts between domains in an Active Directory tree or forest are automatically transitive.

NOTE
Transitive trusts do not take effect until the domains are converted to Windows 2000 native mode.

When you upgrade the domain, create the root domain first, either by creating a new domain (structural or normal) or by upgrading an existing domain and seeding it as the root of the Active Directory tree. Once you have the root up and running with a couple of domain controllers, you can move on to upgrading the other domains and adding them as children of the root domain or as roots in new trees or forests. If necessary, after upgrading all domains and switching to native-mode operation, you can replace any transitive trusts with Windows NT-style one-way trusts to limit access within a forest or to provide external domains access to specific domains in the tree or forest.

TIP
A one-way trust can also be set up to permit a legacy Windows NT 4/3.51 domain or a child domain of another forest (such as one belonging to a business partner) to access a specific domain in the tree or forest. When you set up an explicit one-way trust in Windows 2000, it works identically to trusts in Windows NT—that is, the trust is not transitive. If you grant a domain access to a single domain in the tree or forest, the trusted domain cannot access any other domain in the tree, even though the tree is linked with transitive trusts.

Planning the Site Topology

Sites, an important new feature in Windows 2000, define the boundaries of LAN connectivity, making WAN links more efficient. When you set up sites that mark the sections of the network that have high-speed connectivity, Active Directory tunes the way it uses the WAN links by reducing the frequency of replication between sites and by directing clients' service requests (such as client logons or directory searches) to domain controllers that are available locally.

Sites are independent of domains. While domains typically mirror a company's logical organizational structure, sites mirror the physical network structure of a company. A single site may consist of one or more domains, trees, or even forests, and a single domain may span multiple sites. A site may consist of a single IP subnet (often the case because subnets frequently mark physical network boundaries) or multiple IP subnets, but all subnets must share reliable, high-speed connectivity in order to be a part of a single site.

TIP
In these days of asynchronous transfer mode (ATM) WAN links, it is becoming increasingly common for a company's WAN link to be as fast (or sometimes faster) than an internal LAN. However, the WAN link charge might be based on usage, or a company might use the link heavily for real-time, bandwidth-intensive tasks such as video, reducing the available bandwidth. In such cases, you may still want to set up a site structure for the Active Directory forest, to avoid burdening the WAN link with excessive replication and service requests.

When planning to upgrade a Windows NT domain to Windows 2000, it is important to plan the site topology so that you can set up the site structure promptly after upgrading. Ask yourself the following questions and make a record of your answers:

What sites will you need to create in the Active Directory forest?

What links are available between these sites, and how fast and expensive are they? Are they already heavily utilized, or is an abundance of bandwidth available?

Are there any planned links between the sites?

Are there any domains that will span physical sites, and if so, are the links between the sites fast enough to support this?

Two types of connections are available for intersite replication: point-to-point synchronous low-speed RPC and Simple Mail Transfer Protocol (SMTP). Any domains that span multiple sites must have at least a point-to-point synchronous low-speed RPC connection between the sites within the domain. This connection is required because you can't use SMTP for intersite replication between domain controllers in the same domain; you can use SMTP links only for schema, configuration, and Global Catalog information replication. Therefore, if you have multisite domains, double-check the link between the sites to make sure that you have adequate connectivity for this setup.

REAL WORLD Using Structural Domains
Companies that use the multiple-master-domain or complete trust model under Windows NT will usually choose an existing domain to use as the root for their Active Directory tree. However, some organizations may choose to use a structural domain as the root of their tree, with the former master domains as child domains.
A structural domain is simply a domain without user accounts or resources—it exists purely to form the structure of the domain (hence the name) as well as to aid in easy and efficient interdomain replication. Structural domains can be used to provide a domain structure that is well suited to further restructuring in the future. By placing one or more levels of structural domains in the Active Directory tree, you provide an unchanging anchor in the domain tree, under which you can move child domains without altering the higher-level domain structure. At the same time, the structural root domain acts as a shield to the world so that changes in complexity are hidden behind it.

Structural domains are also useful for replication between sites, especially when accessing or replicating the Global Catalog (GC), which is the master catalog for all objects in the host domain's portion of Active Directory and a partial catalog of objects stored in other domains. If you have more than one site, you may choose to create a structural domain at the root that spans all sites and maintains a copy of the GC at each site. (You could also store a copy of the GC in the top-level local domain at each site and just use the structural domain as a link between the sites.) Having an onsite GC permits the local domains at all sites to concentrate on intrasite data processing and replication, with all intersite replication performed by the structural domain.

Using structural domains for replication also makes setting up and maintaining replication links easier. Child domains simply replicate upward to the parent domain, obviating the need to know the name of each domain you need to replicate with.

MORE INFO
For more information on structural domains, see Microsoft Windows 2000 Distributed Systems Guide (Microsoft Press, 1999).

Developing an Upgrade Strategy

After documenting the existing network infrastructure, making a recovery plan, and designing the Active Directory trees and sites, you're ready to put it all together and create an actual upgrade plan. This section presents some general guidelines that apply to all domain upgrades, as well as some tips for specific domain models.

Make Sure the PDC Is Sufficiently Powerful

Start the domain upgrade by carefully examining the current PDC. Although Windows 2000 uses peer-based, multiple-master domain controllers, the first domain controller retains extra services that in some cases cannot easily be moved to other domain controllers. These services include the Global Catalog server, the Operations Master, and the PDC emulator. (The PDC emulator provides services for Windows NT and Windows 95/98 clients and also performs some tasks in a pure Windows 2000 environment.) In other words, all domain controllers are equal, but the first Windows 2000 domain controller is a little more equal than the others, so you want that machine to be especially fast and powerful.

Create the New Root Domain Before Upgrading the PDC

If you're moving from a multiple-master-domain or complete trust model and want to create a new domain to serve as the root of the domain tree, you need to do this before you upgrade the PDC. By the way, creating this new root domain, whether it's a structural domain or not, involves a brand new system (or at least a clean install) with Windows 2000. Once you have created the new domain and have it running with a couple of domain controllers (as well as any new systems or clean installs), you can upgrade the PDC and join it to this new tree as a child domain.

Upgrade the PDC First

The first server to be upgraded must be the Windows NT PDC in the account domain you want to use as the root of the new Active Directory tree. This is true whether the tree you're creating is the first in the forest or the twentieth in the third forest—you always need to upgrade the PDC first if you want to upgrade the Windows NT domain instead of creating a new domain.

Upgrade the BDCs Right Away

Upgrade all BDCs in the domain as soon as possible after starting the upgrade process. This step will allow you to switch the domain to Windows 2000 native mode and gain the administrative benefits of native mode sooner.

TIP
When you upgrade a BDC to Windows 2000, it will replicate with the first domain controller it can reach. If the former PDC, now Windows 2000, domain controller isn't available, the BDC will try to configure itself as the first Windows 2000 controller in the domain, creating serious problems when the first domain controller comes back online. Make sure that the first Windows 2000 domain controller is visible on the network when upgrading a BDC.

Upgrade Member Servers and Clients Independently

Upgrade member servers and workstations whenever you want—either before or after you upgrade the domain to Windows 2000. Windows 2000 clients and member servers work perfectly well with Windows NT domains; however, the benefits of Active Directory aren't available to them until the domain is upgraded.

Schedule the Domain Upgrade Appropriately

Schedule the domain upgrade at a time that will have the lowest impact on the user population. Although it's probably a forlorn hope, it's best to avoid upgrades during major projects and at the busiest times of year. Even perfect upgrades produce some impact on the users, especially if you perform any domain restructuring or consolidation.