Designing the Active Directory Structure

Previous Topic Next Topic

Placing Servers into Sites

The location of servers on your site topology has a direct effect on the availability of Active Directory. During the physical partitioning exercise of the domain plan, you created a basic plan for domain controller placement. By placing servers onto the site topology, you will complete the details of this plan.

Placing Additional Domain Controllers

During the partitioning exercise, you decided which sites would have domain controllers for each domain, but you did not decide on the number of domain controllers that would be placed in each site for each domain. The number of domain controllers you will create for a particular domain is driven by two factors: fault tolerance requirements and load distribution requirements.

For each domain, use the following guidelines to determine if more domain controllers are necessary:

Always create at least two domain controllers.   Even for small domains with small user populations, create at least two domain controllers so that there is no single point of failure for the domain.

For each site that contains a single domain controller, decide if you trust the WAN for failover.   If the single domain controller fails, clients in the site can be serviced by other domain controllers for that domain that are located in other sites. If network connectivity is unreliable or intermittently available, you might not want to trust the network to handle failover. In that case, place a second domain controller for that domain into the site.

Place additional domain controllers for a domain into a site to handle the client workload.The number of clients that a particular server can handle depends on the workload characteristics and the hardware configuration of the server. Clients randomly select from the available domain controllers in a site to distribute client load evenly.

Placing Global Catalog Servers

The availability of global catalog servers is crucial to the operation of the directory. For example, a global catalog server must be available when processing a user log on request for a native-mode domain, or when a user logs on with a user principal name.


note-icon

Note

When processing a log on request for a user in a native-mode domain, a domain controller sends a query to a global catalog server to determine the user's universal group memberships. Since groups can be explicitly denied access to a resource, complete knowledge of a user's group memberships are necessary to enforce access control correctly. If a domain controller of a native-mode domain cannot contact a global catalog server when a user wants to log on, the domain controller refuses the log on request.

As a general rule, designate at least one domain controller in each site as a global catalog server.

Use the same failover and load distribution rules that you used for individual domain controllers to determine whether additional global catalog servers are necessary in each site.


note-icon

Note

In a single domain environment, global catalog servers are not required to process a user log on request. However, you should still designate global catalog servers using the suggested process. Clients still seek global catalog servers for search operations. Also, having global catalog servers already in place allows the system to adapt gracefully if you add more domains later.

Placing DNS Servers

The availability of DNS directly affects the availability of Active Directory. Clients rely on DNS to be able to find a domain controller, and domain controllers rely on DNS to find other domain controllers. Even if you already have DNS servers deployed on your network today, you might need to adjust the number and placement of servers to meet the needs of your Active Directory clients and domain controllers.

As a general rule, place at least one DNS server in every site. The DNS servers in the site should be authoritative for the locator records of the domains in the site, so that clients do not need to query DNS servers off-site to locate domain controllers that are in a site. Domain controllers will also periodically verify that the entries on the primary master server for each locator record are correct.

A simple configuration that satisfies all requirements is to use Active Directory–integrated DNS, store the locator records for a domain within the domain itself, and run the Windows 2000 DNS service on one or more domain controllers for each site where those domain controllers appear.

Distributing the Forest Wide Locator Records

Each domain controller in the forest registers two sets of locator records: a set of domain-specific records that end in <DNS-domain-name>, and a set of forest-wide records that end in _msdcs.<DNS-forest-name>. The forest-wide records are interesting to clients and domain controllers from all parts of the forest. For example, the global catalog locator records, and the records used by the replication system to locate replication partners, are included in the forest-wide records.

For any two domain controllers to replicate between each other, including two domain controllers from the same domain, they must be able to look up forest-wide locator records. In order for a newly created domain controller to participate in replication, it must be able to register its forest-wide records in DNS, and other domain controllers must be able to look up these records. For this reason, it is important to make the forest-wide locator records available to every DNS server in every site.

To do this, create a separate zone called _msdcs.<DNS-forest-name>, and replicate that zone to every DNS server. If you are using the simple Active Directory-integrated configuration, you can place the primary copy of this zone in the forest root domain along with the <DNS-forest-name> zone. You can then replicate the zone to DNS servers outside the domain using standard DNS replication.

Generally, it is not sufficient to replicate the zone to only one DNS server per site. If a DNS server does not have a local copy of the _msdcs.<DNS-forest-name> zone, it must use DNS recursion to look up a name in that zone. For a DNS server to perform recursion, it contacts a DNS server that is authoritative for the root of the namespace (a DNS root server) and proceeds down the delegations in DNS until it finds the record in question. If there is no DNS root server in a site, and the links between that site and other sites are down, a DNS server cannot perform recursion. Thus, it will not be able to find any DNS servers that are authoritative for _msdcs.<DNS-forest-name>, even if those DNS servers are in the same site.

DNS Client Configuration

Clients and domain controllers should be configured with at least two DNS server IP addresses: a preferred local server, and an alternate server. The alternate server can be in the local site, or it can be remote if you trust your network to handle the failover.

© 1985-2000 Microsoft Corporation. All rights reserved.