Windows NT domains are single-master based, with the PDC serving as the master repository for a given domain. The PDC must carry out all changes to the domain. BDCs serve as working backups to the PDC and reduce the load on the PDC by serving client requests themselves. BDCs maintain a current copy of the domain by synchronizing periodically with the PDC; you can upgrade a BDC to the PDC if the PDC server fails or is taken out of service.

Member servers are simply Windows NT servers that belong to a Windows NT domain and are not domain controllers. Member servers usually perform file sharing or print sharing or run some other type of server software, such as Web, Domain Name System (DNS), or Dynamic Host Configuration Protocol (DHCP) server software. You can’t upgrade a Windows NT 4.0 member server to a PDC or BDC without a clean reinstallation of Windows NT, and you can’t demote a PDC or BDC to a member server without reinstalling Windows NT.

Standalone servers are Windows NT servers that do not belong to a Windows NT domain and are instead part of a workgroup. It is important to understand that although a standalone server doesn’t belong to a Windows NT domain, it isn’t limited in its duties as a server. It can still act as a DNS, DHCP, or other type of server, but it can’t act as a central repository for user and group data like a PDC or BDC can. To upgrade a standalone server to a PDC or BDC, you must reinstall Windows NT.

The member server and standalone server roles are unchanged for the Windows 2000 Server and Windows Server 2003 families, but Windows 2000 and Windows Server 2003 replace the PDC and BDC roles with a single domain controller role. Domains in Windows 2000 are finally multiple-master based, with all Windows 2000 or Windows Server 2003 domain controllers acting as peers to one another. Any domain controller can make changes to the domain at will. All domain information is stored in Active Directory, which the File Replication Service (FRS) replicates between all domain controllers. The tradeoff is that Windows 2000 and Windows Server 2003 domain controllers cannot exist on a Windows NT domain until you upgrade the PDC of the domain to Windows 2000 or Windows Server 2003. For more information, see the Planning a Windows NT Domain Upgrade section of this chapter.

You can promote Windows 2000 and Windows Server 2003 member servers and standalone servers to domain controller status, and you can demote domain controllers to member servers or standalone servers without reinstalling the operating system—the only way to demote a BDC under Windows NT. However, as always, it’s preferable not to make more role changes than necessary.

Although Active Directory doesn’t make fundamental changes to the way domains work for end users, it does introduce some important domain structures that affect the way you approach domain design. Active Directory, like the directory service in Windows NT, uses domains as the core unit of logical structure. Domains help organize the network structure to match the organization of the company. Each domain requires at least one domain controller (and preferably more) to store the domain information, and each domain controller can make changes to the domain. See Chapter 3 for more about domain planning.

Active Directory domains use DNS names for domain names instead of the Network Basic Input/Output System (NetBIOS) naming structure of Windows NT domains (although Windows 2000 Server and Windows Server 2003 generate NetBIOS names for backward compatibility). Active Directory domains are hierarchically organized—as required by DNS. Active Directory refers to hierarchically organized groups of domains with a contiguous namespace trees, and groupings of trees with noncontiguous namespaces are known as forests. For example, example.local and all subdomains (support.example.local, finance.example.local, and so forth) belong to a single tree; while a different division of the company (example.com, for example) has its own tree in the forest. Because the companies share their networks and administer them together, they belong to the same forest; the suppliers and partners of the companies would have their own forests. You can establish trust relationships between the forests as necessary to allow them to do business with one another more easily.

Active Directory domains are nearly identical between Windows Server 2003 and Windows 2000 Server; however, upgrading the functional level of a forest and relevant domains to one of the Windows Server 2003 functional levels provides enhanced Active Directory management capabilities, including the ability to rename and move domains within or between forests. For more information, see the Switching Forest and Domain Functional Levels section of this chapter.

Active Directory also introduces the concepts of sites and organizational units (OUs). A site is a group of one or more Internet Protocol (IP) subnets that share local area network (LAN) connectivity. Within a site there can be one or more domains, or a single domain can span multiple sites. See the Planning the Site Topology section later in this chapter for further information.

Organizational units (OUs) are similar to domains in that they are containers for network objects such as user accounts and resources. Unlike domains, however, they do not mark a security boundary, and creating OUs doesn’t require adding domain controllers (because OUs exist within a domain and thus make use of the existing domain controller infrastructure). OUs in Active Directory provide an excellent way to provide organization within a domain without the need for additional security policies and domain controllers. You can easily convert OUs to domains, and domains to OUs, which makes them very flexible. See Chapter 9 for more information about the uses and creation of OUs.

