Windows Server 2008 R2 Unleashed (48 page)
Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
9. Select the appropriate time for replication to occur.
10. Click OK twice to save all settings to the site link.
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.
ptg
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.
Understanding Active Directory Sites
205
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, administra-
tors can “shape” the flow of traffic between and among sites. Figure 7.5 illustrates a
sample AD site structure that utilizes different costs on specific site links.
DC
7
Sapporo
ptg
7
DC
DC
Morloka
5
DC
DC
Sendai
7
15
DC
DC
DC
5
DC
Tokyo
5
DC
DC
Osaka
3
DC
DC
DC
Fukuoka
FIGURE 7.5
Understanding site costs.
206
CHAPTER 7
Active Directory Infrastructure
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\
ptg
server you want to establish as a bridgehead server.
3. Right-click
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 bridge-
heads 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 bridge-
head 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 oper-
ating 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
Planning Replication Topology
207
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.
Network traffic patterns are an important consideration when implementing AD DS, and a
firm understanding of the “pipes” that exist in an organization’s network is warranted. If
all remote sites are connected by T1 lines, for example, there will be fewer replication
concerns than if network traffic passes through a slower link.
With this point in mind, mapping out network topology is one of the first steps in creat-
ing a functional and reliable replication topology.
Mapping Site Design into Network Design
Site structure in Windows Server 2008 R2 is completely independent from the domain,
tree, and forest structure of the directory. This type of flexibility allows domain designers
to structure domain environments without needing to consider replication constraints.
ptg
Consequently, domain designers can focus solely on the replication topology when design-
ing their site structure, enabling them to create the most efficient replication environment.
Essentially, a site diagram in Windows Server 2008 R2 should look similar to a WAN
diagram of your environment. In fact, site topology in AD DS was specifically designed to
be flexible and adhere to normal WAN traffic and layout. This concept helps to define
7
where to create sites, site links, and preferred site link bridgeheads.
Figure 7.6 illustrates how a sample site structure in AD overlays easily onto a WAN
diagram from the same organization. Consequently, it is a very good idea to involve the
WAN personnel in a site design discussion. Because WAN environments change in struc-
ture as well, WAN personnel will subsequently be more inclined to inform the operating
system group of changes that could affect the efficiency of your site design as well.
Establishing Sites
Each “island” of high connectivity should normally be configured as a site. This not only
assists in domain controller replication, but also ensures that clients receive the closest
domain controller and global catalog server to themselves.
NOTE
If your DNS records are inaccurate for a site, clients could be potentially redirected to a
domain controller or global catalog server other than the one that is closest to them.
Consequently, it is important to ensure that all your sites listed in DNS contain the
appropriate server host records. This concept is explained more thoroughly in Chapter
10, “Domain Name System and IPv6.”
208
CHAPTER 7
Active Directory Infrastructure
Montreal
Site
Portland
Site
Montreal
Site
Portland
Network
Boston
Chicago
Site
Site
Boston
Chicago
Network
Network
New York
Site
New York
Network
ptg
Washington
Dallas
Site
Site
Washington
Dallas
Network
Network
FIGURE 7.6
Site and WAN structure.
Choosing Between One Site or Many Sites
In some cases, multiple LAN segments might be consolidated into a single site, given that
the appropriate bandwidth exists between the two segments. This might be the case for a
corporate campus, with various buildings that are associated with LAN “islands” but that
are all joined by high-speed backbones. However, there might also be reasons to break
these segments into sites themselves. Before the decision is made to consolidate sites or
separate into individual sites, all factors must be taken into account.
Single-site design is simpler to configure and administer, but also introduces an increase in
intersegment traffic, as all computers in all buildings must traverse the network for
domain authentication, lookups, frequent replication, and so on.
A multiple-site design addresses the problems of the intersegment traffic because all local
client requests are handled by domain controllers or global catalog servers locally.
Planning Replication Topology
209
However, the complexity of the environment is more significant and the resources
required increase.
NOTE
It is no longer a firm recommendation that all sites contain at least one global catalog
domain controller server. The introduction of the universal group caching capability
and Read-Only Domain Controllers (RODCs) can reduce the number of global catalog
servers in your environment and significantly reduce the amount of replication activity
that occurs. This recommendation still stands, however, for sites with a local
Exchange server, as one or more local full global catalog servers are still critical for
these environments.
The requirements of an organization with the resources available should be mapped to
determine the best-case scenario for site design. Proper site layout helps to logically organize
traffic, increase network responsiveness, and introduce redundancy into an environment.
Associating Subnets with Sites
It is critical to establish the physical boundaries of your AD sites because this information
ptg
utilizes the most efficient logon and directory requests from clients and helps to deter-
mine where new domain controllers should be located. Multiple subnets can be associated
with a single site, and all potential subnets within an organization should be associated
with their respective sites to realize the greatest benefit.
Determining Site Links and Site Link Costs
7
As previously mentioned, site links should normally be designed to overlay the WAN link
structure of an organization. If multiple WAN routes exist throughout an organization, it
is wise to establish multiple site links to correspond with those routes.
Organizations with a meshed WAN topology need not establish site links for every
connection, however. Logically consolidating the potential traffic routes into a series of
pathways is a more effective approach and helps to make your environment easier to
