Active Directory Sites

The basic unit of Active Directory replication is known as the site. Not to be confused with physical sites or Exchange 5.5 sites, the AD site is simply a group of highly connected domain controllers. Each site is established to more effectively replicate directory information across the network. In a nutshell, domain controllers within a single site will, by default, replicate more often that those that exist in other sites. The concept of the site constitutes the centerpiece of replication design in Active Directory.

Windows Server 2003 Site Improvements

Specific functionality that affects sites has evolved since the days of Windows 2000. Windows Server 2003 introduces numerous replication enhancements that directly affect the functionality of sites and allow for greater design flexibility in regard to site design:

• GC universal group membership caching

• Media-based domain controller creation

• Linked-value replication

• ISTG algorithm improvements

• No global catalog full synchronization with schema changes

• Ability to disable replication packet compression

• Lingering object detection

These concepts are elaborated more fully in later sections of this chapter.

Associating Subnets with Sites

In most cases, a separate instance of a site in Active Directory physically resides in a separate subnet for other sites. This idea stems from the fact that the site topology most often mimics, or should mimic, the physical network infrastructure of an environment.

In Active Directory, sites are associated with their respective subnets to allow for the intelligent assignment of users to their respective domain controllers. For example, consider the design shown in Figure 7.6.

Figure 7.6. Sample client site assignment.

Server1 and Server2, both members of Site1, are both physically members of the 10.1.1.x subnet. Server3 and Server4 are both members of the 10.1.2.x subnet. Client1, which has a physical IP address of 10.1.2.145, will be automatically assigned Server3 and Server4 as its default domain controllers by Active Directory because the subnets have been assigned to the sites in advance. Making this type of assignment is fairly straightforward. The following procedure details how to associate a subnet with a site:

1.	Open Active Directory Sites and Services.
2.	Drill down to Sites\Subnets.
3.	Right-click Subnets and choose New Subnet.
4.	Enter the network portion of the IP range that the site will encompass. In our example, we use the 10.1.2.0 subnet with a Class C (255.255.255.0) subnet mask.
5.	Select a site to associate with the subnet. In the example shown in Figure 7.7, Site2 was selected. Figure 7.7. Associating a subnet with a site.
6.	Click OK.

Note

Automatic DC site assignment is built in with Windows 2000 or higher clients. Down-level clients, however, require the use of the Active Directory Client component to utilize this functionality. If the AD Client is not installed, Windows 9x or NT clients may be inadvertently directed to domain controllers in far-away sites.

In addition, it's becoming increasingly important to ensure that clients can properly look up their AD sites because many applications, such as SMS 2003, are site-aware and distribute services based on the location of the client as defined in AD. This makes it critical to include subnet information in AD Sites and Services for all available subnets within an organization.

Using Site Links

By default, the creation of two sites in Active Directory does not automatically create a connection linking the two sites. This type of functionality must be manually created, in the form of a site link.

A site link is essentially a type of connection that joins together two sites and allows for replication traffic to flow from one site to another. Multiple site links can be set up and should normally follow the WAN lines that your organization follows. Multiple site links also assure redundancy so that if one link goes down, replication traffic will follow the second link.

Creation of site links is another straightforward process, although you should establish in advance which type of traffic will be utilized by your site link: SMTP or IP (refer to the section "SMTP Versus IP Replication").

Site link replication schedules can be modified to fit the existing requirements of your organization. If, for example, the WAN link is saturated during the day, a schedule can be established to replicate information at night. This functionality allows you to easily adjust site links to the needs of any WAN link.

With the assumption that a default IP site link is required, the following steps will create a simple site link to connect Site1 to Site2. In addition, the replication schedule will be modified to allow replication traffic to occur only from 6 p.m. to 6 a.m. at one-hour intervals:

1.	Open Active Directory Sites and Services.
2.	Drill down to Sites\Inter-Site Transports\IP.
3.	Right-click IP and choose New Site Link to open a properties page similar to the one in Figure 7.8. Figure 7.8. Site link creation properties page.
4.	Give a name to the subnet that will easily identify what it is. In our example, we named it Site1 - Site2 SL.
5.	Ensure that the sites you want to connect are located in the Sites in This Site Link box.
6.	Click OK to create the site link.
7.	Right-click the newly created site link and choose Properties.
8.	Click Change Schedule.
9.	Select the appropriate time for replication to occur. In our case, we made replication unavailable from 6 a.m. to 6 p.m. by highlighting the desired hours and choosing the Replication Not Available button, as shown in Figure 7.9. Figure 7.9. Replication scheduling.
10.	Click OK twice to save all settings to the site link.

