Chapter 6: Configuring and Troubleshooting Active Directory Domains

Certainly, the title of this chapter encompasses a broad topic that cannot be fully covered even in a dozen books. We will discuss only certain issues here, ones that you inevitably encounter in your practice, and that you should not forget about. See also Chapter 9, "General Characteristics and Purpose of System Tools", that will help you to select the necessary tools and utilities for your work, and simplify the troubleshooting process. Do not neglect these very useful tools! (Though alas, in practice, quite often many indeed do neglect them.)

In this chapter, all considerations of Active Directory domains cover both Windows 2000 and Windows .NET domains unless otherwise noted.

Placing Flexible Single-Master Operation (FSMO) Roles

Every Active Directory beginner first gets a piece of good news: all Active Directory domain controllers (running either Windows 2000 or Windows .NET) are peers; write operations are permitted on every domain controller (DC); and all changes are replicated from the originating DC to others (so-called multi-master replication is used). These features are quite advantageous when compared to the rules accepted in Windows NT-based domains.

Some time later, the beginner gets some bad news: there are operations when some DCs perform additional functions (i.e., in comparison with other DCs), and instead of the one role available for a DC in Windows NT-based domains — either Primary Domain Controller (PDC) or Backup Domain Controller (BDC)—an Active Directory domain controller can simultaneously perform up to five different roles^[1]. These roles are known as Flexible Single-Master Operation (FSMO) roles. (You can easily find a description of each role in the Help and Support Center. Open the Index tab and enter FSMO as the keyword, or use the Search tab. See also the "Managing FSMO Roles in the Forest" section in Chapter 8, "Common Administrative Tasks" and the "How to Find an FSMO Master?" section in Chapter 17, "Scripting Administrative Tasks.")

Fig. 6.1 illustrates the default placement of FSMO roles within a forest. As you can notice, every first DC created in a domain holds three domain-wide roles; and in addition, the first DC located in the forest root domain holds two forest-wide roles.

Fig. 6.1: Default placement of FSMO role owners in a forest

There are many guidelines for placing FSMO roles; we will consider only a few rules that you should not violate:

• Notwithstanding the fact that the Primary Domain Controller (PDC) Emulator in Active Directory domains does not play as important a role as the PDC plays in Windows NT domains, you must carefully assign this role. Even in the native mode Windows 2000 domains or Windows .NET (version 2002) level Windows .NET domains, the PDC Emulator is used as a primary authority for updating user passwords and controlling failed authentication requests.

  By default, the PDC Emulator is selected by the Group Policy Object Editor snap-in, and you may have trouble editing group policies if the PDC Emulator is inaccessible. Keep the PDC Emulator and Relative Identifier (RID) Master role on the same DC. However, keep in mind that these two roles can produce a considerable workload on that DC.

  All DCs in a domain will synchronize the clock with the PDC Emulator. In a multiple-domain forest, the PDC Emulator from each domain will synchronize the clock with the PDC Emulator located in the forest root domain. The forest root PDC Emulator should synchronize its clock with an external time source.

• If a domain has two or more DCs, the Infrastructure Master and a Global Catalog (GC) server must not be placed on the same DC; however, they need to be connected by a high-speed link to reduce network traffic. (You can ignore this requirement if there is only one DC in a domain, or if each DC in a domain is the GC server.) It is advisable to deploy at least one GC per site. (You may also consider universal group membership caching available in Windows .NET domains.) However, it is not typically recommended that you designate all DCs in the domain as GC servers, since this produces additional network traffic.

• Place both per-forest roles — Schema Master and Domain Naming Master on the same DC. In Windows 2000, assign this DC as a GC server; this is not required, if Domain Naming Master runs on a Windows .NET-based DC. This is mandatory to guarantee the uniqueness of names in the forest.

• By default, the first DC installed into a domain owns all of the domain operations master roles. If you remove Active Directory from this domain controller, all roles are automatically transferred to another available DC. If the demotion process fails, you must manually seize the operations master roles. As a "best practices" rule, you might consider manual transferring of any roles before demotion of a DC. (See the description of the NTDSutil tool in Chapter 10, "Diagnosing and Maintaining Domain Controllers.") If the demoting DC is a GC server, you must first be sure that there are other GC servers in the forest, and then designate a new GC server if necessary.

• If you restore a DC that owns some FSMO roles, these roles will be also restored. Therefore, you may need to review all current role owners after the restore is completed.

^[1]In fact, this number may even increase if one takes into consideration the fact that the Infrastructure Master role also exists for each created application directory partition.