The first domain you create in Active Directory automatically becomes the forest root domain—the top-level domain in the Active Directory hierarchy. If you create additional domain trees (with their own contiguous namespaces), Active Directory creates transitive two-way trusts between the trees and the forest root domain, as if the trees were child domains. Indeed, from a trust and replication perspective, it appears that the subsequent trees are children of the forest root, even though they use completely different namespaces.

Besides its significance as the hub of replication between trees, the forest root domain also contains the Enterprise Admins and Schema Admins groups, which have forest-wide administrative scope.

Because the forest root domain is so important, fault-tolerance and recoverability is critical. If a regional catastrophe wiped out all domain controllers and backups in the forest root domain, the Enterprise Admins and Schema Admins groups would be forever lost, and you would have to re-create the entire forest.

To help reduce the need to alter the forest root domain, you can create a dedicated forest root domain exclusively for forest-level administration and replication, and place the majority of accounts and resources in child domains. Because there are few user accounts and resources in a dedicated forest root domain, Active Directory structures that consist of a dedicated forest root and a single child domain are often said to be using the Single Global Domain Model. Active Directory structures that consist of a dedicated forest root with multiple child domains are referred to as using the Regional Domain Model—a nod to the fact that the child domains are often organized geographically.

Trust relationships are an important component of large networks that consist of multiple domains. Simply stated, a trust relationship is a policy that enables users from one domain to access resources in another domain.

For example, say that a user, Susan, in the domain Administration, wants to access a resource in the domain Manufacturing, and that the Manufacturing domain trusts the Administration domain. When Susan attempts to access the resource, the resource must verify that she has an account that has permission to access it. To authenticate Susan, the resource in the Manufacturing domain contacts its local domain controller (DC, BDC, or PDC), which in turn queries a domain controller in the Administration domain and verifies that Susan has a valid account and that the account belongs to a group permitted to access the resource.

Trust Relationships in Windows NT 4.0

Among and between Windows NT 4.0 and earlier domains, all trusts are nontransitive, meaning that each trust is a one-way relationship between two domains that you must explicitly create. For two domains to trust each other, you must create two separate trust relationships—one for each direction.

A nontransitive trust is also strictly limited. For example, suppose that the domain Finance also trusts the domain Administration (as shown in Figure 6-1). When nontransitive trusts are involved, this statement tells you only that the Finance and Manufacturing domains both allow users from the Administration group access to their domains. It does not tell you anything about the relationship between the Finance and Manufacturing domains, nor does it indicate whether Administration, in turn, allows either Finance or Manufacturing to authenticate users. You must create each trust relationship separately and explicitly.

Figure 6-1. Three domains under Windows NT 4.0 and under Windows 2000

Trust Relationships in Active Directory

Active Directory introduces transitive trusts. Transitive trusts are always two-way, and they support pass-through authentication. Creating a trust between the Administration and Manufacturing domains (now probably called administration.example.local and manufacturing.example.local) automatically means that users in each domain can be authenticated and be eligible to access resources in the other domain (though they still need to have proper permissions, of course).

Pass-through authentication comes into play with child domains. With Active Directory domains, users in the child domain can use the parent domain’s trusts by means of the automatic two-way transitive trust that Active Directory creates between the child domain and the parent domain. For example, let’s say you create a widgets.manufacturing.example.local child domain. Users in this domain are automatically eligible to access resources in the manufacturing.example.local domain (the parent domain) as well as the example.local domain (the parent domain of the parent domain—the grandparent domain, if you will).

Transitive trusts become available after you upgrade a domain to Active Directory. Despite some confusion over the matter, they do operate in domains that use the Windows 2000 mixed functional level and work between trees in a forest, but they do not apply to remaining Windows NT domains in your company or to clients connected to Windows NT BDCs. (These domains and clients rely on existing one-way nontransitive trusts.) Explicit one-way trusts are also available between Active Directory–based domains, but you must create them manually.

Windows Server 2003 provides additional capability to set up one-way or two-way transitive trusts between forests, and the ability to rename and move domains within and between forests after you upgrade the forests to the Windows Server 2003 forest functional level.

Real World: Whom Do You Trust?

