9.2 Designing Sites and Links for Replication

There is only one really important point, which is the overriding factor when designing a replication strategy for your network: how much traffic and over what period will you be replicating across the network? However, replication isn't the only reason for creating sites. Sites also need to exist to group sets of machines together for ease of locating data, finding the nearest DC to authenticate with, or finding the nearest DFS share mount point.

9.2.1 Step 1—Gather Background Data for Your Network

Before you sit down to design your site and WAN topology, you need to obtain the map of your existing network infrastructure. This map should contain all physical locations where your company has computers, along with every link between those locations. The speed and reliability of each link should be noted.

If you have an existing IP infrastructure, write down all the subnets that correspond to the sites you have noted.

9.2.2 Step 2—Design the Sites

From the network diagram, you need to draw your site structure and name each site, using a one-to-one mapping from the network diagram as your starting point. If you have 50 physical WAN locations, you have 50 sites. If only 30 of these will be used for Active Directory, you may not see a need to include the entire set of sites in Active Directory. If you do include the entire set, however, it is much easier to visualize your entire network and add clients or servers to those locations later.

When drawing Active Directory networks, sites normally are represented by ovals.

Remember that a site is a well-connected set of subnets (well-connected tends to mean about 10 Mbps LAN speed). A site does not have to have a server in it; it can be composed entirely of clients. If you have two buildings—or an entire campus—that is connected over 10/100 Mbps links, your entire location is a single site.

This is not a hard and fast rule. By the normal rules, two locations connected over a 2 Mbps link represent two distinct sites. You can, however, group networks together into single sites if you want to. You have to appreciate that there will be more replication than if you had created two sites and a site link, because DCs in both physical locations will maintain the intrasite replication ring topology. If you had created two sites and a site link, only two bridgehead servers would replicate with each other.

We've also successfully used a single site to represent two networks, one with clients and one with servers, separated by a 2 Mbps link. The clients at the end of the 2 Mbps link successfully authenticated quickly and downloaded profiles from a server at the other end of the other link. If we'd used two sites, we would have had to create a site link between them, but the clients still would have had to authenticate across the link anyway.

To summarize, we would suggest that, by default, you create one site per 10 Mbps or higher location, unless you have an overriding reason not to do so.

9.2.3 Step 3—Design the Domain Controller Locations

Placing of DCs is fairly easy, but the number of DCs to use is a different matter entirely.

9.2.3.1 Where to put DCs

Each workstation in a domain exists in a single site that it knows about. When a user tries to log on to the domain at that workstation, the workstation authenticates to a DC from the local site, which it originally locates via a DNS query. If no DC is available in the local site, the workstation finds a remote site, and by a process of negotiation with a DC in that site, either authenticates with that DC or is redirected to a more local DC.

This consideration governs the placement of DCs. You should place one DC for authentication purposes per domain in all sites that meet any of the following criteria:

• The site has links that are not fast enough for logon purposes to a particular domain.

• The site has links that may be fast enough for logon, but you do not wish to authenticate across them for a particular domain.

• Under Windows 2000, if you made heavy use of universal groups, you needed to place a server at a site if you did not want to impact logons due to a network failure. But with Windows Server 2003 Active Directory, you can enable universal group membership caching (with the Sites and Services snap-in) so that this is no longer a requirement.

The first and second points also need to be considered in light of the number of users and workstations at the sites. If a branch office has a 64 Kbps link, would you want users to log on using a centrally located DC at the other end of that link? If you had 10 users in that office, it may be no problem. If you had 20 users, you may not be so sure. If you had 50 it would be impossible, so you should put in a DC at that site.

9.2.3.2 How many DCs to have

Deciding how many DCs to create is never easy, as Windows NT administrators well know. The problem is that it depends on the power of the individual server and what else the server is doing at the time as much as it depends on the operating system's ability to authenticate users. If you have an Intel server that's already serving 500 heavy users and is close to its load limit, could it authenticate 100 additional users quickly enough at the same time? Powerful servers can authenticate hundreds of users simultaneously, but even these servers will balk if they are already heavily loaded.

We can't answer this question for you. The only way to decide is to consider how many users will need to use DCs for authentication purposes and what pattern of logons occur throughout the day at your organization. That way, you should be able to judge for yourself how many DCs you may need for authentication purposes.

9.2.3.3 Reasons for putting a server in more than one site

By default, any server that you install or bring into a domain will belong to one site only. However, there can be instances in which you may want to configure a server to belong to multiple sites. For example, you might want to make sure that workstations from a number of sites all authenticate using one DC.

Here's an example: imagine five sites (Cairo, Delhi, Bangkok, Sydney, and Rio de Janeiro), each representing a 20-user branch office of a large centralized company. Each site has a 64 Kbps link back to the main office in London. You've decided that each site can authenticate down the slow link to a central server, even though all 20 users will log on at 9:00 each morning, because time zone differences effectively stagger the load. In addition, to make sure that these clients do not authenticate with any other servers, you have to provide them with their own central server that is also a member of all the remote sites. That way, when the clients attempt to log on, they will do so down the slow link, but only to that one server.

While sites are used for replication, for clients to find resources, and to cut down on traffic on intersite connections, modifying the site membership can cause performance problems. However, in this case we understand the consequences, and this looks like a good decision.

Configuring a server to have multiple site membership is fairly straightforward. First, manually create the sites that the server is to be a member of if they do not already exist. Then edit the registry on the server that is to have multiple site membership and add a REG_MULTI_SZ value called SiteCoverage to the HKLM\SYSTEM\CurrentControlSet\ServicesNetlogon\Parameters subkey. Add the names of the sites to this value. If you're using RegEdit or RegEdt32, use Shift-Enter to add the data for multiple lines.

9.2.4 Step 4—Plan Intrasite Replication

This is a short step. Your only requirement is to set the schedules that the replication cycles use. As for the connection objects themselves, if you don't specifically need to change the intrasite replication topologies that the KCC sets up, don't. Leave the KCC to do its stuff by itself; it takes care of things pretty well. You could remove the default links and make a long linked list of replication partners—A to B to C to D to E—rather than a ring if you wanted to, but you have to have a very good reason to do so.

If you do want to manipulate the existing setup of replication between DCs, you'll have to stop the KCC service generating the intrasite topology for that site.

You can turn off intrasite or intersite topology generation by the KCC by using the Sites and Services snap-in to look at the properties of the specific NTDS Site Settings object that you are interested in.

9.2.5 Step 5—Decide How You Will Use the KCC to Your Advantage

There are really three ways to use the KCC to your advantage over intersite links:

• Manually create all the connection objects and turn off the KCC for intersite replication. This isn't something we recommend unless you know exactly what you're doing.

• Let the KCC generate your entire topology for you automatically. This is the default and what Microsoft recommends as standard. You still need to create all site links manually, but if you leave site link transitiveness on by default, the KCC will not need you to create extra site links to replicate data via sites that do not have the relevant DCs. Site link bridges are not used in this scenario.

You can define multiple site links between two distinct sets of bridgehead servers at separate sites if you wish, i.e., DC1 in Site A connects to DC3 in Site B and DC2 in Site A connects to DC4 in Site B. This will help in case one of the servers at one end of a single site link goes down, as this means that you will lose only one site link and not the intersite connectivity.

• A mixture of the two can be had by forcing the KCC to make decisions based on certain key information that you provide. For example, if you make sure that you leave site links nontransitive, the KCC will be able to replicate only across site links that do exist. You then can make use of site link bridges to force the KCC to use certain routes for replication.

If you have many connections that need to be created but don't want to use the KCC, you can use the KCC to start with, allow it to create its default objects, turn it off, and modify the objects to whatever you choose. If you have 500 links, for example, but want to manipulate only one, this is the best way of doing things.

You can leave this step until after you have designed the site links (Steps 6, 7, and 8) if you are not sure what to do. The example design for PetroCorp shows later why this is useful.

9.2.6 Step 6—Create Site Links for Low-Cost, Well-Connected Links

Now that you have all the sites down on paper, you need to think about the links. In this step we identify those sites that are interconnected with what can be considered very fast links or backbones.

Site links should be created along 2 Mbps or faster connections between distinct sites. For each link, you need to choose an appropriate name, cost, and transport. The name should be distinct and immediately conjure up what the link represents. The transport for low-cost links is normally DS-RPC; such a high-capacity network can cope with traffic of this nature. However, if you only want to use email across a link, make the transport ISM-SMTP. If you set up both for some reason, you normally would set a slightly higher cost for the SMTP connectors than you would for standard DS-RPC-based replication.

When choosing costs, the values you choose depend entirely on the different intersite link speeds that you have in your organization. If you have only 64 Kbps and 1 Mbps^[1] links between sites, you really need only 2 values. If you use both transport types, you'll need 4. However, if your sites have many different types of connection, such as 10 Mbps, T3, T2, T1, 256 Kbps, and 64 Kbps, you'll need many more. The values you use should represent in your own mind the difference in cost for using a route. The key to using costs is to realize that everything is relative. After all, if you have two routes to a site and they have costs of 1 and 2, respectively, 2 seems twice as slow as 1. That isn't true; it is just a slower link—not twice as slow. Because the numbers are so close together, there is almost nothing between these values. However, the difference between 10 and 20 is more significant. When determining values, we suggest that as a starting point, use 1 through 10 for low-cost fast links, 11 through 20 for medium-cost links, and 21 and above for higher-cost routes.

^[1] In the U.K., 64 Kbps links are known as kilostream links and 1 Mbps links are known as megastream links.

Create all the site links along fast-interconnected links between sites.

9.2.7 Step 7—Create Site Links for Medium-Cost Links

Having identified the fastest links and created site links for them, you now need to create any links that are interconnected with a similar transport at medium cost. These are sites such as those connected via MANs with T1 connections, interconnected via frame relay clouds, or entirely connected together. Create these sites now, and remember to use a slightly slower value for any SMTP connectors.

9.2.8 Step 8—Create Site Links for High-Cost Links

Finally, you have the WAN connections that are high cost due to their slow speed or unreliability. You now need to create those site links and allocate a name, transport, and cost as before. For unreliable links, consider using an SMTP connector with a certificate to encrypt the data. This will ensure that as soon as a link is available for email, your updates will propagate backward and forward as required. For more reliable links, use the standard DS-RPC connector; later in Step 10 you can configure the replication times to be suitable to that link.

9.2.9 Step 9—Create Site Link Bridges

If you chose the third option in Step 5 and turned off site link transitiveness, you now need to create site link bridges or more site links to satisfy your desire to force the KCC to create its topology along certain paths.

9.2.10 Step 10—Design the Replication Schedule

Now sit down with your entire map and identify in which time windows you will allow replication along the various links. Low-cost links may allow traffic all day. Medium-cost links may allow traffic from late afternoon until early morning, and high-cost links may allow replication windows only at very specific times. It all depends on you. In my mind, there is certainly a split between the high-, medium-, and low-cost link replication schedules that you create. Remember that you must have a common window for replication across all routes.