To map the network structure to site structure, start by examining each network location and the speed of the connections between those locations. In general, if you want to make separate network locations part of the same site, the sites should have at least 512 Kbps of available bandwidth. If the sites are in separate geographic locations, I also recommend that the network locations have redundant links for fault tolerance.

These recommended speeds are for replication traffic only, not for other user traffic. Smaller organizations with fewer than 100 users at branch locations may be able to scale down to dedicated 128-Kbps or 256-Kbps links. Larger organizations with 250 or more users at branch locations may need to scale up.

Following the previous example, the Chicago-based company would probably be best served by having separate sites at each network location. With this in mind, the site-tonetwork mapping would be as shown in Figure 35-11. By creating the additional sites at the other network locations, you help control replication over the slow links, which can significantly improve the performance of Active Directory. More good news is that sites are relatively low maintenance once you configure them, so you get a significant benefit without a lot of additional administration overhead.

Figure 35-11. Initial site-to-network mapping.

After you have determined how many sites you will have, you next need to consider the design of each site. A key part of the site design has to do with naming the sites and identifying the subnets that are associated with each site. Site names should reflect the physical location of the site. The default site created by Active Directory is Default-First-Site-Name, and most site names should follow a similar naming scheme. Continuing the example, you might use the following site names:

I've used dashes instead of spaces, following the style Active Directory uses for the default site. I've named the sites City-First-Site rather than City-Site to allow for easy revision of the site architecture to include additional sites at each location. Now, if a location receives additional sites, the naming convention is very clear, and it is also very clear that if you have a Seattle-First-Site, Seattle-Second-Site, and Seattle-Third-Site, these are all different sites at the Seattle location.

To determine the subnets that should be associated with each site, use the network diagram developed in the previous section. It already has a list of the subnets. In your site documentation, simply note the IP subnet associations that are needed and update your site diagram to include the subnets.

After you name the sites and determine subnet associations, you should design the intersite replication topology. You do this by planning the details of replication over each link designated in the initial site diagram. For each site link, plan the following components:

Typically, you'll want replication to occur at least every 180 minutes, 24 hours a day, 7 days a week. This is the default replication schedule. If you have limited bandwidth, you may need to alter the schedule to allow user traffic to have priority during peak usage times. If bandwidth isn't a concern or if you have strong concerns about keeping branch locations up to date, you may want to increase the replication frequency. In all cases, if possible you should monitor any existing links to get a sense of the bandwidth utilization and the peak usage periods.

Calculating the link cost can be a bit complicated. When there are multiple links between locations, you need to think carefully about the appropriate cost of each link. Even if there is only one link between all your sites now, you should set an appropriate link cost now to ensure that if links are added between locations, all the links are used in the most efficient way possible.

Valid link costs range from 1, which assigns the highest possible preference to a link, to 99999, which assigns the lowest possible preference to a link. When you create a new link, the default link cost is set to 100. If you were to set all the links to this cost, all the links would have equal preference for replication. But would you really want replication to go over a 128-Kbps link when you have a 512-Kbps link to the same location? Probably not.

In most cases, the best way to set link cost is to assign a cost based on the available network bandwidth over a link. Table 35-4 provides an example of how this could be done.

You can use the costs in the table to assign costs to each link you identified in your site diagram. Once you do this, update your site diagram so that you can determine the route that will be used for replication if all the links are working. As Figure 35-12 shows, your site diagram should now show the names of the sites, the associated subnets, and the cost of each link.

Figure 35-12. Updated site design to show site names, subnet associations, and link costs.

By default, Active Directory automatically configures site link bridges, which makes links transitive between sites in much the same way that trusts are transitive between domains.

When a site is bridged, any two domain controllers can make a connection across any consecutive series of links. The site link bridge cost is the sum of all the costs of the links included in the bridge. Let's calculate the site link bridge costs using the links shown in Figure 35-12. Because of site link bridges, the domain controllers at the Chicago headquarters have two possible routes for replication to each of the branch office locations. The costs of these routes are summarized in Table 35-5.

Knowing the costs of links and link bridges, you can calculate the effects of a network link failure. In this example, if the primary link between Chicago and Seattle went down, replication would occur over the Chicago-LA-Seattle site link bridge. It's relatively straightforward in this example, but if you were to introduce additional links between network locations, the scenarios become very complicated very quickly.

The network topology used in the previous example is referred to as a hub-and-spoke design. The headquarters in Chicago is the hub, and the rest of the offices are spokes. Automatic site link bridging works well with a hub-and-spoke design. It doesn't work so well when you have multiple hubs. Consider the example shown in Figure 35-13. In this example, Chicago is the main hub, but because Seattle and LA have a spoke, they are also considered hubs.

Figure 35-13. Additional sites added to original site design, making Seattle and LA hubs.

Site link bridging can have unintended consequences when you have multiple hubs and spokes on each hub. Here, when the bridgehead servers in the Chicago site replicate with other sites, they will replicate with Seattle, New York, LA, and Miami bridgehead servers as before, but they will also replicate with the Vancouver and San Diego bridgehead servers across the site bridge from Chicago-Seattle-Vancouver and from Chicago-LA-San Diego. This means that the same replication traffic could go over the Chicago-Seattle and ChicagoLA links twice. This can happen because of the rule of three hops for optimizing replication topology.

The repeat replication over the hub links is made worse as additional spokes are added. Consider Figure 35-14. Here, the LA hub has connections to sites in Sacramento, San Diego, and San Francisco. As a result of site link bridging, the same replication traffic could go over the Chicago-LA links four times. This happens because of the rule of three hops for optimizing replication topology.

Figure 35-14. A site design with multiple spokes at hubs.

The solution to the problem of repeat replication traffic is to disable automatic site bridging. Unfortunately, the automatic bridging configuration is all or nothing. This means that if you disable automatic site link bridging and still want some site links to be bridged, you will need to configure those bridges manually. You can enable, disable, and manually configure site link bridges as discussed in the section entitled "Configuring Site Link Bridges".

When you are finished configuring site links, you should plan the placement of servers in the sites. Think about which types of domain controllers and how many of each will be located in a site. Answer the following questions:

Think about which Active Directory partitions will be replicated between the sites as a result of the domain controller placement, and about any additional partitions that may need to be replicated to a site. Answer the following questions:

By answering all these questions, you will know what servers will be placed in each site as well as what information will be replicated between sites. Don't forget about dependent services for Active Directory. At a minimum, each site should have at least one domain controller, a global catalog, and DNS. This configuration allows intrasite replication to occur without having to go across site links for dependent services. To improve the user experience, keep in mind the following facts: