Defining 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 might 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 check box.
|
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.
Understanding the Knowledge Consistency Checker (KCC) and the Intersite Topology Generator (ISTG)
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.
In Windows Server 2003, the
Active Directory design 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 AD DS. The number of sites that can
be effectively managed in AD DS now exceeds 5,000, particularly if
64-bit domain controllers are installed.
Note
Because all domain
controllers in a forest must agree on the ISTG algorithm, the
improvements to the ISTG are not realized until the forest is in Windows
Server 2003 or higher forest functional 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 AD DS has a cost associated
with it. The concept of site cost, which might 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. In this way, administrators can
“shape” the flow of traffic between and among sites. Figure 4 illustrates a sample AD site structure that utilizes different costs on specific site links.
In
this example, traffic between the Morioka and Fukuoka sites follow the
two Tokyo links for a total cost of 10. However, if there is a problem
with the connection between Morioka and Tokyo or it is saturated,
replication traffic will be routed through the Sendai-Morioka and then
through the Sendai-Tokyo and Tokyo-Fukuoka site links because the total
cost (all site link costs added together) for this route is 27. This
type of situation illustrates the advantage of utilizing multiple routes
in an AD DS site topology.
Utilizing Preferred Bridgehead Servers
Often, it becomes
necessary to segregate all outgoing or incoming intersite traffic to a
single domain controller, thus controlling the flow of traffic and
off-loading the special processor requirements that are required for
this functionality. This concept gave rise to preferred bridgehead
servers, domain controllers that are specifically assigned as a
preferred bridgehead server for a specific transport (IP or SMTP). The
preferred bridgehead servers will subsequently be the handler for all
intersite traffic for that specific transport.
Bridgeheads can be
easily defined in AD DS. The following example illustrates how this is
accomplished. In these steps, Server2 is added as a preferred site link
bridgehead for the IP transport:
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.
|
4. | Select the IP transport and choose Add.
|
5. | Click OK to save the settings.
|
Preferred bridgehead
servers bring with them both advantages and disadvantages. The advantage
of designating a preferred bridgehead server is that in an environment
where domain controllers with weaker processors need to be excluded as
designated site bridgeheads or when a domain controller holds an
Operations Master (OM) role, especially that of the PDC emulator, having
a designated preferred bridgehead server can allow for controlled
communications to a specific bridgehead server.
However, the problem with
selecting a preferred bridgehead server is that they can reduce the
inherent redundancy of AD DS by preventing the Knowledge Consistency
Checker (KCC) from failing over to other domain controllers in the same
site if the preferred bridgehead server goes offline. As a result, when
bridgeheads are required, multiple bridgehead servers should be used
within each site.
Typically,
organizations choose to not implement preferred bridgehead servers, and
only implement them when they have a specific need to designate a server
in a site as a preferred bridgehead server.
Deploying AD DS Domain Controllers on Server Core
Windows Server 2008 R2 has
an installation option called Server Core that allows the operating
system to be deployed with only those services that are absolutely
required for the role that the server holds. For domain controllers,
this includes only those services that are needed
for a DC to operate. Server Core is configured to run at a command
prompt, without a graphical user interface (GUI) to further reduce the
security profile of the box.
Deploying dedicated
domain controllers using Server Core is ideal in many situations where
security is a strong requirement. By doing so, only the necessary
functionality is deployed, and no auxiliary services are required.