The question of transitive trusts arises in large multidomained enterprises. Active Directory domain controllers automatically use transitive trusts when communicating with other Active Directory domain controllers, even in domains that use the Windows 2000 mixed functional level. The existing trusts remain in place for use by Windows NT BDCs until you switch the domain to the Windows 2000 native or Windows Server 2003 functional level. Trusts that you add to or take from Windows NT domains are the nontransitive trusts that you explicitly and deliberately set. This means that if you are creating a new Active Directory domain, you must manually create trusts with existing Windows NT domains.

Table 6-1 shows the possible trust relationships between different types of domains.

Table 6-1. Trust relationships between domains of different types

	Windows NT Domain	Active Directory Domain (Same Forest)	Active Directory Domain (Different Forest)
Windows NT Domain	One-way trust[a]	One-way trust[a]	One-way trust[a]
Active Directory Domain (Windows 2000)	One-way trust[a]	Two-way transitive trust (One-way trust available)	One-way trust[a]
Active Directory Domain (Windows Server 2003 forest functional level)	One-way trust[a]	Two-way transitive trust (One-way trust available)	Two-way transitive forest trust (One-way trust available)
[a] You can establish one-way trusts in both directions, simulating a two-way trust.

The type of domain structure, or model, that the existing Windows NT domains use determines how you implement Active Directory trees and forests. Table 6-2 summarizes the types of domain models that might be in use.

Document existing trust relationships, and determine whether all trusts are still necessary. Windows preserves existing trust relationships during an upgrade to maintain compatibility with Windows NT 4.0 BDCs. However, Windows doesn’t import trusts with Windows NT 4.0 domains into Active Directory. Re-create these trusts in Active Directory before upgrading or taking the last BDC in the domain offline.

If you upgrade any domains into separate forests and want to maintain trust relationships between the forests, delete the existing trusts (which use NetBIOS domain names) after upgrading the PDC and re-create them using fully qualified DNS domain names. See Chapter 14 for information about working with trusts in Active Directory

Record the current number of account domains and resource domains. Also think about whether you want to restructure your domains, either before or after you upgrade the network to Active Directory.

If the company has already deployed DNS, carefully document the namespaces currently in use. You cannot easily rename domains after you create them, and they must be unique on the network.

A crucial and sometimes forgotten step in documenting a network is to make an inventory of the servers. Record the server names, hardware capabilities, locations, operating system version, and service pack levels of the following types of servers, and evaluate any compatibility issues or problems with the servers before you begin the upgrade process:

When designing the Active Directory structure for an existing Windows NT–based network, take into consideration the current Windows NT domain model: single domain, single-master domain, multiple-master domain, or complete trust. (See Table 6-2 for a summary.) This section guides you through designing an Active Directory domain structure appropriate for your existing network model.

Single-Master–Domain Model

The Windows NT single-master–domain model consists of one master domain that contains all user accounts, and one or more resource domains that trust the master domain and contain only computer accounts and other resources.

If you have a single-master–domain model, create a dedicated forest root domain (discussed in the Real World sidebar Using Dedicated Forest Root), and make the former master domain the first child domain. Then add the resource domains as second-level child domains.

If the company has a centralized network structure, after upgrading the domains to Active Directory and switching the master domain to Windows 2000 or Windows Server 2003 native mode, consider restructuring the domains into a single child domain. 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.

Note

If you want to restructure or consolidate your domains, do so before using Group Policy.

Merging the resource domains back into a single child domain under the dedicated forest root 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 dealing with trusts. In addition, you can delegate administrative authority to the OUs, giving you the flexibility to handle the administrative tasks the way you want. You can also perform Active Directory queries faster and more efficiently in a single domain. Finally, because OUs don’t require domain controllers, there is the potential to free up some underused computing resources for other tasks. Figure 6-2 shows a single-master Windows NT domain converted to an Active Directory tree using a dedicated forest root domain, with a resource domain converted to an OU after switching the account domain to Windows 2000 or Windows Server 2003 native mode.

Figure 6-2. A single-master Windows NT domain converted to an Active Directory

A company with a more decentralized organization, or one with different business units, might want to keep 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 they use, reducing traffic and making it easier for users to find and access the resources they need. However, you must wait until you upgrade all relevant domains and switch the target domain to Windows 2000 or Windows Server 2003 native mode before you can move the accounts. This is because an object that is moved between domains loses its ability to access resources to which it formerly had access, unless the native mode SIDHistory feature can provide the resources with the object’s old security identifier (SID).

