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).
Site links have several properties that you can tweak in addition to the sites contained within the site link. These properties include cost, replication frequency (how often replication occurs over the site link), and replication schedule (when replication can begin). Cost is probably the most misunderstood property of site links.
AD factors cost into decisions only when there are multiple paths between any two sites. If there's only one path, then cost doesn't matter because it's mandatory to use that site link. The value for cost also isn't particularly important as long as the preferred path is a lower cost than other paths. If you do need to set site link costs, there are a few strategies for doing so. The first strategy is to use values that are proportional to WAN link speed. This table makes a good cheat sheet if you opt for this approach. Another common strategy is to use static values for different types of connections. For example, connections between data centers have cost 100, connections between data centers and spokes have cost 200, and connections between spokes have cost 300.
Figure 3 shows a simple scenario in which site link cost doesn't matter. In this example, we have three AD sites: New York, Boston, and Atlanta. WAN links exist between New York and Boston, as well as between New York and Atlanta. Using this information, site links were created to model the WAN topology. Because there's only one path between each site, the costs on the site links are irrelevant.
Figure 4 shows a scenario in which site link costs do matter. In this scenario, each of the three sites is connected with a WAN link. Using this information, site links were created linking each of the three sites in a full mesh topology. Costs were set such that the links between Houston and Dallas and Houston and Austin are preferred over the link between Dallas and Austin.
In addition to cost, site links also have frequency and schedule properties. The frequency is fairly straightforward in that it defines how often AD will initiate normal replication over the site link. This value can be as low as 15 minutes or as high as 1 week. If you need replication to occur more frequently than every 15 minutes, you can enable change notification for the site link by following these steps:1. Launch ADSIEdit (Select Start, Run, ADSIEdit.msc).
2. Browse to \Configuration\Sites\Inter-Site Transports\IP.
3. Right-click the site link you want to edit, and select Properties.
4. Double-click the Options attribute.
5. Add 1 to the value displayed. If the value is null, set it to 1.
Change notification will cause AD to enable intra-site style replication over the site link, which will lead to synchronization occurring almost in real time. This change is typically made for site links that connect data centers.
Finally, the schedule defines when (i.e., during what time) Windows replication can begin. By default, the schedule allows replication to begin at any time; however, you might have a scenario in which you don't want to use a WAN link during certain times—possibly because of utilization, or for other reasons. A key data point around the replication schedule is that the schedule defines when replication can begin. After replication begins during the scheduled window, it won't stop until it's finished.
Now that we've looked at a few examples, let me highlight two final tips about site links that relate to naming and the default site link. One handy way to name site links is to name the link according to the two connected sites (e.g., New York-Boston), and then reverse the order in the Description field (i.e., Boston-New York). This approach lets you sort on either column in the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in, depending on how you need the data presented. When a new AD forest is created, an initial site link is provisioned called the DEFAULTIPSITELINK. Much like the initial default site, you can rename or delete this site link if doing so makes sense.
Site link bridges. The final component of AD site topology is undoubtedly the least used. This component is known as the site link bridge. Site link bridges are used when you have a network that isn't fully routed. When your network is fully routed, a client (or server) on any part of the network can connect to a client (or server) on any other part of the network (with the exception of firewalls blocking this action). A common situation in which you might not have a fully routed network is if you have branch offices and it isn't possible for one branch office to communicate with another branch office over the network. Another scenario is when sites in one region can't connect to sites in another region.
By default, a setting called Bridge All Site Links (BASL) is enabled in AD. With BASL enabled, a DC in the Boston site (see Figure 3) can replicate directly with a DC in the Atlanta site, bypassing any DCs in New York, even though there's no site link connecting Boston and Atlanta. If this isn't possible in your network, you'll need to disable BASL. With BASL disabled, you can use site link bridges to define sets of site links that are fully routed.
In Figure 5, the only possible path over the network from North America to Europe is between servers in Denver and London. Within each region, there's full mesh connectivity over the WAN. To represent this in AD, it's necessary to create two site link bridges—one for North America and one for Europe. The North America bridge contains the Denver-Phoenix and Denver-Miami site links, whereas the Europe bridge contains the London-Paris and London-Munich site links.
Creating Replication Connections
After you define your site link topology in AD, AD still needs to do some work to determine which DCs will replicate with one another. This calculation is performed in the background by the KCC. Two different topologies are calculated, leading to the overall replication topology. The first topology is for intra-site replication. Intra-site replication is replication between DCs that are in the same AD site. With intra-site replication, the KCC doesn't need to worry about things like site links and site link bridges because all the DCs are considered to be well connected. With this in mind, the KCC calculates a topology that's centered around ensuring that no DC in a given site is more than three hops away from any other DC in the site. This ensures that DCs within a site can converge and be in sync within about a minute (this time used to be about 15 minutes in Windows 2000 forests). Figure 6 shows a sample topology with four DCs in a site, considering the three-hop rule.
Inter-site replication topologies are calculated according to the site topology information that's included in AD. The calculation of inter-site replication topologies is performed by the Inter-Site Topology Generator. The ISTG is a component of the KCC that runs on one DC in each AD site and is responsible for creating connection objects for replication across site links.
AD is very adept at calculating replication topologies within an AD site—but to replicate across site boundaries, administrators must provide information so that AD can select the best path. This information is provided in the form of sites, site links, and site link bridges that typically closely mirror the organization's WAN topology. With this information, the KCC and the ISTG can create efficient replication topologies for the forest.
Windows IT Pro Resources