As part of the design of Active Directory directory service, you should examine the network topology and determine if you need to manage network traffic between subnets or business locations. To manage network traffic related to Active Directory, you use sites, which can be used to reflect the physical topology of your network. Every Active Directory implementation has at least one site. An important part of understanding sites involves understanding Active Directory replication. Active Directory uses two replication models: one model for replication within sites and one model for replication between sites. You need a solid understanding of these replication models to plan your site structure.
A site is a group of Transmission Control Protocol/Internet Protocol (TCP/IP) subnets that are implemented to control directory replication traffic and isolate logon authentication traffic between physical network locations. Each subnet that is part of a site should be connected by reliable, high-speed links. Any business location connected over slow or unreliable links should be part of a separate site. Because of this, individual sites typically represent the individual local area networks (LANs) within an organization, and the wide area network (WAN) links between business locations typically mark the boundaries of these sites. However, sites can be used in other ways as well.
Sites do not reflect the Active Directory namespace. Domain and site boundaries are separate. From a network topology perspective, a single site can contain multiple TCP/IP subnets as well. However, a single subnet can be in only one site. This means that the following conditions apply:
A single site can contain resources from multiple domains.
A single domain can have resources spread out among multiple sites.
A single site can have multiple subnets.
As you design site structure, you have many options. Sites can contain a domain or a portion of a domain. A single site can have one subnet or multiple subnets. It is important to note that replication is handled differently between sites than it is within sites. Replication that occurs within a site is referred to as intrasite replication. Replication between sites is referred to as intersite replication. Each side of a site connection has one or more designated bridgehead servers.
Figure 35-1 shows an example of an organization that has one domain and two sites at the same physical location. Here, the organization has an East Campus site and a West Campus site. As you can see, the organization has multiple domain controllers at each site. The domain controllers in the East Campus site perform intrasite replication with each other, as do the domain controllers in the West Campus site. Designated servers in each site, referred to as site bridgehead servers, perform intersite replication with each other.
Figure 35-2 shows an example of an organization that has two different physical locations. Here, the organization has decided to use two domains and two sites. The Main site is for the cohowinery.com domain and the Seattle site is for the sea.cohowinery.com domain. Again, replication occurs both within and between the sites.
One reason to create additional sites at the same physical location is to control replication traffic. Replication traffic between sites is automatically compressed, reducing the amount of traffic passed between sites by 85 to 90 percent of its original size. Because network clients try to log on to network resources within their local site first, this means that you can use sites to isolate logon traffic as well.
It is recommended that each site have at least one domain controller and one global catalog for client authentication. For name resolution and IP address assignment, it is also recommended that each site have at least one Domain Name System (DNS) server and one Dynamic Host Configuration Protocol (DHCP) server. Then, by creating multiple sites in the same physical location and establishing a domain controller, global catalog, and DNS and DHCP server within each site, you can closely control the logon process.
Sites should also be designed with other network resources in mind, including distributed file system (DFS) file shares, certificate authorities, and Microsoft Exchange 2000 servers. You want to configure sites so that clients' network queries can be answered within the site. If every client query for a network resource has to be sent to a remote site, there could be substantial network traffic between sites which could be a problem over slow WAN links.
A good example of the importance of locating network resources within a site is Exchange 2000. All Exchange 2000 clients contact a global catalog server for the global address list. As a result, the number of queries to the global catalog server can be substantial. On a site with 1,000 clients using Exchange 2000, the global catalog server typically would get two to three requests per second from these clients.
Most organizations implementing Active Directory have multiple domain controllers. The domain controllers may be located in a single server room where they are all connected to a fast network or they may be spread out over multiple geographic locations, from which they are connected over a WAN that links the company's various office locations.
All domain controllers in the same forest—regardless of how many domain controllers there are and where domain controllers are located—replicate information with each other. Although more replication is performed within a domain than between domains, replication between domains occurs nonetheless. The same replication model is used in both cases.
When a change is made to a domain partition in Active Directory, the change is replicated to all domain controllers in the domain. If the change is made to an attribute of an object tracked by the global catalog, the change is replicated to all global catalog servers in all domains of the forest. Similarly, if you make a change to the forest-wide configuration or schema partitions, these changes are replicated to all domain controllers in all the domains of the forest.
Authentication within and between domains is also handled by domain controllers. If a user logs in to his or her home domain, the local domain control authenticates the logon. If a user logs in to a domain other than the home domain, the logon request is forwarded through the trust tree to a domain controller in the user's home domain.
Active Directory's replication model is designed for consistency, but the consistency is loosely defined. By loosely defined, I mean that at any given moment the information on one domain controller can be different from the information on a different domain controller. This can happen when changes on the first domain controller have not been replicated to the other domain controller. Over time, the changes made to one domain controller will be replicated to all domain controllers as necessary.
When multiple sites are involved, the replication model is used to store and then forward changes as necessary between sites. In this case, a domain controller in the site where the changes were originally made forwards the changes to a domain controller in another site. This domain controller in turn stores the changes, and then forwards the changes to all the domain controllers in the second site. In this way, the domain controller on which a change is made doesn't have to replicate directly with all the other domain controllers. It can instead rely on the store-and-forward technique to ensure that the changes are replicated as necessary.
When trying to determine site boundaries, you should configure sites so that they reflect the physical structure of your network. Use connectivity between network segments to determine where site boundaries should be located. Areas of the network that are connected with fast connections should all be part of the same site, unless you have specific requirements for controlling replication or the logon process. Areas of the network that are connected with limited bandwidth or unreliable links should be part of different sites.
As you examine each of the organization's business locations, determine whether placing domain controllers and other network resources at that location is necessary. If you elect not to place a domain controller at a remote location, you cannot make the location a part of a separate site. This has the following advantages:
No Active Directory replication between the business locations
No remote domain controllers to manage
No additional site infrastructure to manage
There are also several disadvantages to this approach:
All logon traffic will have to cross the link between the business locations.
Users may experience slow logon and authentication to network resources.
In the end, the decision to establish a separate site may come down to the user experience and the available bandwidth. If you have fast connections between sites—which should be dedicated and redundant—you may not want to establish a separate site for the remote business location. If you have limited bandwidth between business locations and want to maintain the user experience, you may want to establish a separate site and place domain controllers and possibly other network resources at the site. This will speed up the logon and authentication process and allow you to better control the network traffic between sites.