Lesson 2: Planning the Active Directory Physical Structure

To a large degree, the availability of Active Directory services in your network is determined by how you’ve designed Active Directory’s physical structure. Your design of the physical structure must take into account site design, replication, optimizing network traffic, confining authentication to a specific segment of your network, and the placement of domain controllers, global catalog servers, and operations masters. This lesson describes the steps that you should take when planning the Active Directory physical structure.

After this lesson, you will be able to

• Define a site structure and determine where to place domain controllers, global catalog servers, and operations masters
• Define a replication strategy

Estimated lesson time: 30 minutes

Planning Process

When planning the physical structure of Active Directory services in your network, you must define a site structure in order to determine where domain controllers should be placed, define an intersite replication strategy, and determine where global catalog servers and operations masters should be placed. This lesson describes each of these steps.

Defining a Site Structure

In Lesson 1 you learned that a site is made up of one or more subnets connected by highly reliable and fast links. Sites have two main roles: to facilitate client authentication and streamline directory replication traffic.

When a client attempts to log on to a domain, it sends its request to a domain controller that’s within the same site, if one is available. If one isn’t available, the client attempts to communicate with domain controllers in any other site. The authentication process is much more efficient if a client can be authenticated by a domain controller that’s well connected, usually within the same site. You should also take site structure into account when you use firewalls to connect network segments. In most cases you’d want to control the authentication (and replication) traffic that crosses the firewall.

In addition to affecting the authentication process, the site structure affects directory replication. Active Directory handles intrasite replication differently from intersite replication. As a result, bandwidth is important when you plan your site structure. You must take into consideration your subnet structure, your network’s LAN and WAN connectivity, the placement of perimeter networks and firewalls, and your organization’s network traffic patterns. Any time two network segments are connected by links that are heavily used during some parts of the day and idle at others, you should create separate sites to prevent replication traffic from competing with other traffic during high usage hours.

Designing a Site Structure

When setting up Active Directory sites, you must take into account how your organization is set up in terms of geographic locations and connectivity. You need to know how the network is subnetted and how those subnets are connected. You must also determine the speed of the connections and the average available bandwidth during normal business hours.

Generally, you should create a site for each of the following:

• A LAN or set of LANs that are connected by a high-speed link
• A perimeter network that’s separated from another network segment by a firewall
• A location that’s reachable only by Simple Mail Transfer Protocol (SMTP) mail (and doesn’t have direct connectivity to the rest of the network)

When you’re designing your Active Directory site structure, you’re basically taking your network’s physical topology and creating a more general topology that’s based on available bandwidth, network reliability, and network segmentation, as is the case for a perimeter network. If you want particular clients to log on to a specific set of domain controllers, you should define your site structure so that only those domain controllers are in the same site as the clients.

Placing Domain Controllers

Once you’ve determined how you’ll set up your Active Directory sites, you can decide how you’ll place domain controllers in those sites. The availability of domain controllers determines Active Directory availability and the ability of users to be authenticated. Each domain requires at least one domain controller, although each domain should include at least two domain controllers to avoid any single points of failure. However, the number of domain controllers that you place in a particular domain should be determined by your fault tolerance and your organization’s load distribution requirements.

When deciding how many domain controllers to place in your domain and where to put them, you must determine the level of fault tolerance that you want to ensure in that site. You must also take into account the connections between sites and whether you want to confine client authentication to specific domain controllers. You should put a domain controller into a site under the following conditions:

• A large number of clients connect to the site.
• You want clients to be authenticated at a specific set of domain controllers.
• The connection to other sites is slow, near capacity, or sometimes unavailable.
• The connection to other sites is through a firewall.
• The site is accessible only by using SMTP mail.

To ensure optimum network response time and application availability, you should place at least one domain controller in each site and two domain controllers in a domain. However, you should place additional domain controllers in a site in the following situations:

• A large number of clients use the site. If there’s not enough processing power to service requests, performance will lag and clients might experience slow logon times and slow authentication when attempting to access resources.
• Intersite connections are relatively slow, unreliable, or near capacity. If a single domain controller fails, clients must connect to domain controllers in other sites. If the site links are unreliable, users might not be able to log on to their computers.
• You want clients to be authenticated at a specific set of domain controllers. In these cases you might want to prevent users from going to another site to request authentication if a domain controller fails. For example, you might want to ensure that client requests generated within a perimeter network are always authenticated on that side of the firewall.

In some situations you might not want to place a domain controller in a site, such as a site with a small number of users or a small site that has client computers but no servers. However, to ensure high performance and availability, most sites should contain at least one domain controller and some sites should have multiple domain controllers.

Defining an Intersite Replication Strategy

After you’ve defined your site structure and determined the placement of domain controllers, you can plan your intersite replication strategy. Planning for intersite replication consists primarily of determining how site links will be configured. Site links, which are logical, transitive connections between sites, allow you to customize how Active Directory replicates information between sites.

Once you create site links, the Knowledge Consistency Checker (KCC) automatically creates the appropriate connection objects that connect domain controllers. The KCC uses the site links to determine replication paths between two sites. Unlike connection objects, you must create the site links manually.

By default, all site links are transitive. However, if you disable this transitivity for a transport, all site links for that transport are affected and none of them are transitive. In that case you must create site link bridges to provide transitive replication. A site link bridge connects two or more site links in a transport to create a link between two sites that don’t have an explicit site link. However, because site links are transitive by default, it’s seldom necessary to create site link bridges.

For each intersite transport, the KCC automatically designates a domain controller in each site as a bridgehead server and creates connection objects between the bridgehead servers. You can also specify a preferred bridgehead server in situations where you want to control which server is the replication point for that site.

For each site link that you create, you must provide the following information:

• Replication schedule The scheduled times and days on which replication polling occurs over a seven-day interval. The default daily schedule allows polling to occur all day, every day.
• Replication interval The scheduled intervals in which replication polling occurs. The default polling interval is three hours.
• Replication transport The type of transport used by the site link. You can choose IP or SMTP.
• Link cost The relative bandwidth of the connection, as compared to other site links. You can choose between 1 and 32,767. Lower values should indicate better connectivity and higher usage priority. The default link cost is 100.

You should configure your site links according to available bandwidth, network usage patters, and type of transport. To create more reliable, fault-tolerant replication, configure additional site links to provide redundant replication paths.

Your site link configurations must be optimized for your specific network environment. For example, suppose your organization’s network is divided into four sites. Figure 8.5 shows the site topology for these sites. The solid lines connecting the sites represent an IP transport type. The dotted line represents an SMTP transport type.

Figure 8.5 - Active Directory site topology

In addition to the four sites, the figure shows four site links. Table 8.1 shows a possible configuration strategy for your organization. The strategy would take into account your network structure and capacity.

Table 8.1 Site Link Parameters

Site Link	Replication Schedule	Replication Interval	Transport Type	Link Cost
Sea-Pdx	Always	1 hour	IP	25
Sea-Den	1800 to 0600, daily	30 minutes	IP	100
Pdx-Den	1800 to 0600, daily	15 minutes	IP	50
Sea-Slc	1800 to 0600, daily	15 minutes	SMTP	100

Three out of the four site links are scheduled for replication at off-peak hours only. The Sea-Pdx site link allows replication to occur every hour, all day, every day. This would be a good strategy to use if the connection between the Seattle and Portland sites is reliable and has plenty of bandwidth. Notice, however, that a longer polling interval has been configured. On the other hand, the Sea-Slc site link replicates every 15 minutes, but only during off-peak hours.

Placing Global Catalog Servers and Operations Masters

The final step in planning your Active Directory physical structure is to determine where you’ll place the global catalog servers and the operation masters.

Placing Global Catalog Servers

A global catalog server holds a copy of the global catalog. The global catalog’s availability is crucial to the operation of Active Directory. For example, the logon process requires that the global catalog be available to determine group memberships when a user logs on to a native-mode domain. If the global catalog isn’t available, the domain controller refuses the logon request.

To achieve optimum network response time and application availability, you should locate at least one global catalog server in each site to provide clients with a local computer to service query requests. If you want to increase availability for a site, you should add more global catalog servers. Place additional global catalog servers in a site in the following situations:

• A large number of clients use the site.
• Intersite connections are relatively slow, unreliable, or near capacity.

Placing Operations Masters

Active Directory supports five operations masters: schema master, domain naming master, relative ID master, PDC emulator, and infrastructure master. A forest must contain exactly one schema master and one domain at any one time. Each domain in the forest must contain exactly one relative ID master, one PDC emulator, and one infrastructure master at any one time. When you create the first domain in a new forest, all operations master roles are assigned to the first domain controller. As you add child domains and create trees in the forest, Active Directory automatically assigns operations master roles according to the structure of the forest.

In a domain containing only one domain controller, all five operations master roles are assigned to that domain controller. In a domain that contains more than one domain controller, you can assign the roles to different domain controllers. When assigning operations master roles, you should adhere to the following guidelines:

• Make one domain controller the operations master and make another domain controller a standby operations master.
• In large domains, place the relative identifier master and PDC emulator on separate domain controllers. Both servers should be direct replication partners with a standby operations master.
• Don’t assign the infrastructure master role to a domain controller that’s hosting the global catalog, although you should assign this role to a domain controller that’s well connected to a global catalog in the same site. Note that if all domain controllers in the domain are hosting the global catalog, it doesn’t matter which domain controller is the infrastructure master.