Note

Third-party solutions can provide much of this organizational flexibility in Windows NT 4.0, with the intent of permitting companies to restructure their domains in a way that works well with Active Directory before they upgrade.

Real World: Using Dedicated Forest Root

Creating a dedicated forest root domain that consists solely of users and resources involved in forest-wide administration has a number of advantages over a forest root domain that does double-duty as a normal production domain. Advantages include the following:

• The Domain Admins group exists to delegate administration of a domain; however, in the forest root domain this group can exert forest-wide control, which might not be a good thing. In a dedicated forest root domain, this isn’t a problem because the forest administrators (Enterprise Admins) also handle the domain administration tasks (normally performed by separate Domain Admins). Domain Admins in child domains do not have forest-wide control.

• A dedicated forest root domain provides a permanent, unchanging root for the Active Directory forest, facilitating future reorganization.

• Because a dedicated forest root domain contains an extremely small number of users and resources, it’s easily replicated and backed up. (Remember, if all domain controllers in the forest root domain are permanently lost, so are the Enterprise Admins and Schema Admins groups.)

• You can transfer the ownership of the forest root without affecting data and users in a production environment—they remain safely in one or more child domains.

As you can see, there are some good reasons Microsoft recommends using a dedicated forest root domain. However, smaller networks should weigh these options against the additional resources required by the domain—the forest root domain is vital to Active Directory, and therefore is not a domain to neglect.

Multiple-Master–Domain Model

The multiple-master–domain model in Windows NT consists of a network with two or more master domains that contain all the user accounts, and multiple resource domains that trust each master domain and contain all the computer accounts and other resources. Large networks use this model to circumvent the Windows NT limit of 40,000 objects per domain.

Because of the flexibility and simplicity the Active Directory single-domain or single global domain models offer, many companies with a multiple-master–domain model choose to consolidate their domains into a single Active Directory domain (with or without a dedicated forest root domain) and use OUs to hierarchically structure their network. If you choose to consolidate the domains, create the forest root domain first (if applicable) and then perform the domain upgrades just as if you were going to preserve the existing domain structure. After you upgrade the domains and switch the target domain to a native-mode functional level, you can move all accounts into the single domain without the need to reassign permissions on the objects.

Note

If you want to restructure or consolidate your domains, do so before using Group Policy.

To create a single-domain tree (with a contiguous namespace) during the domain upgrade, create a dedicated forest root domain and stabilize it with a couple of domain controllers. (See the Real World sidebar Using Dedicated Forest Root, in the previous section.) Then upgrade the master domains one by one, adding them to the Active Directory tree as children of the forest root, which also serves as the tree root domain in this example. Figure 6-3 shows a multiple-master Windows NT domain converted to an Active Directory tree, with two resource domains converted to OUs after switching the account domains to native mode. After you upgrade the account domains, upgrade the resource domains and add them to the tree as children of the account domains (grandchildren of the forest root). Once the upgrade is complete, switch the account domains to a Windows 2000 or Windows Server 2003 native mode, and consider consolidating the resource domains into the account domains, using OUs when applicable.

Figure 6-3. A multiple-master Windows NT domain converted to an Active Directory tree

If you want to keep each master domain in an authoritative role, create a multiple-tree forest. First, create a dedicated forest root domain to serve as the root for the forest. Dedicate this domain exclusively to forest administration; do not create your users or resources in this domain. Then seed each master domain as the root for a new tree in the forest. (This is called the tree root domain.) In this case, it doesn’t matter which master domain you upgrade first, but you must upgrade the master domain for each tree before upgrading the resource domains.

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 several 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 after it grows past 40 MB, performance degradation is noticeable. This means that the practical limit for a domain is 40,000 objects, with a maximum of 20,000 user accounts. To create more user accounts or objects than this in Windows NT 4.0, you must use a multiple-master–domain model.

The second reason that companies use a multiple-master–domain model in 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 because no replication takes place between master account domains and all 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 you can use an administrator account in the dedicated forest root domain that belongs to the Enterprise Admins group, depending on the desires of the company.

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 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), and each domain stores only its part of the directory instead of one server storing the entire network schema. This enables you to scale the domain to millions of objects. No other domain is necessary; you can perform all organization 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. For help with consolidating domains, see the Solution Accelerator for Domain Server Consolidation and Migration: Windows NT 4.0 to Windows Server 2003, a set of documentation that provides prescriptive, tested, and supported help on planning, designing, deploying, and verifying a domain migration project. You can obtain this tool from the Microsoft Download Center at http://www.microsoft.com/downloads.

