Most companies do the right thing when it comes to Active Directory (AD) site design. For example, suppose you have several sites connected by T1 lines, as Figure 37.1 shows. The T1 lines represent your WAN's physical connectivity, and all the AD design guidelines tell you that your site links should reflect that physical connectivity.
Figure 37.1: Sample physical WAN design.
If you set up one site link per T1 link, you'll wind up with a design somewhat like the one in Figure 37.2. This configuration is straightforward and reflects the way that most companies build their sites and networks. If you have additional backup links between sites, you might even configure separate site links for those, configuring a higher link cost to reflect the link's nature as a backup.
Figure 37.2: Site link topology.
What you might not realize is that AD, by default, creates site link bridges for every site link. This setup isn't necessarily a bad idea. For example, consider what happens if an administrator locks out a user account in the Bath office. Obeying only the site links, AD will have to replicate that change from a bridgehead in the Bath office to a bridgehead in the Boston office, then to New York, LA, Las Vegas, and finally Reno. Depending upon your replication schedules, it could be quite some time before a Reno domain controller actually locked out the user's account, even though account lockout is a high-priority change for replication. In the meantime, a user could be logging on to a Reno or Las Vegas domain controller, relying on the fact that those domain controllers haven't yet heard about the lockout.
AD's automatic site link bridges create a topology similar to the one in Figure 37.3, in which each site is logically linked to the others.
Figure 37.3: Site link bridges are shown in green.
When a change is made at the Bath office, its bridgehead domain controllers replicate directly to bridgehead domain controllers in each of the other offices. Effectively, AD is ignoring the physical layout of your network a bit in order to speed replication. The cost is that your WAN links are going to carry more traffic than you might expect. For example, the link connecting Las Vegas and LA will carry Bath's change twice—once as Bath replicates with Las Vegas, and once as Bath replicates with Reno. The link between Bath and Boston will carry the same replication traffic five times—once for each of the other offices.
You don't have to let AD create site link bridges automatically. In fact, you can disable the behavior entirely. However, doing so puts you right back to a high degree of replication latency, which may not be any more desirable than wasting WAN bandwidth. Fortunately, there's a happy middle ground. Consider the topology that Figure 37.4 shows, in which two site link bridges have been manually created.
Figure 37.4: Manually created site link bridges.
In this case, a change made at Bath would replicate to Boston and LA, because LA is "virtually" connected to Bath. LA would then replicate to New York and Las Vegas. Reno would receive the information last, either from New York or Las Vegas. You might reconfigure this setup a bit to have the Reno site link bridge connecting to LA rather than New York; doing so would place more burdens on LA-based domain controllers, but would disseminate the information in fewer steps. The site link bridges effectively shortcut the physical topology, wasting a small amount of WAN bandwidth but providing minimal replication latency.
You can make this configuration change in the AD Sites & Services console. You'll need to make the change for each intersite replication transport in use, although most companies will just have IP. Right-click the transport's folder, and select Properties from the context menu. As Figure 37.5 shows, the default behavior is to bridge all site links; you can disable this behavior by clearing the check box.
Figure 37.5: Default settings of the IP intersite transport.
If you disable this behavior, you should definitely review your manual site link bridges and create new ones as necessary to provide the desired amount of replication latency. I recommend testing your new topology by making changes in your furthest-out office (Bath, in our example) and measuring the amount of time it takes the change to replicate to the opposite corner of your network (Reno, in our example). Adding site link bridges that bridge from the edges of your WAN to the middle of your WAN is the most effective strategy, as it provides the most efficient shortcut for replication traffic.