Site Link Bridging

By default, all site links are bridged, which means that all domain controllers in every site can communicate directly with any other domain controller through any of a series of site links. Such a bridge has the advantage of introducing redundancy into an environment; for example, if Site A has a link with Site B, and Site B is linked to Site C, servers in Site C can communicate directly with Site A.

On some occasions, it is preferable to turn off this type of replication. For example, your organization may require that certain domain controllers never communicate directly with other domain controllers. In this case, site bridging can be turned off through the following procedure:

1.	Open Active Directory Sites and Services.
2.	Navigate to Sites\Inter-Site Transports\IP (or SMTP, if appropriate).
3.	Right-click the IP (or SMTP) folder and choose Properties.
4.	Uncheck the Bridge All Site Links box, as shown in Figure 7.10. Figure 7.10. Turning off site link bridging.
5.	Click OK to save the changes.

Note

Turning off site link bridging will effectively make your domain controller replication dependent on the explicit site links you have established.

The Knowledge Consistency Checker and the Intersite Topology Generator

Every domain controller contains a role called the Knowledge Consistency Checker (KCC) that automatically generates the most efficient replication topology at a default interval of every 15 minutes. The KCC creates connection objects that link domain controllers into a common replication topology. The KCC has two components: an intrasite KCC, which deals with replication within the site, and an intersite topology generator (ISTG), which establishes connection objects between sites.

The Windows Server 2003 Replication team vastly improved the algorithm used by the ISTG, which resulted in a several-fold increase in the number of sites that can effectively be managed in Active Directory. The number of sites that can be effectively managed in Active Directory is now 5,000.

Note

Because all domain controllers in a forest must agree on the ISTG algorithm, the improvements to the ISTG are not realized until the schema is updated and all domain controllers are upgraded to Windows Server 2003 (either pre-R2 or R2 levels) and the forest and domain functionality levels are raised to Windows Server 2003 level.

Detailing Site Cost

An AD replication mechanism allows designers and administrators to establish preferred routes for replication to follow. This mechanism is known as site cost, and every site link in Active Directory has a cost associated with it. The concept of site cost, which may be familiar to many administrators, follows a fairly simple formula. The lowest cost site link becomes the preferred site link for communications to a site. Higher cost site links are established mainly for redundancy or to reduce traffic on a specific segment. Figure 7.11 illustrates a sample AD site structure that utilizes different costs on specific site links.

Figure 7.11. Site costs.

To use the example illustrated in Figure 7.11, most traffic between the Sendai and Fukuoka sites follows the Sendai-Tokyo site link because the cost of that site link is 15. However, if there is a problem with that connection or it is saturated, replication traffic will be routed through the Sendai-Morioka and then through the Morioka-Tokyo and Tokyo-Fukuoka site links because the total cost (all site link costs added together) for this route is 17. This type of situation illustrates the advantage of utilizing multiple routes in an Active Directory site topology.

Preferred Site Link Bridgeheads

Often, it becomes necessary to segregate all outgoing or incoming intersite traffic to a single domain controller, thus controlling the flow of traffic and offloading the special processor requirements that are required for this functionality. This concept gave rise to preferred site link bridgeheads, domain controllers in a site that are specifically assigned to be the end or starting point of a site link. The preferred bridgehead servers will subsequently be the handler for all traffic for that specific site link.

Multiple site link bridgeheads can be easily defined in Active Directory. The following example illustrates how this is accomplished. In these steps, Server2 is added as a preferred site link bridgehead for the site link named Site1 - Site2 SL:

1.	Open Active Directory Sites and Services.
2.	Drill down to Sites\<Sitename>\Servers\<Servername>, where Servername is the server you want to establish as a bridgehead server.
3.	Right-click <Servername> and choose Properties to open a properties page similar to Figure 7.12. Figure 7.12. Defining a preferred bridgehead server.
4.	Select the transport for which this server will be made a bridgehead and choose Add, as illustrated in Figure 7.12.
5.	Click OK to save the settings.

Establishing preferred bridgehead servers can have many advantages. Domain controllers with weaker processors can be excluded from this group, as can domain controllers with Operations Master (OM) roles, especially that of the PDC Emulator, which should never be a bridgehead server, if avoidable. It is important, however, to make sure that at least one server in a site from each naming context is established as a bridgehead server. For example, if you have two domains that occupy space in the same site, you should ensure that at least one domain controller from each domain is established as a preferred bridgehead server to ensure proper domain replication.