Using Structural Domains Elsewhere in an Active Directory Tree

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. The dedicated forest root domain is a type of structural domain (albeit one with the additional role of forest-wide administration, which does entail some user accounts and resources).

You can use structural domains elsewhere in the forest to create a domain hierarchy that is well suited to further restructuring. For example, by using a structural domain as a tree root domain (in addition to the forest root domain), you provide an unchanging anchor in the domain tree, under which you can move child domains without altering the higher-level domain structure.

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 might choose to create a structural domain at the root that spans all sites and maintains a copy of the GC at each site. (You can 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 on-site 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.

As you can see, using structural domains has a number of advantages; however, you must balance these advantages with the increased complexity and resources required for additional domains. A simple Active Directory structure makes administration and reorganization easier, and it permits the more efficient placement of domain controllers.

After conceiving an Active Directory structure, it’s time to name the baby. If you haven’t read Chapter 3 yet, you might want to refer to it for namespace planning information. After you settle on a naming convention and decide whether to use separate internal and external domain names, it’s time to choose the DNS names for the forest root domain and any additional trees. To do so, use the following steps as a guide—just remember that domain names are 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 authorities in your organization.

Sites, an important new feature of Active Directory, 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 symmetrical connectivity (10 Mbps is a good number to use), Active Directory tunes the way it uses the WAN links. It reduces the frequency of replication between sites and directs clients’ service requests, such as client logon events or directory searches, to domain controllers that are available locally.

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

When planning to upgrade a Windows NT domain to Active Directory, 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 record your answers:

Two types of connections are available for intersite replication: point-to-point synchronous low-speed remote procedure call (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 (GC) information replication. Therefore, if you have multisite domains, double-check the link between the sites to make sure you have adequate connectivity for this setup.

You would be wise to have a global catalog server on each site to allow a local domain controller to service requests for any resource in the forest without having to use the WAN link. However, the global catalog server shouldn’t be the same server as the infrastructure master unless there are no other domain controllers in the domain, because this configuration breaks the infrastructure master’s ability to update other domain controllers in the domain. (See Chapter 15 for information about the infrastructure master role.)

Place at least one DNS server in each site, and have a minimum of two domain controllers per site for redundancy. (This isn’t as important for remote sites with a small number of clients.)

Be sure all domains you plan to upgrade have at least one BDC in addition to the PDC. This prevents the domain from being orphaned (or lost entirely) if the PDC fails the upgrade. Having a working and recently synchronized BDC allows the network to function (almost) normally while you upgrade the PDC. (Some programs or services such as WINS don’t like it when the PDC is gone.)

Back up each system before upgrading it. This is perhaps overly cautious on some desktop systems that do not store any data locally, but it’s important on servers, especially domain controllers. Also, make sure you test the backups by restoring randomly selected data from the backup, or even performing a full restoration into a Microsoft Virtual Server environment. (See Chapter 29 for information about Microsoft Virtual Server.)

Synchronize the PDC with all 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.

Freshly synchronized BDCs and new tape backups of the PDC 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 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 to a healthy copy of the domain.

To prepare a BDC to act as an offline domain backup, synchronize the BDC with the PDC domain, back up the BDC, and then disconnect the network cable to the BDC. If a major disaster occurs after upgrading the PDC and it is necessary to restore the domain to its pre–Active Directory state, use the following steps:

Don’t let all these warnings dissuade you from performing an upgrade. If you take precautions and the upgrade goes faultlessly, you won’t have to resort to restoring backups or using other recovery mechanisms. However, if you do encounter problems, you will be prepared.

As mentioned earlier in this chapter, Windows NT 4.0 RAS servers don’t play well with Active Directory networks. Because of this, upgrade or replace any Windows NT 4.0 RAS servers with Windows Server 2003 or Windows 2000 member servers running Routing and Remote Access (RRAS) before upgrading the PDC and starting the domain upgrade. If this isn’t feasible, put all Windows NT 4.0 RAS servers near the top of the list of servers to upgrade after you upgrade the PDC and a few BDCs.

Start the domain upgrade by carefully examining the current PDC. Although Active Directory uses peer-based, multiple-master domain controllers, the first domain controller retains extra services that in some cases you cannot easily move 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, Windows 95, Windows 98, and Windows Me clients, and also performs some tasks in a pure Windows 2000, Windows XP, and Windows Server 2003 environment.)

Because of these additional roles the upgrade PDC must perform, the first PDC should be especially fast, powerful, and reliable. The best way to ensure that the PDC is fast enough is to buy a powerful new server and install Windows NT 4.0 Server on it as a BDC with Service Pack 6a and the latest hot fixes. Promote the server to your PDC, let it sit for a little while, and then take it offline and perform the upgrade to Windows Server 2003. This ensures that your first domain controller is on the most powerful and up-to-date hardware you have available, and it provides the closest-to-clean install experience possible from an upgrade.

If you want to create a dedicated forest root domain, you need to do this before you upgrade the PDC. After you have the new domain up and running with a couple of domain controllers, you can upgrade the PDC and join it to this new tree as a child domain.

If you have any Windows NT 4.0 RAS servers or computers running Windows NT 3.51 or earlier, upgrade or retire these systems as discussed earlier in this chapter.

Disable the LAN Manager Replication Service on all Windows NT 4.0 servers because it’s incompatible with Active Directory networks. The file replication service (FRS) feature of Windows 2000 and Windows Server 2003 domain controllers replaces it. (Note that the new DFS Replication service of Windows Server 2003 R2 does not replace FRS for domain controller replication.)

The first server you upgrade 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—upgrade the PDC first if you want to upgrade the Windows NT domain instead of creating a new domain.

It’s important to get another Windows Server 2003 or Windows 2000 domain controller online quickly after you upgrade the PDC. If the sole Windows Server 2003 domain controller goes down, you’ll have to promote a BDC to PDC and start over again (though most changes will survive, except any changes incapable of being stored on a Windows NT BDC).

Another reason that it’s important to quickly add additional domain controllers is because computers running Windows 2000, Windows XP, or Windows Server 2003 authenticate preferentially with Windows Server 2003 and Windows 2000 domain controllers. If there are too few Windows Server 2003 or Windows 2000 domain controllers available, clients might not be able to authenticate during busy times. (Most clients can log on using cached credentials, but you should nonetheless add domain controllers quickly.) If you can’t add additional Windows Server 2003 or Windows 2000 domain controllers in a prompt manner, configure the Windows Server 2003 domain controllers to appear to all clients as Windows NT 4.0 domain controllers. To do so, refer to the Windows Server 2003 Resource Kit or Knowledge Base Article 298713.

Because the master copy of the domain information is stored in Active Directory after you upgrade the PDC, you don’t need to upgrade BDCs. Instead, you can replace them with new Windows Server 2003 or Windows 2000 domain controllers, or perform clean installations on BDCs and then install Active Directory when finished.

If you do choose to upgrade BDCs, do so one at a time, and pause before upgrading or retiring the last BDC. Verify that you’ve dealt with all incompatible clients and servers, re-create in Active Directory any trusts in that are established with Windows NT 4.0 domains, and to be extra safe, take the last BDC offline for a week or more before upgrading or retiring it. If nothing erupts in flames, go ahead with your plan.

Real World: Upgrading BDCs on Remote Sites Using Backup Media

To reduce the amount of replication traffic generated when upgrading or deploying a new domain controller on the far end of a slow WAN link, back up the system state information from an existing domain controller and physically ship the backup media to the remote site. Then upgrade the BDC to Windows Server 2003 (or perform a clean install) and, before running the Active Directory Installation Wizard, restore the files to a local hard drive (by specifying Restore Files To: Alternate Location In Backup). Then run the Active Directory Wizard (Dcpromo.exe) with the /adv switch and specify the location of the restored files. This seeds the new or upgraded domain controller with a slightly out-of-date copy of the Active Directory database, which Active Directory updates during the first replication. This first replication is significantly faster than if you replicated the entire Active Directory database.

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

Schedule the domain upgrade at a time that has the lowest impact on the user population. It’s best to avoid upgrades during major projects and during the busiest times of year if possible. Even perfect upgrades produce some impact on the users, especially if you perform any domain restructuring or consolidation.

It’s important to ascertain whether Active Directory is functioning properly after a domain upgrade, before it’s too late to back out and restore the Windows NT 4.0 domain. Use these criteria as a starting point: