Under normal conditions, replication occurs on an as-needed basis. In some organizations, though, random replication is unacceptable because of bandwidth limitations, so it's necessary to implement a replication schedule. This requires you to divide the domain into sites and then schedule replication between the sites.

DESIGNING A SITE STRUCTURE

Microsoft recommends dividing your organization into sites in a way that mimics the subnetting scheme. The problem is that not everyone has his or her network subnetted. The only way to get the performance gains associated with site segregation is to ensure that your network is effectively divided into subnets.

SUBNETS AND SITES

While subnets are a mechanism used to divide the network into smaller components, sites are an Active Directory-level mechanism used to split a domain into smaller pieces. Sites do two main things for Windows. First, they allow you to schedule replication rather than having it occur on an as-needed basis. Second, they condense replication traffic into single sets.

To see why scheduling replication-related traffic is important, consider this: If someone at a satellite office were to make an update to Active Directory, the update would most likely be related to an Active Directory object that applies directly to that office, such as a password change for a user in that office.

If a user were to change his or her password, it would be necessary for the password change to eventually be replicated to every domain controller in the domain. However, it would be even more important for the change to be quickly replicated to the domain controllers that are most likely to authenticate the user's request.

Sites make this selective updating possible. For example, suppose you established a site replication schedule of 15 minutes. If a user in one site were to change his or her password, then the domain controllers in the user's local site would be updated immediately. But it could be up to 15 minutes before domain controllers in remote sites were updated. During this time, the site's bridgehead server would collect domain controller updates and transmit them all at once at the end of the replication cycle.

If the remote office had five domain controllers, then five sets of replication traffic would flow to the remote office for every Active Directory update. When sites are used, a single set of replication traffic flows between the two sites. Rather than trying to update every single domain controller, the local site simply sends the updates to the remote site's bridgehead server, which then distributes the traffic to the domain controllers within the remote site.

SETTING SITE REPLICATION FREQUENCIES

A site connector is a logical connector that tells the replication-related traffic how to flow between the two sites. You must have at least one site connector connecting any two sites, although it is possible to use redundant or transitive site connectors. For example, if you had three sites, A, B, and C, at a minimum, you'd need two site connectors, AB and BC. However, you could have site connectors for AB, AC, and BC.

Although there are a lot of configuration options related to site connectors, the two most important are the cost and the replication frequency. The cost is simply a numeric value that Windows uses to determine which site connector to use. If a site had two site connectors to another site, and one had a cost of 1 and the other had a cost of 2, the connector with the lowest cost would always be used. The higher cost connection would be used only if the lower cost connection was unavailable.

The replication frequency parameter controls the amount of time between replication updates. The minimum value is 15 minutes, and the maximum is 10,080 minutes, or one week.

There's really no right or wrong way to set the replication frequency. The main point to remember is that longer replication frequencies mean better performance but fewer updates. Lower replication frequencies mean a more consistent Active Directory database, but they also mean you will be sacrificing some bandwidth to get those frequent updates. On smaller networks, 15-minute replication cycles are acceptable. On larger networks, use 30-minute replication cycles. Of course, these are just guidelines. In the real world, you must look at a company's operational needs and use those to determine the ideal replication frequency.