5. Site Links
The KCC assumes that within a site, all domain controllers can
reach each other. It builds an intrasite replication topology that is agnostic to the underlying network
connectivity. Between sites, however, you can represent the network
paths over which replication should occur by creating site
link objects. A site link contains two or more sites. The
Intersite Topology Generator (ISTG), a component of the
KCC, builds connection objects between servers in each of the sites to
enable intersite replication—replication between sites.
Site links are greatly misunderstood, and the important thing to
remember about a site link is that it represents an available path for
replication. A single site link does not control the network routes
that are used. When you create a site link and add sites to it, you
are telling Active Directory that it can replicate between any of the
sites associated with the site link. The ISTG creates connection
objects, and those objects determine the actual path of replication.
Although the replication topology built by the ISTG effectively
replicates Active Directory, it might not be efficient, given your
network topology.
An example illustrates this concept: When you create a forest,
one site link object is created—DEFAULTIPSITELINK. By default, each
new site that you add is associated with the DEFAULTIPSITELINK.
Consider an organization with a data center at the headquarters and
three branch offices. The three branch offices are each connected to
the data center with a dedicated link. You create sites for each
branch office, Seattle (SEA), Amsterdam (AMS), and Beijing (PEK). The
network and site topology is shown in Figure 2. The lightning
bolts indicate physical connectivity between the sites.
Because all four sites are on the same site link, you are
instructing Active Directory that all four sites can replicate with
each other. That means it is possible that Seattle will replicate
changes from Amsterdam, Amsterdam will replicate changes from Beijing,
and Beijing will replicate changes from Headquarters, which in turn
replicates changes from Seattle. In several of these replication
paths, the replication traffic on the network flows from one branch
through the headquarters on its way to another branch. With a single
site link, you have not created a hub-and-spoke replication topology, even though your network topology is
hub-and-spoke.
Therefore, it is recommended that you manually create site links that reflect your physical network topology.
Continuing the preceding example, you would create three site
links:
-
HQ-AMS, including the Headquarters and Amsterdam
sites
-
HQ-SEA, including the Headquarters and Seattle sites
-
HQ-PEK, including the Headquarters and Beijing sites
You would then delete the DEFAULTIPSITELINK. The resulting
topology is shown in Figure 3.
The four Active Directory sites shown in Figure 3 (HEADQUARTERS,
SEA, PEK, and AMS) are logical objects that represent portions of the
network with strong connectivity. The lightning bolts represent
physical connectivity between sites. Site links—for example,
HQ-AMS—are logical objects that represent a potential path for
replication between sites.
After you create site links, the ISTG uses the topology to build
an intersite replication topology connecting each site.
Connection objects are built to configure the intersite replication
paths. These connection objects are created automatically, and
although you can create connection objects manually, there are few
scenarios that require manually creating intersite connection objects.
Replication Transport Protocols
You’ll notice in the Active Directory Sites And Services
snap-in that site links are contained within a container named IP
that itself is inside the Inter-Site Transports container. Changes are
replicated between domain controllers, using one of two
protocols:
-
Directory Service Remote Procedure
Call (DS-RPC) DS-RPC appears in the Active Directory Sites And
Services snap-in as IP. IP is used for all intrasite replication
and is the default, and preferred, protocol for intersite
replication.
-
Inter-Site Messaging—Simple Mail
Transport Protocol (ISM-SMTP) Also known simply as SMTP, this protocol is used
only when network connections between sites are unreliable or
are not always available.
In general, you can assume you will use IP for all intersite
replication. Very few organizations use SMTP for replication because
of the administrative overhead required to configure and manage a
certificate authority (CA) and because SMTP replication is not
supported for the domain naming context, meaning that if a site uses
SMTP to replicate to the rest of the enterprise, that site must be
its own domain.
Tip
EXAM TIP
Although, in the production environment, you are highly
unlikely to use SMTP for replication, it is possible you will
encounter SMTP replication on the exam. The most important thing
to remember is that if two sites can replicate only with SMTP—if
IP is not an option—then those two sites must be separate domains
in the forest. SMTP cannot be used to replicate the domain naming
context.
The ISTG creates a replication topology between sites on a site link. To make
replication more efficient, one domain controller is selected as the
bridgehead server. The bridgehead server is
responsible for all replication into and out of the site for a
partition. For example, if a data center site contains five DCs, one
of the DCs will be the bridgehead server for the domain naming
context. All changes made to the domain partition within the data
center replicate to all DCs in the site. When the changes reach the
bridgehead server, those changes are replicated to bridgehead servers in branch offices, which in turn
replicate the changes to DCs in their sites. Similarly, any changes to
the domain naming context in branch offices are replicated from the
branches’ bridgehead servers to the bridgehead server in the data
center, which in turn replicates the changes to other DCs in the data
center. Figure 4
illustrates intrasite replication within two sites and the intersite
replication using connection objects between the bridgehead servers in
the sites.
To summarize, the bridgehead server is the server responsible
for replicating changes to a partition from other bridgehead servers
in other sites. It is also polled by bridgehead servers in other sites
to determine when it has changes that they should replicate.
Bridgehead servers are selected automatically, and the
ISTG creates the intersite replication topology to ensure that changes
are replicated effectively between bridgeheads sharing a site link.
Bridgeheads are selected per partition, so it is possible that one DC
in a site might be the bridgehead server for the schema and another
might be the bridgehead server for the configuration. However, you
will usually find that one domain controller is the bridgehead server
for all partitions in a site unless there are domain controllers from
other domains or application directory partitions, in which case
bridgeheads will be chosen for those partitions.
Preferred Bridgehead Servers
You can also designate one or more preferred
bridgehead servers.
To designate a domain controller as a preferred bridgehead
server:
-
Open the properties of the server object in the Active
Directory Sites And Services snap-in.
-
Select the transport protocol, which is almost always IP,
and then click Add.
You can configure more than one preferred bridgehead server
for a site, but only one will be selected and used as the
bridgehead. If that bridgehead fails, one of the other preferred
bridgehead servers will be used.
It’s important to understand that if you have specified one or
more bridgehead servers and none of the bridgeheads is available, no
other server is automatically selected, and replication does not
occur for the site even if there are servers that could act as
bridgehead servers. In an ideal world, you should not configure
preferred bridgehead servers. However, performance
considerations might suggest that you assign the bridgehead server
role to domain controllers with greater system resources. Firewall
considerations might also require that you assign a single server to
act as a bridgehead instead of allowing Active Directory to select
and possibly reassign bridgehead servers over time.