Making a Decision

The process of planning the Active Directory physical structure includes defining a site structure, defining a replication strategy, and determining where to locate domain controllers, global catalog servers, and operations masters. Table 8.2 lists the specific steps that you should follow when planning the physical structure and describes what factors you should take into consideration for each step.

Table 8.2 Planning the Active Directory Physical Structure

Step	Description
Defining a site structure	Each site should be made up of one or more subnets connected by highly reliable and fast links.
Placing domain controllers	Each domain must include at least one domain controller and at least two domain controllers to provide fault tolerance. To determine how many additional domain controllers to place in your domain, you must take into account your fault tolerance and distribution requirements.
Defining an intersite replication strategy	For each site link you must configure a replication schedule, replication interval, replication transport, and link cost.
Placing global catalog servers and operations masters	A copy of the global catalog must be available to every domain controller in your network. In addition, a forest must contain exactly one schema master and one domain naming master at any one time. Each domain in the forest must contain exactly one relative ID master, one PDC emulator, and one infrastructure master at any one time.

Recommendations

When planning the Active Directory physical structure, you should adhere to the following guidelines:

• Create a site for each LAN or set of LANs connected by high-speed links, any perimeter networks separated from other network segments by firewalls, and any location reachable only by SMTP.
• Place at least one domain controller in each site and two domain controllers in each domain. Place additional domain controllers in a site when a large number of clients access the site; intersite connections are relatively slow, unreliable, or near capacity; or clients should be authenticated at a specific set of domain controllers.
• Configure your site links according to available bandwidth, network usage patterns, and type of transport. If appropriate, configure additional site links to provide redundant replication paths.
• Locate at least one global catalog in each site. Place additional global catalog servers in a site when a large number of clients access the site or intersite connections are relatively slow, unreliable, or near capacity.
• Provide a standby operations master. In large domains, place the relative identifier master and PDC emulator on separate domain controllers. Don’t assign the infrastructure master role to a domain controller that’s hosting the global catalog unless all domain controllers in the domain are global catalog servers.

Example: Active Directory Physical Structure for Woodgrove Bank

Woodgrove Bank has implemented a Windows 2000 native-mode network that includes only one domain. The network includes a perimeter network to support the bank’s Web operations. In setting up Active Directory, administrators created a site in the perimeter network and another site inside the corporate network. The sites are separated because the two network segments are connected by a fire-wall, and administrators wanted Web clients to be authenticated from within the perimeter network and not the corporate network.

To ensure high performance and availability, two domain controllers are included in the perimeter network site. Each of these domain controllers is configured with the global catalog. Additional domain controllers are located in the corporate network. To facilitate fault tolerance in the corporate network and to minimize traffic across the firewall, redundant domain controllers have been configured to act as backups for the global catalog server and the operations master.

Figure 8.6 illustrates how Active Directory is integrated into the network to provide fault tolerance, maximum network performance, and separate operations on either side of the firewall to support the bank’s Web operations.

Figure 8.6 - Active Directory integrated into the perimeter network

Lesson Summary

When planning the physical structure of Active Directory, you must define a site structure, determine where domain controllers should be placed, define an inter-site replication strategy, and determine where global catalog servers and operations masters should be placed. Site structures facilitate client authentication and streamline replication traffic. You should create a site for each LAN or set of LANs that are connected by a high-speed link, a perimeter network that’s separated from another network segment by a firewall, or a location that’s reachable only by SMTP mail. Each domain requires at least one domain controller, although it should include at least two to avoid creating any single points of failure. You should place a domain controller in a site when a large number of clients connect to the site; when you want clients to be authenticated at a specific set of domain controllers; when the connection to other sites is slow, near capacity, or sometimes unavailable; or when the connection to other sites is through a firewall. You should place additional domain controllers in a site when a large number of clients use the site; when intersite connections are relatively slow, unreliable, or near capacity; or when you want clients to be authenticated at a specific set of domain controllers. Planning for intersite replication consists primarily of determining how site links will be configured. For each site link, you must configure the replication schedule, replication interval, replication transport, and link cost. To achieve optimum network response time and application availability, you should locate at least one global catalog server in each site to provide clients with a local computer to service query requests. Place additional global catalog servers in a site when a large number of clients use the site or when intersite connections are relatively slow, unreliable, or near capacity. When assigning operations master roles, you should make one domain controller the operations master and make another domain controller a standby operations master. In large domains, place the relative identifier master and PDC emulator on separate domain controllers. Don’t assign the infrastructure master role to a domain controller that’s hosting the global catalog.