Active Directory Replication Topology

In "Active Directory Replication In Depth," I discussed the specifics of Active Directory (AD) replication technology with regard to how objects and attributes are actually kept in sync and how changes to them are tracked. A layer above this is the discussion of how AD decides which domain controllers (DCs) should replicate with one another. AD includes a very efficient background process known as the Knowledge Consistency Checker. The KCC is responsible for consuming information that administrators provide to AD in the form of subnets, sites, site links, and site link bridges to determine the best overall topology of connections between DCs. These connections are represented by connection objects, which the KCC automatically adds and removes as necessary. Your sites, site links, and site link bridges typically map closely to your network topology to form what's called a site topology. Figure 1 shows a sample site topology.

Site Topology Components

A site topology consists of sites, site links, and site link bridges.

Sites. Sites are a key part of your AD configuration, used not only for replication but also by clients and applications. Clients and applications use site information to find the DC or another resource that's logically closest to them on the network. To associate themselves with the correct site, clients depend on accurate subnet information in AD. Subnet information is defined in terms of IP subnet (IPv4 and/or IPv6) objects stored in the directory, which are in turn associated with sites.

In small environments with only a few sites, it's typically easy for administrators to keep subnet information up-to-date. But this task can be a challenge in large environments if there are frequent network changes and processes aren't in place to communicate these changes to AD administrators. When subnet information isn't up-to-date in AD, clients might be redirected to DCs that are across distant or slow WAN links, which leads to suboptimal performance at best. If your AD needs only one site, there's no need to define any subnets in AD.

Sites typically represent a group of well-connected subnets that contain one or more DCs. The definition for well-connected is very loose, although I like to use a minimum of a 10Mbps connection as a baseline. Sites typically (but not always) map directly to physical locations within your network; these locations contain DCs, as Figure 2 shows. A notable urban legend concerns the initial site that comes with a new AD forest: the Default-First-Site-Name site. Contrary to popular opinion, it's perfectly safe to delete or rename this site object depending on your requirements. There's no need to retain it as an empty site if you're not using it, or to not rename it if another name makes more sense.

In Figure 1, a company has offices in St. Louis and Detroit, but its DCs are located in Chicago. In this scenario, a single site is created for Chicago, but the subnets used in St. Louis and Detroit are associated with the Chicago site (in addition to the subnet for Chicago).

Although it's common to only create sites when there's a DC at that location, some applications, such as Distributed File System (DFS) and Microsoft System Center Configuration Manager (SCCM), take advantage of site information. For example, if you have an SCCM server at a location that doesn't have a DC, you'll probably need to create a site. When a site doesn't contain a DC, AD uses a process called automatic site coverage to determine which DCs clients in that site should use.

In Figure 2, the organization has offices in Seattle, Los Angeles, and San Diego. DCs are located in Seattle; however, an SCCM server also exists in San Diego. To ensure that San Diego clients connect to their local SCCM server, a site for San Diego is created and the San Diego subnet is associated with it. A second site for Seattle is created that contains the Seattle DCs, as well as the subnets for Seattle and Los Angeles.

Site links. We've discussed sites and the subnet objects that describe which clients should associate with that site—but we haven't discussed how sites are connected in AD. AD connects sites using site links. Site links frequently model your WAN topology. Site links contain two or more sites, and they model the paths replication can take, as well as influence client decisions around logically closest DCs and other servers. Although it's possible to connect more than two sites with a site link, site links are typically easier to manage if you stick with defining point-to-point site links (i.e., site links with only two sites in them).