Designing the Site Topology

navybeansvietnameseΔίκτυα και Επικοινωνίες

24 Οκτ 2013 (πριν από 4 χρόνια και 16 μέρες)

237 εμφανίσεις

C H A P T E R 3

An Active Directory
®

directory service site topology is a logical representation of your physical network.
Designing an Active Directory site topology involves planning for domain controller placement and
designing s
ites, subnets, site links, and site link bridges to ensure efficient routing of query and replication
traffic.

In This Chapter

Overview of Designing a Site Topology
................................
................................
................................
.......
138

Collecting Network Information
................................
................................
................................
....................
148

Planning Domain Controller Placement
................................
................................
................................
.....
152

Creating a
Site Design

................................
................................
................................
................................
.....
165

Creating a Site Link Design
................................
................................
................................
............................
168

Creating a Site Link Br idge Design
................................
................................
................................
..............
178

Additional Resources

................................
................................
................................
................................
.......
182

Related Information



For more information about designing the Active Directory logical structure and the DNS
infrastructure needed to support Act
ive Directory, see “Designing the Active Directory
Logical Structure” in this book.



For more information about determining domain controller hardware requirements, see
“Planning Domain Controller Capacity” in this book.



For more information about deploying

a DNS infrastructure for name resolution on your
network, see “Deploying DNS” in
Deploying Network Services
of this kit.



For more information about Active Directory replication topology, see the
Directory
Services Guide

of the
Microsoft
®

Windows
®

Server

2
003 Resource Kit
(or see the
Directory
Services Guide

on the Web at http://www.microsoft.com/reskit).

Designing the Site
Topology


138

Chapter 3

Designing the

Site Topology



Overview of Designing a Site
Topology

Designing a site topology helps you efficiently route client queries and Active Directory replication traffic. A
we
ll
-
designed site topology helps your organization achieve the following benefits:



Minimize the cost of replicating Active Directory data.



Minimize administrative efforts that are required to maintain the site topology.



Schedule replication that enables loc
ations with slow or dial
-
up network links to replicate
Active Directory data during off
-
peak hours.



Optimize the ability of client computers to locate the nearest resources, such as domain
controllers and Distributed File System (DFS) servers, reducing net
work traffic over slow,
wide area network (WAN) links, improving logon and logoff processes, and speeding up file
download operations.

Before you begin to design your site topology, you must understand your physical network structure. In
addition, you must

first design your Active Directory logical structure, including the administrative
hierarchy, forest plan, and domain plan for each forest. You must also complete your DNS infrastructure
design for Active Directory. For more information about designing yo
ur Active Directory logical structure
and DNS infrastructure, see “Designing the Active Directory Logical Structure” in this book.

After you complete your site topology design, you must verify that your domain controllers meet the
hardware requirements for

the Microsoft
®

Windows
®

Server

2003
, Standard Edition; Windows
®

Server

2003, Enterprise Edition; and Windows
®

Server

2003, Datacenter Edition, operating systems
. You
must also determine the appropriate number of domain controllers for each domain that is
represented in each
site. For more information about determining the appropriate number of domain controllers and their
hardware requirements, see “Planning Domain Controller Capacity” in this book.


Note

For a list of job aids that are available to assis
t you in designing the site
topology, see “Additional Resources” later in this chapter.

Overview of

Design
ing a Site Topology

139



Process for Designing a Site Topology

Designing a site topology includes determining what locations require domain controllers and determining
where you need to create

sites, site links, and site link bridges. Figure

3.1 illustrates the site topology design
process.

Figure

3.
1

Designing a Site Topology


Site Topology Design Background
Information

Your site topology significantly affects the performance of your networ
k and the ability of your users to
access network resources. Before you begin to design your site topology, become familiar with the functions
for sites in Microsoft
®

Windows Server

2003, the different network topologies that organizations commonly
use, th
e role of the site topology owner, and some Active Directory replication concepts.

140

Chapter 3

Designing the

Site Topology



Functions for Sites in Windows Server

2003

Windows Server

2003 uses site information for many purposes, including routing replication, client affinity,
system volume replic
ation, DFS, and service location.

Routing replication

Active Directory uses a multimaster, store
-
and
-
forward method of replication. A domain controller
communicates directory changes to a second domain controller, which then communicates to a third, and so

on, until all domain controllers have received the change. To achieve the best balance between reducing
replication latency and reducing traffic, site topology controls Active Directory replication by distinguishing
between replication that occurs within
a site and replication that occurs between sites.

Within sites, replication is optimized for speed


data updates trigger replication and the data is sent without
the overhead required by data compression. Conversely, replication between sites is compresse
d to minimize
the cost of transmission over WAN links. When replication occurs between sites, a single domain controller
per domain at each site collects and stores the directory changes and communicates them at a scheduled time
to a domain controller in a
nother site.

Client affinity

Domain controllers use site information to inform Active Directory clients about domain controllers present
within the closest site as the client. For example, consider a client in the Seattle site that does not know its
site a
ffiliation and contacts a domain controller from the Atlanta site. Based on the IP address of the client,
the domain controller in Atlanta determines which site the client is actually from and sends the site
information back to the client. The domain contr
oller also informs the client whether the chosen domain
controller is the closest one to it. The client caches the site information provided by the domain controller in
Atlanta and queries for the site
-
specific service (SRV) resource record (a DNS resource

record used to locate
domain controllers for Active Directory) and thereby finds a domain controller within the same site.

By finding a domain controller in the same site, the client avoids communications over WAN links. If no
domain controllers are locat
ed at the client site, a domain controller that has the lowest cost connections
relative to other connected sites advertises itself (registers a site
-
specific SRV resource record in DNS) in the
site that does not have a domain controller. The domain contro
llers that are published in DNS are those from
the closest site as defined by the site topology. This process ensures that every site has a preferred domain
controller for authentication.

For more information about the process of locating a domain controll
er, see the
Directory Services Guide

of
the
Windows Server

2003 Resource Kit

(or see the
Directory Services Guide

on the Web at
http://www.microsoft.com/reskit).

Overview of

Designing a Site Topology

141



SYSVOL replication

The system volume (SYSVOL) is a collection of folders in the file system t
hat exists on each domain
controller in a domain. The SYSVOL folders provide a default Active Directory location for files that must
be replicated throughout a domain, including Group Policy objects (GPO), startup and shutdown scripts, and
logon and logoff

scripts. Windows Server

2003 uses the File Replication service (FRS) to replicate changes
made to the SYSVOL folders from one domain controller to other domain controllers. FRS replicates these
changes according to the schedule that you create during your

site topology design.

DFS

DFS uses site information to direct a client to the server that is hosting the requested data within the site. If
DFS does not find a copy of the data within the same site as the client, DFS uses the site information in
Active Di
rectory to determine which file server that has DFS shared data is closest to the client.

Service location

By publishing services such as file and print services in Active Directory, you allow Active Directory clients
to locate the requested service within

the same or nearest site. Print services use the location attribute stored
in Active Directory to let users browse for printers by location without knowing their precise location. For
information about enabling printer location tracking, see “Enable print
er location tracking” in Help and
Support Center for Windows Server

2003. For more information about designing and deploying print servers,
see “Designing and Deploying Print Servers” in
Planning Server Deployments
of this kit.

Site Topology Owner Role

The

administrator who manages the site topology is known as the site topology owner. The site topology
owner understands the conditions of the network between sites and has the authority to change settings in
Active Directory to implement changes to the site
topology. Changes to the site topology affect changes in
the replication topology. The site topology owner’s responsibilities include:



Controlling changes to the site topology if network connectivity changes.



Obtaining and maintaining information about net
work connections and routers from the
network group. The site topology owner must maintain a list of subnet addresses, subnet
masks, and the location to which each belongs. The site topology owner must also
understand any issues about network speed and cap
acity that affect site topology in order to
effectively set costs for site links.



Moving Active Directory server objects representing domain controllers between sites if a
domain controller’s IP address changes to a different subnet in a different site, or

if the
subnet itself is assigned to a different site. In either case, the site topology owner must
manually move the Active Directory server object of the domain controller to the new site.

142

Chapter 3

Designing the

Site Topolo
gy



Network Topologies

An organization’s network topology reflects i
ts business needs. In some organizations, business needs result
in users working in a few large locations that are well connected to one another. Alternatively, other
organizations have users in many small, satellite locations connected to one of a few, we
ll
-
connected hub
sites. Such network topologies usually are one of three general types: ring, hub and spoke, and complex.
These network topologies are illustrated in Figure

3.2.

Figure

3.
2

Network Topologies


Overview of

Designing a Site Topology

143



Active Directory Replication Concepts

Befor
e designing site topology, become familiar with some Active Directory replication concepts.

Connection object

A connection object is an Active Directory object that represents a replication connection from one domain
controller to another. A domain control
ler is a member of a single site and is represented in the site by a
server object in Active Directory. Each server object has a child NTDS Settings object that represents the
replicating domain controller in the site.

The connection object is a child of t
he NTDS Settings object on the destination server. For replication to
occur between two domain controllers, the server object of one must have a connection object that represents
inbound replication from the other. All replication connections for a domain
controller are stored as
connection objects under the NTDS Settings object. The connection object identifies the replication source
server, contains a replication schedule, and specifies a replication transport.

The Knowledge Consistency Checker (KCC) crea
tes connection objects automatically, but they can also be
created manually. Whenever you change a connection object created by the KCC, you automatically convert
it into a manual connection object. The KCC stops making changes to the manual connection obj
ect.

KCC

The KCC is a built
-
in process that runs on all domain controllers and generates replication topology for the
Active Directory forest. The KCC creates separate replication topologies depending on whether replication is
occurring within a site (intr
asite) or between sites (intersite).

The KCC also dynamically adjusts the topology
to accommodate new domain controllers, domain controllers moved to and from sites, changing costs and
schedules, and domain controllers that are temporarily unavailable.

Wit
hin a site, the connections between domain controllers are always arranged in a bidirectional ring, with
additional shortcut connections to reduce latency in large sites. On the other hand, the intersite topology is a
layering of spanning trees, which mean
s one intersite connection exists between any two sites for each
directory partition and generally does not contain shortcut connections. For more information about spanning
trees and Active Directory replication, see the
Directory Services Guide

of the
Wi
ndows Server

2003
Resource Kit
(or see the
Directory Services Guide

on the Web at http://www.microsoft.com/reskit).

On each domain controller, the KCC creates replication routes by creating one
-
way inbound connection
objects that define connections from ot
her domain controllers. For domain controllers in the same site, the
KCC creates connection objects automatically without administrative intervention. When you have more
than one site, you configure site links between sites and a single KCC in each site au
tomatically creates
connections between sites as well.

144

Chapter 3

Designing the

Site Topology



Figure

3.3 shows two sites (Seattle and Los Angeles) with domain controllers that are all in the same domain.
The arrows represent possible inbound connections that the KCC creates. Because all Active

Directory
updates are transferred in a ring within a site and redundant connections exist, all domain controllers can
receive updates from all other domain controllers in the Seattle site, although domain controllers within a site
do not necessarily repli
cate in both directions. For replication to occur between Seattle and Los Angeles, one
domain controller in each site has a replication agreement with a domain controller in the other site. Between
sites, these replication partners replicate in both direct
ions over a site link that represents the physical WAN
connecting the two sites. In Figure

3.3, domain controllers DC
-
3 and DC
-
4 are replication partners between
the Seattle and Los Angles sites.

Figure

3.
3

Intersite and Intrasite Replication Connections


Failover functionality

Sites ensure that replication is routed around network failures and offline domain controllers. The KCC runs
at specified intervals to adjust the replication topology for changes that occur in Active Directory, such as
when new do
main controllers are added and new sites are created. The KCC reviews the replication status of
existing connections to determine if any connections are not working. If a connection is not working due to a
failed domain controller, the KCC automatically bu
ilds temporary connections to other replication partners
(if available) to ensure that replication occurs.

If all the domain controllers in a site are unavailable, then the
KCC automatically creates replication connections between domain controllers from a
nother site.

Overview of

Designing a Site Topology

145



Subnet

A subnet is a segment of a TCP/IP network to which a set of logical IP addresses are assigned. Subnets group
computers in a way that identifies their physical proximity on the network. Subnet objects in Active
Directory identify the ne
twork addresses that are used to map computers to sites.

Site

Sites are one or more TCP/IP subnets with highly reliable and fast network connections. Site information
allows administrators to configure Active Directory access and replication to optimize us
age of the physical
network. Sites are represented in Active Directory as site objects. Site objects are a set of subnets, and each
domain controller in a forest is associated with an Active Directory site according to its IP address. Sites can
host domain

controllers from more than one domain, and a domain can be represented in more than one site.

Site link

Site links are logical paths that the KCC uses to establish a connection for Active Directory replication. Site
links are stored in Active Directory as

site link objects. A site link object represents a set of sites that can
communicate at uniform cost through a specified intersite transport.

All sites contained within the site link are considered to be connected by means of the same network type.
Sites
must be manually linked to other sites by using site links so that domain controllers in one site can
replicate directory changes from domain controllers in another site. Because site links do not correspond to
the actual path taken by network packets on t
he physical network during replication, you do not need to
create redundant site links to improve Active Directory replication efficiency.

When two sites are connected by a site link, the replication system automatically creates connections
between specifi
c domain controllers in each site called
bridgehead servers
. In Microsoft
®

Windows
®

2000,
intersite replication of the directory partitions (e.g. domain, configuration, and schema) between domain
controllers in different sites is performed by the domain co
ntrollers (one per directory partition) in those sites
designated by the KCC as the bridgehead server. In Windows Server

2003, the KCC may designate more
than one domain controller per site hosting the same directory partition as a candidate bridgehead ser
ver. The
replication connections created by the KCC are randomly distributed between all candidate bridgehead
servers in a site to share the replication workload. By default, the randomized selection process takes place
only when new connection objects are

added to the site.

146

Chapter 3

Designing the

Site Topology



However, you can run Adlb.exe, a new Windows Resource Kit tool called Active Directory Load Balancing
(ADLB) to rebalance the load each time a change occurs in the site topology or in the number of domain
controllers the site. In addit
ion, ADLB can stagger schedules so that the outbound replication load for each
domain controller is spread out evenly across time. Consider using ADLB to balance replication traffic
between the Windows Server

2003

based domain controllers when they are rep
licating to more than 20 other
sites hosting the same domain. For more information about bridgehead servers and Active Directory
replication, see the
Directory Services Guide

of the
Windows Server

2003 Resource Kit
(or see the
Directory
Services Guide

on t
he Web at http://www.microsoft.com/reskit). For more information about Adlb.exe, in
Help and Support Center for Windows Server

2003, click
Tools
, and then click Windows Resource Kit
Tools.

Site link bridge

A site link bridge is an Active Directory object t
hat represents a set of site links, all of whose sites can
communicate by using a common transport. Site link bridges enable domain controllers that are not directly
connected by means of a communication link to replicate with each other. Typically, a site

link bridge
corresponds to a router (or a set of routers) on an IP network.

By default, the KCC can form a transitive route through any and all site links that have some sites in
common. If this behavior is disabled, each site link represents its own dist
inct and isolated network. Sets of
site links that can be treated as a single route are expressed through a site link bridge. Each bridge represents
an isolated communication environment for network traffic.

Site link bridges are a mechanism to logically r
epresent transitive physical connectivity between sites. A site
link bridge allows the KCC to use any combination of the included site links to determine the least expensive
route to interconnect directory partitions held in those sites. The site link brid
ge does not provide actual
connectivity to the domain controllers. If the site link bridge is removed, replication over the combined site
links will continue until the KCC removes the links.

Site link bridges are only necessary if a site contains a domain
controller hosting a directory partition that is
not also hosted on a domain controller in an adjacent site, but another domain controller hosting that
directory partition is located in other sites in the forest. Adjacent sites are defined as any two or mo
re sites
included in a single site link.

A site link bridge creates a logical connection between two site links, providing a transitive path between two
disconnected sites by using an interim site. For the purposes of the intersite topology generator (ISTG
), the
bridge implies physical connectivity by using the interim site. The bridge does not imply that a domain
controller in the interim site will provide the replication path. However, this would be the case if the interim
site contained a domain controll
er that hosted the directory partition to be replicated, in which case a site link
bridge is not required.

Overview of

Designing a Site Topology

147



The cost of each site link is added, creating a summed cost for the resulting path. The site link bridge would
be used if the interim site did not c
ontain a domain controller hosting the directory partition and a lower cost
link does not exist. If the interim site contained a domain controller that hosts the directory partition, two
disconnected sites would set up replication connections to the interi
m domain controller and not use the
bridge.

Site link transitivity

By default all site links are transitive, or “bridged.” When site links are bridged and the schedules overlap,
the KCC creates replication connections that determine domain controller repli
cation partners between sites,
where the sites are not directly connected by site links but are connected transitively through a set of
common sites. This means that you can connect any site to any other site through a combination of site links.

In general
, for a fully routed network, you do not need to create any site link bridges unless you want to
control the flow of replication changes. All site links for a specific transport implicitly belong to a single site
link bridge for that transport. The default

bridging for site links occurs automatically, and no Active
Directory object represents that bridge. The
Bridge all site links

setting found in the properties of both the IP
and Simple Mail Transfer Protocol (SMTP) intersite transport containers implement
s automatic site link
bridging.

Global catalog server

A global catalog server is a domain controller that stores information about all objects in the forest, but not
their attributes, so that applications can search Active Directory without referring to sp
ecific domain
controllers that store the requested data. Like all domain controllers, a global catalog server stores full,
writable replicas of the schema and configuration directory partitions and a full, writable replica of the
domain directory partition

for the domain that it is hosting.

Universal group membership caching

Universal group membership caching allows the domain controller to cache universal group membership
information for users.
You can enable domain controllers that are running Windows Ser
ver

2003 to cache
universal group memberships by
using the Active Directory Sites and Services snap
-
in.

Enabling universal group membership caching eliminates the need for a global catalog server at every site in
a domain, which minimizes network bandwidth

usage because a domain controller does not need to replicate
all of the objects located in the forest. It also reduces logon times because the authenticating domain
controllers do not always need to access a global catalog to obtain universal group member
ship information.
For more information about when to use universal group membership caching, see “Planning Global Catalog
Server Placement” later in this chapter.

148

Chapter 3

Designing the

Site Topology



Collecting Network Information

The first step in designing an effective Active Directory sit
e topology is to consult your organization’s
networking group to collect information and communicate with them regularly about your physical network
topology. Figure

3.4 shows the process for collecting information about your physical network.

Figure

3.
4


Collecting Network Information


Creating a Location Map

Create a location map that represents the physical network infrastructure of your organization. On the
location map, identify the geographic locations that contain groups of computers with internal
connectivity of
10

megabits per second (Mbps) or higher (local area network [LAN]
-
speed or better).

Figure

3.5 shows an example of a location map for Trey Research.

Col
lecting Network

Information

149



Figure

3.
5

Trey Research Locations


Listing Communication Links and Available
Bandwidth

After creating a location map, document the type of communication link, its link speed, and the available
bandwidth between each location. Obtain a WAN topology from your networking group. For a list of
common WAN circuit types and their bandwidth, see “S
etting the Cost” later in this chapter. You need this
information to create site links later in the site topology design process.

Bandwidth

refers to the amount of data that you can transmit across a communication channel in a given
amount of time.
Availab
le bandwidth

refers to the amount of bandwidth actually available for use by Active
Directory. You can obtain available bandwidth information from your network group or you can analyze
traffic on each link by using a protocol analyzer such as Network Monit
or, which is a component that ships
with Windows Server

2003. For information about installing Network Monitor, see “Monitoring network
traffic” in Help and Support Center for Windows Server

2003.

150

Chapter 3

Designing the

Site Topology



Document each location and the other locations that are li
nked to it. In addition, record the type of
communication link and its available bandwidth. For a worksheet to assist you in listing communication links
and available bandwidth, see “Geographic Locations and Communication Links” (DSSTOPO_1.doc) on the

Wind
ows Server

2003 Deployment Kit
companion CD (or see “Geographic Locations and Communication
Links” on the Web at http://www.microsoft.com/reskit).

Figure

3.6

shows an example of a worksheet listing the locations for Trey Research, the communication links
b
etween each location, and the available bandwidth for each communication link.

Figure

3.
6

Example of a Geographic Locations and Communication Links Worksheet


Listing IP Subnets Within Each Location

After you document the communication links and the ava
ilable bandwidth between each location, record the
IP subnets within each location. If you do not already know the subnet mask and IP address within each
location, consult your networking group.

Active Directory associates a workstation with a site by comp
aring the workstation’s IP address with the
subnets that are associated with each site. As you add domain controllers to a domain, Active Directory also
examines their IP addresses and places them in the most appropriate site.

For a worksheet to assist you

in listing the IP subnets within each location, see “Locations and Subnets”
(DSSTOPO_2.doc) on the

Windows Server

2003 Deployment Kit
companion CD (or see “Locations and
Subnets” on the Web at http://www.microsoft.com/reskit).

Collecting Network

Information

151



Figure

3.7 shows an example

of a completed worksheet listing the IP subnets within each Trey Research
location.

Figure

3.
7

Example of a Locations and Subnets Worksheet


Listing Domains and Number of Users for
Each Location

The number of users for each regional domain that is repr
esented in a location is one of the factors that
determine the placement of regional domain controllers and global catalog servers, which is the next step in
the site topology design process. For example, plan to place a regional domain controller in a loc
ation that
contains more than one hundred regional domain users so they can still log on to the domain if the WAN link
fails.

Record the locations, the domains that are represented in each location, and the number of users for each
domain that is represent
ed in each location. For a worksheet to assist you in listing the domains and the
number of users that are represented in each location, see “Domains and Users in Each Location”
(DSSTOPO_3.doc) on the

Windows Server

2003 Deployment Kit
companion CD (or see

“Domains and
Users in Each Location” on the Web at http://www.microsoft.com/reskit).

Figure

3.8 shows a completed worksheet listing the domains that are represented in each Trey Research
location, and the number of users for each domain.

152

Chapter 3

Designing the

Site Topology



Figure

3.
8

Exa
mple of a Domains and Users in Each Location Worksheet


Planning Domain Controller
Placement

After you have gathered all of the network information that will be used to design your site topology, plan
where you want to place domain controllers, including
regional domain controllers, forest root domain
controllers, operations master role holders, and global catalog servers.

Figure

3.9 shows the process for determining domain controller placement.

Pl anning Domain

Controller Placement

153



Figure

3.
9

Planning Domain Controller Placement


Althoug
h this process helps you plan where you intend to place domain controllers, it does not address how
you determine the proper number of domain controllers and the domain controller hardware requirements for
each domain that is represented in each site. For
more information about determining the proper number of
domain controllers for each domain that is represented in each site, see “Planning Domain Controller
Capacity” in this book.

154

Chapter 3

Designing the

Site Topology



Planning Forest Root Domain Controller
Placement

Forest root domain contro
llers are needed to create trust paths for clients that need to access resources in
domains other than their own. Place forest root domain controllers at locations that host datacenters and in
hub locations. If users in a given location need to access reso
urces from other domains in the same location,
and the network availability between the datacenter and the user location is unreliable, then you can either
add a forest root domain controller in the location or create a shortcut trust between the two domai
ns. It is
more cost efficient to create a shortcut trust between the domains unless you have other reasons to place a
forest root domain controller in that location.

Shortcut trusts help to optimize authentication requests made from users located in either

domain. For more
information about how to create shortcut trusts between domains, see “Create a shortcut trust” in Help and
Support Center for Windows Server

2003.

For a worksheet to assist you in documenting your forest root domain controller placement,
see “Domain
Controller Placement” (DSSTOPO_4.doc) on the
Windows Server

2003 Deployment Kit
companion CD (or
see “Domain Controller Placement” on the Web at http://www.microsoft.com/reskit). For an example of a
completed Domain Controller Placement workshe
et, see “Example: Determining Domain Controller
Placement” later in this chapter.

You need to refer to this information when you create the forest root domain. For more information about
deploying the forest root domain, see “Deploying the Windows Server

2
003 Forest Root Domain” in this
book.

Planning Regional Domain Controller
Placement

For cost efficiency, plan to place as few regional domain controllers as possible. First review the Geographic
Locations and Communication Links worksheet to determine whet
her a location is a hub. Plan to place
regional domain controllers for each domain that is represented in each hub location.

In addition, ensure the physical security of domain controllers in hub locations so that unauthorized
personnel cannot access them.

Do not place domain controllers in a location in which you cannot guarantee
the physical security of the domain controller.

After you place regional domain controllers in all hub locations, evaluate the need for placing regional
domain controllers at sate
llite locations. Eliminating unnecessary regional domain controllers from satellite
locations reduces the support costs required to maintain a remote server infrastructure.

Pl anning Domain

Controller Placement

155



To authenticate client logons and access to local file servers, most organizations

place regional domain
controllers for all regional domains that are represented in a given location. However, you must consider
many variables when evaluating whether a business location requires its clients to have local authentication
or the clients can

rely on authentication and query over a WAN link. Figure

3.10 shows how to determine
whether to place domain controllers at satellite locations.

Figure

3.
10

Determining Whether to Place Domain Controllers at Satellite Locations


156

Chapter 3

Designing the

Site Topology



Domain Controller Phys
ical Security

Do not place a regional domain controller in a satellite location if you cannot ensure the physical security of
the domain controller. A person who has physical access to a domain controller can attack the system by:



Accessing physical disks
by starting an alternate operating system on a domain controller.



Removing (and possibly replacing) physical disks on a domain controller.



Obtaining and manipulating a copy of a domain controller system state backup.

Add regional domain controllers only to

locations in which you can guarantee their physical security.

On
-
site Technical Expertise Availability

Domain controllers need to be managed continuously for various reasons. Place a regional domain controller
only in locations that include personnel who
can administer the domain controller, or be sure that the domain
controller can be managed remotely.

WAN Link Availability

WAN links that experience frequent outages can cause significant productivity loss to users if the location
does not include a domain

controller that can authenticate the users. If your WAN link availability is not
100

percent, place a regional domain controller in locations where the users require the ability to log on when
the WAN link is down.

Authentication Availability

Certain orga
nizations, such as banks, require that users be authenticated at all times. Place a regional domain
controller in a location where the WAN link availability is not 100

percent but users require authentication at
all times.

Logon Performance over WAN Link

I
f your WAN link availability is 100 percent, then whether you place a domain controller at the location
depends on the logon performance requirements over the WAN link. Factors that influence logon
performance over the WAN include link speed and available
bandwidth, number of users and usage profiles,
and the amount of logon network traffic versus replication traffic.

WAN link speed and bandwidth utilization

The activities of a single user can congest a slow WAN link. Place a domain controller at a location

if logon
performance over the WAN link is unacceptable.

The average percentage of bandwidth utilization indicates how congested a network link is. If a network link
has an average bandwidth utilization that is greater than an acceptable value, place a dom
ain controller at that
location.

Pl anning Domain

Controller Placement

157



Number of users and usage profile

The number of users and their usage profile at a given location can help determine whether you need to place
regional domain controllers at that location. To avoid productivity loss in the

event of a WAN link failure,
place a regional domain controller at a location that has a staff of one hundred or more users.

The usage profile indicates how the users use the network resources. You need not place a domain controller
in a location that con
tains only a few users who do not frequently access network resources.

Logon network traffic vs. replication traffic

If a domain controller is not available within the same location as the Active Directory client, then the client
creates logon traffic on t
he network. The amount of logon network traffic that is created on the physical
network is influenced by several factors, including group memberships, number and size of GPOs, logon
scripts, and IntelliMirror
®

features such as offline folders, folder redir
ection, and roaming profiles.

On the other hand, a domain controller that is placed at a given location generates replication traffic on the
network. The frequency and amount of updates made on the partitions hosted on the domain controllers
influence the
amount of replication traffic that is created on the network. The different types of updates that
can be made on the partitions hosted on the domain controllers include adding or changing users and user
attributes, changing passwords, and adding or changin
g global groups, printers, or volumes.

To determine if you need to place a regional domain controller at a location, compare the cost of logon traffic
created by a location without a domain controller versus the cost of replication traffic created by placi
ng a
domain controller at the location.

For example, consider a network that has branch offices that are connected through slow links to the
headquarters and in which domain controllers can easily be added. If the daily logon and directory lookup
traffic o
f a few remote site users causes more network traffic than replicating all company data to the branch,
consider adding a domain controller to the branch.

If reducing the cost of maintaining domain controllers is more important than network traffic, central
ize the
domain controllers for that domain and do not place any regional domain controllers at the location.

For a worksheet to assist you in documenting the placement of regional domain controllers and the number
of users for each domain that is represent
ed in each location, see “Domain Controller Placement”
(DSSTOPO_4.doc) on the

Windows Server

2003 Deployment Kit
companion CD (or see “Domain Controller
Placement” on the Web at http://www.microsoft.com/reskit). For an example of a completed Domain
Control
ler Placement worksheet, see “Example: Determining Domain Controller Placement” later in this
chapter.

You need to refer to the information about locations in which you need to place regional domain controllers
when you deploy regional domains. For more in
formation about deploying regional domains, see “Deploying
Windows Server

2003 Regional Domains” in this book.

158

Chapter 3

Designing the

Site Topology



Planning Global Catalog Server Placement

In a single domain forest, configure all domain controllers as global catalog servers because this does

not
require any additional disk space usage, CPU usage, or replication traffic.
Global catalog servers facilitate
user logon requests and forest
-
wide searches.
Figure

3.11

illustrates how to determine which locations
require global catalog servers.

Figure

3.
11

Determining the Placement of Global Catalog Servers


Pl anning
Domain

Controller Placement

159



Adding Global Catalog Servers Based on Application Requirements

Certain applications, such as Microsoft
®

Exchange
®

2000, Message Queuing (also known as MSMQ), and
applications using Distributed

COM (DCOM), do not deliver adequate response over latent WAN links and
therefore need a highly available global catalog infrastructure to provide low query latency. Determine
whether any applications that perform poorly over a slow WAN link are running in

locations or whether the
locations include Exchange servers. If your locations include applications that do not deliver optimum
response over a WAN link, you must place a global catalog server at the location to reduce query latency.

Adding Global Catalog

Servers for a Large Number of Users

Place global catalog servers at all locations that contain more than 100 users to reduce congestion of network
WAN links and to prevent productivity loss in case of WAN link failure.

Using Highly Available Bandwidth

You

do not need to place a global catalog at a location that does not include applications that require a global
catalog server, includes less than 100 users, and is also connected to another location that includes a global
catalog server by a WAN link that i
s 100 percent available for Active Directory. In this case, the users can
access the global catalog server over the WAN link.

Adding Global Catalog Servers for a Large Number of Roaming
Users

Roaming users need to contact the global catalog servers wheneve
r they log on for the first time at any
location. Place a global catalog at a location that is visited by a large number of roaming users if the logon
time over the WAN link is unacceptable.

Enabling Universal Group Membership Caching

For locations that in
clude less than 100 users and do not include a large number of roaming users or
applications that require a global catalog server, you can deploy domain controllers that are running
Windows Server

2003 and enable universal group membership caching. Ensure
that the global catalog
servers are not more than one replication hop from the domain controller on which universal group
membership caching is enabled, so that universal group information in the cache can be refreshed.

For more information about how to en
able

universal group membership caching
, see “
Cache universal group
memberships
” in Help and Support Center for Windows Server

2003.

For a worksheet to assist you in documenting where you plan to place global catalog servers and domain
controllers with uni
versal group caching enabled, see “Domain Controller Placement” (DSSTOPO_4.doc) on
the
Windows Server

2003 Deployment Kit
companion CD (or see “Domain Controller Placement” on the
Web at http://www.microsoft.com/reskit). For an example of a completed Domai
n Controller Placement
worksheet, see “Example: Determining Domain Controller Placement” later in this chapter. You need to refer
to the information about locations in which you need to place global catalog servers when you deploy the
forest root domain an
d regional domains.

160

Chapter 3

Designing the

Site Topology



Planning Operations Master Role
Placement

Active Directory supports multimaster replication of directory data, which means any domain controller can
accept directory changes and replicate the changes to all other domain controllers. Ho
wever, certain changes,
such as schema modifications, are impractical to perform in a multimaster fashion. For this reason certain
domain controllers, known as
operations masters
, hold roles responsible for accepting requests for certain
specific changes.

Three operations master roles exist in each domain:



The primary domain controller (PDC) emulator processes all replication requests from
Microsoft
®
Windows

NT
®

4.0 backup domain controllers (BDCs) and processes all
password updates for clients that are not

running Active Directory client software.



The relative identifier (RID) master allocates RIDs to all domain controllers to ensure that
all security principals have a unique identifier.



The infrastructure master for a given domain maintains a list of the s
ecurity principals from
other domains that are members of groups within its domain.

In addition to the three domain
-
level operations master roles, two operations master roles exist in each forest:



The schema master governs changes to the schema.



The domain

naming master adds and removes domains to and from the forest.

Place the domain controllers hosting these operations master roles in areas where network reliability is high,
and ensure that the PDC emulator and the RID master are consistently available.

O
perations master role holders are assigned automatically when the first domain controller in a given domain
is created. The two forest
-
level roles (schema master and domain naming master) are assigned to the first
domain controller created in a forest. Add
itionally, the three domain
-
level roles (RID master, infrastructure
master, and PDC emulator) are assigned to the first domain controller created in a domain.

Place the first domain controller for a domain in a location that has the largest number of users

for that
domain. Designate a standby operations master for a domain controller that hosts the operations master roles.
The standby operations master is a domain controller that you identify as the computer that assumes the
operations master role if the or
iginal role holder fails. Ensure that the standby operations master is a direct
replication partner of the actual operations master.

Pl anning Domain

Controller Placement

161



Operations Master Placement for Single Domain Forest

In addition to hosting the operations master roles, the first domain
controller created in a forest also hosts the
global catalog. In a single domain forest, the database of a global catalog server is identical to that of a
domain controller. Therefore, configure all domain controllers as global catalog servers because it d
oes not
cause any additional workload for the domain controllers. In a single domain forest where all domain
controllers are configured as global catalog servers, leave all operation master roles on the first domain
controller that is created in the forest

and use the second domain controller as a standby operations master.

Operations Master Placement for Forest Root Domain

In a forest hosting multiple domains, if all domain controllers in the forest root domain are also global
catalog servers, leave all th
e operations master roles on the first domain controller. Use the second domain
controller deployed in the forest as the standby operations master.

However, if all domain controllers in the forest root domain are not also global catalog servers, move all t
he
operations master roles to the second domain controller deployed in the forest root domain and ensure that
this domain controller is never configured as a global catalog server. This is because the first domain
controller is always a global catalog serv
er and the infrastructure master should not be placed on a domain
controller that is also a global catalog server unless all domain controllers are global catalog servers. To
simplify the environment, keep all the operations master roles on the second doma
in controller. Configure
the third domain controller deployed in the forest root domain as the standby operations master and ensure
that this domain controller will also never be configured as global catalog server.

Operations Master Placement for Regional

Child Domain

The three domain
-
level roles are assigned to the first domain controller in the domain by default. If any
domain controllers in the regional domain will not host the global catalog, leave the three
-
domain
-
level
operations master roles on the
first domain controller and ensure that the first domain controller is never
configured as a global catalog server. Configure the second domain controller deployed in this domain to be
the standby operations master.

Planning the PDC emulator placement

The
PDC emulator acts as a Windows

NT

4.0 PDC if the domain contains pre

Active Directory clients or if
it contains Windows

NT

4.0 BDCs. It processes password changes from clients and replicates updates to the
BDCs. Only one domain controller acts as the PDC e
mulator in each domain in the forest.

Even if all the domain controllers are upgraded to Windows

2000 or Windows Server

2003 and the domain is
operating at the Windows

2000 native functional level, the PDC emulator receives preferential replication of
pass
word changes performed by other domain controllers in the domain. If a password was recently changed,
that change takes time to replicate to every domain controller in the domain. If logon authentication fails at
another domain controller due to a bad pass
word, that domain controller forwards the authentication request
to the PDC emulator before rejecting the logon attempt.

Place the PDC emulator in a location that contains a large number of users from that domain for password
forwarding operations if neede
d. In addition, ensure that the location is well connected to other locations to
minimize replication latency.

Use the Domain Controller Placement worksheet to document the information about where you plan to place
PDC emulators and the number of users for

each domain that is represented in each location. For an example
162

Chapter 3

Designing the

Site
Topology


of a completed Domain Controller Placement worksheet, see “Example: Determining Domain Controller
Placement” later in this chapter.

You need to refer to the information about locations in wh
ich you need to place PDC emulators when you
deploy regional domains. For information about deploying regional domains, see “Deploying Windows
Server

2003 Regional Domains” in this book.

Requirements for infrastructure master placement

The infrastructure m
aster updates the names of security principals from other domains that are added to
groups in its own domain. For example, if a user from one domain is a member of a group in a second
domain and the user’s name is changed in the first domain, then the seco
nd domain is not notified that the
user’s name must be updated in the group’s membership list. Because domain controllers in one domain do
not replicate security principals to domain controllers in another domain, the second domain never becomes
aware of t
he change in the absence of the infrastructure master.

The infrastructure master constantly monitors group memberships, looking for security principals from other
domains. If it finds one, it checks with the security principal’s domain to verify that the i
nformation is
updated. If the information is out of date, the infrastructure master performs the update and then replicates
the change to the other domain controllers in its domain.

Two exceptions apply to this rule. First, if all domain controllers are gl
obal catalog servers, the domain
controller that hosts the infrastructure master role is insignificant because global catalogs replicate the
updated information regardless of the domain to which they belong. Second, if the forest has only one
domain, the d
omain controller that hosts the infrastructure master role is insignificant because security
principals from other domains do not exist.

Do not place the infrastructure master on a domain controller that is also a global catalog server. If the
infrastructu
re master and global catalog are on the same domain controller, the infrastructure master will not
function. The infrastructure master will never find data that is out of date, so it will never replicate any
changes to the other domain controllers in the d
omain.

Document the information about operations master roles placement. You need to refer to this information
when you create the forest root domain and regional domains. For more information about deploying the
forest root domain, see “Deploying the Wind
ows Server

2003 Forest Root Domain” in this book. For more
information about deploying regional domains, see “Deploying Windows Server

2003 Regional Domains” in
this book. Use the Domain Controller Placement worksheet to document information about where yo
u plan
to place operations master role holders. For an example of a completed Domain Controller Placement
worksheet, see “Example: Determining Domain Controller Placement” later in this chapter.

For a worksheet to assist you in planning operations master r
ole placement, see “Domain Controller
Placement” (DSSTOPO_4.doc) on the

Windows Server

2003 Deployment Kit
companion CD (or see
“Domain Controller Placement” on the Web at http://www.microsoft.com/reskit).

Pl anning Domain

Controller Placement

163



Example: Determining Domain Controller
Placement

Figure

3.12 shows an example of a completed Domain Controller Placement worksheet for Trey Research,
which has offices located in Seattle, New York, Los Angeles, Boston, Phoenix, and Washington, DC. Users
from three domains exist in the organization: the f
orest root domain, and the EAST and WEST domains.
Seattle is the hub location for Western locations and New York is the hub location for Eastern locations. For
each location, Trey Research documented the names of the domains, the number of users for each d
omain,
and the type of domain controllers needed.

Figure

3.
12

Example of a Domain Controller Placement Worksheet


164

Chapter 3

Designing the

Site Topology



The following decisions were made regarding placement of domain controllers at each location based on
WAN link speed between locations, nu
mber of users per domain, the need for users to access resources
across the forest, and logon performance over WAN links:



The PDC emulator for the WEST domain is placed in Seattle because it includes the largest
number of users from the WEST domain. The PD
C emulator for the EAST domain is placed
in New York because it includes the largest number of users from the EAST domain.



Because Trey Research includes a large number of users that are distributed across different
geographic locations connected by a wide

area network (WAN), two regional domains are
created (EAST and WEST) to reduce replication traffic over slow WAN links. Regional
domain controllers hosting the WEST domain are placed in Seattle, Los Angeles, and New
York. Regional domain controllers hosti
ng the EAST domain are placed in New York,
Boston, Seattle, and Washington, DC. At any given time, an average of 200 mobile users
from the WEST domain travel from Seattle to the New York location. Therefore, regional
domain controllers hosting the WEST dom
ain are placed in New York so that these mobile
users belonging to the WEST domain can log on locally at the New York location. Similarly,
at any given time, an average of 200 mobile users from New York travel to the Seattle
location. Therefore, regional d
omain controllers hosting the EAST domain are placed in
Seattle so that mobile users belonging to the EAST domain can log on locally in Seattle.

Because domain controllers from both EAST and WEST domains are placed into the Seattle
and New York locations r
espectively, the resulting network traffic for replication is similar
to the replication traffic created if Trey Research had deployed a single domain forest.
However, because there are additional locations (Los Angeles, Phoenix, Boston, and
Washington, DC
) that are connected to the Seattle and New York hub locations through
slower network links, and none of the users from these satellite locations will travel to these
hub locations, Trey Research will still save network bandwidth caused by replication.

Bec
ause Phoenix has only 20 users from the WEST domain and users at the Phoenix
location have acceptable logon performance over the WAN link between Phoenix and
Seattle, the organization decides not to place any regional domain controllers in Phoenix.
Users i
n Boston require local authentication at all times but do not have 100 percent WAN
link availability between New York and Boston. Therefore, a domain controller hosting the
EAST domain is placed at the Boston location.



The TRCCORP forest root domain contro
llers are placed in Seattle and New York because
they are hub locations in the Trey Research forest. Shortcut trusts are created between the
WEST domain and the EAST domain because users in Boston need to regularly access
resources from the WEST domain.

Cr eating a

Site Design

165





G
lobal catalog servers are placed in Seattle, Los Angeles, and New York because each
location hosts more than one hundred users. A domain controller with universal group
caching enabled is placed in Boston instead of a global catalog server because that loc
ation
has only 80 users and does not include any applications that require a global catalog server.



Washington, DC hosts only 50 users from the EAST domain, and does not have 100 percent
WAN link availability between New York. Additionally, no applications

that require a
global catalog server are running at this location. Because Washington, DC has less than 100
users and also no application that requires a global catalog server is running at this location,
no global catalog server is placed in Washington,
DC. The users in Washington, DC need
local authentication at all times, hence a domain controller running Windows Server

2003 is
configured for universal group caching and placed there to facilitate user logon requests.

Creating a Site Design

Creating a si
te design involves deciding which locations will become sites, creating site objects, creating
subnet objects, and associating the subnets with sites. Figure

3.13 shows the steps that are required to create a
site design.

Figure

3.
13

Creating a Site Desi
gn


166

Chapter 3

Designing the

Site Topology



Deciding Which Locations Will Become Sites

Figure

3.14 illustrates how to decide which locations will become sites.

Figure

3.
14

Deciding Which Locations Will Become Sites


Decide which locations to create sites for as follows:



Create sites for all

locations in which you plan to place domain controllers. Refer to the
information documented in the Domain Controller Placement worksheet to identify locations
that include domain controllers. For an example of a completed Domain Controller
Placement work
sheet, see “Example: Determining Domain Controller Placement” earlier in
this chapter.



Create sites for those locations that include servers that are running applications that require
a site to be created. Certain applications, such as DFS, use site object
s to locate the closest
servers to clients.



If a site is not required for a location, add the subnet of the location to a site for which the
location has the maximum WAN speed and available bandwidth.

Cr eating a

Site Design

167



Document those locations that will become sites and th
e network addresses and subnet masks within each
location. For a worksheet to assist you in documenting sites, see “Associating Subnets with Sites”
(DSSTOPO_6.doc) on the
Windows Server

2003 Deployment Kit
companion CD (or see “Associating
Subnets with Sit
es” on the Web at http://www.microsoft.com/reskit).

Creating a Site Object Design

For every location where you have decided to create sites, plan to create site objects in Active Directory.
Document those locations that will become sites in the “Associatin
g Subnets with Sites” worksheet.

For more information about how to create site objects, see “Create a site” in Help and Support Center for
Windows Server

2003.

Creating a Subnet Object Design

For every IP subnet and subnet mask associated with each locatio
n, plan to create subnet objects in Active
Directory representing all the IP addresses within the site. To obtain information about IP subnets within
each location, refer to the Locations and Subnets worksheet. For an example of a completed Locations and
S
ubnets worksheet, see “Listing IP Subnets Within Each Location” earlier in this chapter.

When creating an Active Directory subnet object, the information about network IP subnet and subnet mask
is automatically translated into the network prefix length not
ation format <
IP address
>/<
# of bits
>. For
example, the network IP address 172.16.4.0 with a subnet mask 255.255.252.0 appears as 172.16.4.0/22.

For more information about how to create subnet objects, see “Create a subnet” in Help and Support Center
for W
indows Server

2003.

Document the Active Directory subnet object associated with each location in the “Associating Subnets with
Sites” worksheet.

Associating Subnets with Sites

Associate each subnet object with a site object by referring to the “Associating

Subnets with Sites”
worksheet to determine which subnet is to be associated with which site.

For more information about associating subnets with sites, see “Associate a subnet with a site” in Help and
Support Center for Windows Server

2003.

168

Chapter 3

Designing the

Site Topology



Example: Asso
ciating Subnets with Sites

Figure

3.15 shows an example of a completed Associating Subnets with Sites worksheet for Trey Research,
which has offices located in Seattle, Los Angeles, Boston, New York, Phoenix, and Washington, DC. Trey
Research listed potent
ial site candidates, the locations to be included in those sites, and the corresponding
Active Directory subnets. Because the Phoenix location includes fewer than one hundred users, a domain
controller is not placed at that location. The Phoenix subnets ar
e associated with the Seattle site because
Seattle is the nearest location that has a direct communication link to Phoenix.

Figure

3.
15

Example of Associating Subnets with Sites Worksheet


Creating a Site Link Design

Create a site link design in order t
o connect your sites with site links. Site links reflect the intersite
connectivity and method used to transfer replication traffic. You must connect sites with site links so that
domain controllers at each site can replicate Active Directory changes.

Fig
ure

3.16 shows the process for creating a site link design.

Cr eating a

Site Link Design

169



Figure

3.
16

Creating a Site Link Design


Connecting Sites with Site Links

To connect sites with site links, identify the member sites that you want to connect with the site link, create a
site

link object in the respective
Inter
-
Site Transports

container, and then name the site link. After you
create the site link, you can proceed to set the site link properties.

When creating site links, ensure that every site is included in a site link. In ad
dition, ensure that all sites are
connected to each other through other site links so that the changes can be replicated from domain controllers
in any site to all other sites. If you fail to do this, then the KCC generates an error message in the Director
y
Service log in Event Viewer stating that the site topology is not connected.

170

Chapter 3

Designing the

Site Topology



Whenever you add sites to a newly created site link, determine if the site being added is a member of other
site links and change the site link membership of the site if needed
. For example, if you make a site a
member of the default
-
first
-
site
-
link when you initially create the site, be sure to remove the site from the
default
-
first
-
site
-
link after you add the site to a new site link. If you do not remove the site from the defa
ult
-
first
-
site
-
link, the KCC will make routing decisions based on the membership of both site links, which may
result in incorrect routing.

To identify the member sites that you want to connect with a site link, use the list of locations and linked
locatio
ns that you recorded in the “Geographic Locations and Communication Links” worksheet. If multiple
sites have the same connectivity and availability to each other, you can connect them with the same site link.
For an example of a completed Geographic Locati
ons and Communication Links worksheet, see “Listing
Communication Links and Available Bandwidth” earlier in this chapter.

The Inter
-
Site Transports container provides the means for mapping site links to the transport that the link
uses. When you create a s
ite link object, you create it in either the IP container (which associates the site link
with the remote call procedure [RPC] over IP transport) or the Simple Mail Transfer Protocol (SMTP)
container (which associates the site link with the SMTP transport)
. When you create a site link object in the
respective
Inter
-
Site Transports

container, Active Directory uses RPC over IP to transfer both intersite and
intrasite replication between domain controllers. To keep data secure while in transit, RPC over IP
rep
lication uses both the Kerberos authentication protocol and data encryption.

When a direct IP connection is not available, you can configure replication between sites to use SMTP.
However, SMTP replication functionality is limited and requires an enterpris
e certification authority (CA).
SMTP can only replicate the configuration, schema, and application directory partitions, and does not
support the replication of domain directory partitions.

To name site links, use a consistent naming scheme, such as
name_o
f_site1
-
name_of_site2
. Record the list of
sites, linked sites, and the names of the site links connecting these sites in a worksheet.

For a worksheet to assist you in recording site names and associated site link names, see “Sites and
Associated Site Links
” (DSSTOPO_5.doc) on the
Windows Server

2003 Deployment Kit
companion CD (or
see “Sites and Associated Site Links” on the Web at http://www.microsoft.com/reskit).

Figure

3.17 shows an example of a completed “Sites and Associated Site Links” worksheet.

Cr eating a

Site Link Design

171



Fig
ure

3.
17

Example of a Sites and Associated Site Links Worksheet


Setting Site Link Properties

Intersite replication occurs according to the properties of the connection objects. When the KCC creates
connection objects, it derives the replication schedul
e from properties of the site link objects. Each site link
object represents the WAN connection between two or more sites.

Setting site link object properties includes the following steps:



Determining the cost that is associated with that replication path.

The KCC uses cost to
determine the least expensive route for replication between two sites that replicate the same
directory partition.



Determining the schedule that defines the times during which intersite replication can occur.



Determining the replicati
on interval that defines how frequently replication should occur
during the times when replication is allowed as defined in the schedule.

Determining the Cost

You assign cost values to site links to favor inexpensive connections over expensive connections.

Certain
applications and services, such as Domain Controller Locator and DFS, also use cost information to locate
nearest resources. Site link cost can be used to determine which domain controller is contacted by clients
located in one site if the domain
controller for the specified domain does not exist at that site. The client
contacts the domain controller by using the site link that has the lowest cost assigned to it.

172

Chapter 3

Designing the

Site Topology



It is recommended that the cost value be defined on a site
-
wide basis. Cost is usual
ly based not only on the
total bandwidth of the link but also on the availability, latency, and monetary cost of the link.

To determine the costs to place on site links, perform these tasks:



Document the connection speed for each site link. Refer to the Ge
ographic Locations and
Communication Links worksheet for information about the connection speed that you
identified. For an example of a completed Geographic Locations and Communication Links
worksheet, see “Listing Communication Links and Available Bandwi
dth” earlier in this
chapter.

Table

3.1 lists the speeds for different types of networks.

Table

3.
1

Speeds for Different Network Types

Network Type

Speed

Very slow

56

kilobits per second (Kbps)

Slow

64

Kbps

ISDN

64

Kbps or 128

Kbps

Frame relay

Varia
ble rate, commonly between 56

Kbps and
1.5

megabits per second (Mbps)

T1

1.5

Mbps

T3

45

Mbps

10BaseT

10

Mbps

Asynchronous transfer
mode (ATM)

Variable rate, commonly between 155

Mbps
and 622

Mbps

100BaseT

100

Mbps

Gigabit Ethernet

1

gigabit per secon
d (Gbps)




Use Table

3.2 to calculate the cost of each site link based on WAN link speed. For WAN
link speed that is not listed in the table, you can calculate a relative cost factor by dividing
1024 by the log of the available bandwith as measured in Kbps
.

Cr eating a

Site Link Design

173



Table

3.
2

Calculating Costs Based on WAN Link Speed

Available Bandwidth (Kbps)

Cost

9.6

1042

19.2

798

38.4

644

56

586

64

567

128

486

256

425

512

378

1024

340

2048

309

4096

283


These costs do not reflect differences in reliability between
network links. Set higher costs on any failure
-
prone network links so that you do not need to rely on those links for replication. By setting higher site links
costs, you can control replication failover when a site link fails.

Determining the Schedule

You

can control site link availability by setting a schedule on site links. When replication between two sites
traverses multiple site links, the intersection of the replication schedules on all relevant links determines the
connection schedule between the tw
o sites.

To plan for setting the site link schedule, create two overlapping schedules between site links that contain
domain controllers that need to directly replicate with each other. Use the default (100
-
percent available)
schedule on those links unless

you want to block replication traffic during peak hours. By blocking
replication, you give priority to other traffic, but you also increase replication latency.

Domain controllers store time in Coordinated Universal Time (UTC). Time settings in site link
object
schedules conform to the local time of the site and computer on which the schedule is set. When a domain
controller contacts a computer that is in a different site and time zone, the schedule on the domain controller
displays the time setting accord
ing to the local time for the site of the computer.

174

Chapter 3

Designing the

Site Topology



Determining the Interval

You must set the site link replication interval property to indicate how frequently you want replication to
occur during the times when the schedule allows replication. For examp
le, if the schedule allows replication
between 02:00

hours and 04:00

hours, and the replication interval is set for 30

minutes, replication can occur
up to four times during the scheduled time. The default replication interval is 180

minutes, or 3

hours.

C
onsider the following criteria to determine how often replication occurs within the schedule window:



A small interval decreases latency but increases the amount of WAN traffic.



To keep domain directory partitions up to date, low latency is preferred.

With
a store
-
and
-
forward replication strategy, determining just how long a directory update might take to be
replicated to every domain controller is difficult. To provide a conservative estimate of maximum latency,
perform these tasks:



Create a table of all th
e sites on your network, as shown in Table

3.3.

Table

3.
3

Maximum Latency (in Hours) of Replication Between Sites


Seattle

Boston

Los
Angeles

New York

Washingto
n DC

Seattle

0.25





Boston


0.25




Los
Angeles



0.25



New York




0.25


Washington
D
C





0.25


An average, worst
-
case latency within a site is estimated to be 15 minutes.

Cr eating a

Site Link Design

175





From the replication schedule, determine the maximum replication latency possible on any
site link connecting two hub sites.

For example, if replication occurs betwee
n Seattle and New York every three hours, then the
maximum delay for replication between these sites is 3 hours. If the replication delay
between New York and Seattle is the longest scheduled delay among all hub sites, then the
maximum latency between all
hubs is 3 hours.



For each hub site, create a table of the maximum latencies between the hub site and any of
its satellite sites.

For example, if replication occurs between New York and Washington, DC, every four
hours and this is the longest replication de
lay between New York and any of its satellite
sites, then the maximum latency between New York and its satellites is four hours.



Combine these maximum latencies to determine the maximum latency for the entire
network.

For example, if the maximum latency be
tween Seattle and its satellite site in Los Angeles is
one day, the maximum replication latency for this set of links (Washington, DC
-
New York
-
Seattle
-
Los Angeles) is 31 hours (4 (Washington, DC
-
New York)+ 3 (New York
-
Seattle) +
24 (Seattle
-
Los Angeles)) a
s shown in Table

3.
4
.

Table

3.
4

Maximum Latency (in Hours) of Replication Between Sites


Seattle

Boston

Los
Angeles

New York

Washingto
n DC

Seattle

0.25

4+3

24.00

3.00

4+3

Boston


0.25

4+3+24

4.00

4.00

Los Angeles



0.25

24 + 3

24+3+4

New York




0.25

4.00

Washington,
DC





0.25


Review your maximum replication latency, and revise your replication schedule and interval if necessary.

176

Chapter 3

Designing the

Site Topology



Example: Creating a Site Link Design

As an example of a site link design, Figure

3.18 shows three domain controllers
from the same domain at
three different Trey Research sites: Los Angeles, New York, and Seattle. The LAX
-
SEA and SEA
-
NYC site
link objects are created to permit replication between domain controllers at the three sites. The site link
object LAX
-
SEA is assi
gned a cost of 586, whereas the site link object SEA
-
NYC is assigned a lower cost of
471 because the T1 communication link that connects the Seattle and New York sites has a more available
bandwidth (150 Kbps) than the 56 Kbps available bandwidth between t
he Seattle and Los Angeles sites.

Active Directory replication topology for the example in Figure

3.
18

is computed by the KCC according to a
spanning tree algorithm. For intersite replication, a spanning tree algorithm determines how to connect all the
sit
es that need to be connected with the minimum number of connections and the least cost. For the example
shown in Figure

3.
18
, the cost of replication between domain controller DC
-
2 and domain controller DC
-
1 is
586, the cost of replication between domain c
ontroller DC
-
1 and domain controller DC
-
3 is 471. Because no
direct communication link exists between the New York and Los Angeles sites, the cost of replication
between these two sites is equal to the sum of the replication costs between the Los Angeles a
nd Seattle sites
and the Seattle and New York sites (471 + 586 = 1,057).

Based on these calculated costs, the domain controllers in these three sites can replicate the domain
information by creating three replication connections: DC
-
2 replicates with DC
-
1
(cost =586), DC
-
3
replicates with DC
-
1 (cost = 471), and DC
-
2 replicates with DC
-
3 (cost = 1,057). Two replication
connections between DC
-
1 and DC
-
2 and DC
-
1 and DC
-
3 are sufficient for replicating the domain
information between the three sites. Hence, bas
ed on the spanning tree algorithm, connection objects are
created between DC
-
1 and DC
-
2, and between DC
-
1 and DC
-
3..

No site link is created between the Los Angeles and New York sites by the site topology owner because no
direct communication link exists b
etween these two locations. Even if a third site link with a cost of 1,057 is
created between the Los Angeles and New York sites, no additional connection objects will be created
between domain controllers DC
-
2 and DC
-
3.

With transitivity enabled in this e
xample, DC
-
2 at Los Angeles always replicates with DC
-
1 (cost = 586) in
Seattle and not DC
-
3 (cost = 586 + 471) in New York because the LAX
-
SEA site link cost is more favorable.
Replication connections between DC
-
2 and DC
-
3 will only be created if DC
-
1 at
the Seattle site is
unavailable.

Cr eating a

Site Link D
esign

177



Figure

3.
18

Example of Site Links


However, with transitivity disabled in this example, because no direct communication link exists between the
Los Angeles and New York sites, DC
-
2 will only replicate with DC
-
1 and neve
r replicate with DC
-
3 even if
DC
-
1 in Seattle fails.

With site link transitivity enabled, if DC
-
2 in the Los Angeles site and DC
-
3 in the New York site are from a
different domain (domain A) than DC
-
1 in the Seattle site (domain B), and if the LAX
-
SEA site

link has a
schedule of 18:00

hours to 24:00

hours and the SEA
-
NYC site link has a schedule of 17:00

hours to
20:00

hours, data can be replicated directly from DC
-
2 to DC
-
3 between 18:00

hours and 20:00

hours, which
is the intersection of the LAX
-
SEA site
link replication schedule and the SEA
-
NYC site link replication
schedule. If the LAX
-
SEA site link schedule does not overlap with the SEA
-
NYC site link schedule, then
replication between DC
-
2 and DC
-
3 can never occur.

178

Chapter 3

Designing the

Site Topology



Creating a Site Link Bridge
Design

A
site link bridge connects two or more site links. Figure

3.19 shows the steps for creating a site link bridge
design.

Figure

3.
19

Creating a Site Link Bridge Design


A site link bridge enables transitivity between site links. Each site link in a bridge
needs to have a site in
common with another site link in the bridge or else the bridge cannot compute the cost from sites in the link
to the sites in the other links of the bridge. Without the presence of a common site between site links, the
bridge also c
annot establish direct connections between domain controllers in the sites that are connected by
the same site link bridge.

Cr eating a

Site Link Bridge Design

179



By default, all site links are transitive and it is recommended to keep transitivity enabled by not changing the
default value of
B
ridge all site links

(enabled by default). However, you will need to disable
Bridge all site
links

to complete your site link bridge design if:



Your IP network is not fully routed. When you disable
Bridge all site links
, all site links are
considered nontr
ansitive, and you can create and configure site link bridge objects to model
the actual routing behavior of your network.


Or


You need to control the replication flow of the changes made in Active Directory. By
disabling
Bridge all site links
for the site

link IP transport and configuring a site link bridge,
the site link bridge becomes the equivalent of a disjointed network. All site links within the
site link bridge can route transitively, but they do not route outside of the site link bridge.

For more i
nformation about how to use Active Directory Sites and Services to disable the
Bridge all site
links
setting, see “Enable or disable site link bridges” in Help and Support Center for Windows Server

2003.

Creating a Site Link Bridge Design for
Disjointed Ne
tworks

If your IP network is not fully routed, you must disable
Bridge all site links

for the IP transport and
configure site link bridge objects. If your IP network is fully routed but you have too many routes that you
categorically do not want the KCC to

consider, you also need to disable
Bridge all site links

and manually
create site link bridges.

For more information about how to use the Active Directory Sites and Services snap
-
in to disable the
Bridge
all site links
setting, see “Enable or disable site

link bridges” in Help and Support Center for Windows
Server

2003.

Creating a Site Link Bridge Design to
Control Active Directory Replication Flow

Two scenarios where you might want to control replication flow include controlling replication failover and
c
ontrolling replication through a firewall.

180

Chapter 3

Designing the

Site Topology



Controlling Replication Failover

If your organization has a hub
-
and
-
spoke network topology, you generally do not want the satellite sites to
create replication connections to other satellite sites if all domain c
ontrollers in the hub site fail. In such
scenarios, you must disable
Bridge all site links

and create site link bridges such that replication connections
are created between the satellite site and another hub site that is just one or two hops away from the

satellite
site.

Example: Creating a site link bridge design to control replication
failover

Figure

3.20 illustrates an organization’s hub
-
and
-
spoke network topology, consisting of two hub sites (A and
B) and six satellite sites (C through H). The site lin
ks between all sites are named A
-
B, A
-
C, A
-
D, A
-
E, B
-
F,
B
-
G, and B
-
H.

Figure

3.
20

Creating a Site Link Bridge to Control Replication Failover


Cr eating a

Site Link Bridge Design

181



With
Bridge All Site Links

enabled, if DC
-
1 in hub site A fails, DC
-
3 can create replication connections
betw
een DC
-
2, DC
-
4, DC
-
5, DC
-
6, DC
-
7 or DC
-
8. The only intended connection for DC
-
3 in this case is
with DC
-
2 in hub site B, as this connection will not congest network traffic. To ensure that DC
-
3 only
replicates with DC
-
2 when DC
-
1 fails, you can disable sit
e link transitivity and create the AC
-
AB site link
bridge between the A
-
C and B
-
C site links. Similarly, you can create the AB
-
BH site link bridge between the
A
-
B and B
-
H site links. With the AC
-
AB site link bridge, if DC
-
1 is unavailable, the replication
connections
from DC
-
3 are created only with DC
-
2 in hub site B. With the AB
-
BH site link bridge, if DC
-
2 is
unavailable, the replication connections from DC
-
8 are created only with DC
-
1 in hub site A. Create similar
site link bridges between all satellite
sites so that the KCC failover occurs only to the domain controllers at
the hub sites.

Controlling Replication Through a Firewall

If two domain controllers representing the same domain in two different sites are specifically allowed to
communicate with eac
h other only through a firewall, you can disable
Bridge all Site Links

and create site
link bridges for sites on the same side of the firewall.

Example: Creating a site link bridge design to control replication
through a firewall

Figure

3.21 illustrates a
similar scenario as shown in Figure

3.20, but in this case a firewall separates hub site
A and hub site B. IPSec is used to replicate through the firewall. The IPSec policy allows only DC
-
1 and DC
-
2 to communicate through the firewall by using IPSec. With
transitivity enabled, if DC
-
1 fails, then DC
-
3 in
satellite site C can create replication connections not only with DC
-
4 and DC
-
5 as intended, but it can try to
create replication connections across the firewall with DC
-
2, DC
-
6, DC
-
7, or DC
-
8.

To ensure th
at DC
-
3 directly replicates only on one side of the firewall, you can disable transitivity and
create the WEST site link bridge, which includes site links A
-
C, A
-
D, and A
-
E. Creating the WEST site link
bridge ensures that if domain controller DC
-
1 fails, D
C
-
3, DC
-
4, and DC
-
5 directly replicate only with each
other and not with DC
-
2, DC
-
6, DC
-
7, or DC
-
8. Similarly, you can create the EAST site link bridge, which
includes site links the B
-
F, B
-
G, and B
-
H, to ensure that if DC
-
2 fails, then DC
-
6, DC
-
7, or DC
-
8

directly
replicate only with each other.

182

Chapter 3

Designing the

Site Topology



Figure

3.
21

Creating Site Link Bridges to Control Replication Through a Firewall


Therefore, if your network is separated by firewalls, it is recommended that you disable transitivity of site
links and create s
ite link bridges for the network on one side of the firewall.

Additional Resources

These resources contain additional information and tools related to this chapter.

Related Information



“Designing the Logical Structure” in this book.



“Planning Domain Contro
ller Capacity” in this book.



“Deploying the Windows Server

2003 Forest Root Domain” in this book.



“Deploying Windows Server

2003 Regional Domains” in this book.



“Deploying DNS” in
Deploying

Network Services
of this kit.



The Active Directory Branch Office P
lanning Guide link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for a complete guide to
information involving Active Directory branch office implementations.

Additional Resources

183



Related Tools



Adlb.exe

You can use ADLB to improve replicat
ion efficiency in forests set to Windows Server

2003
functional level. For more information about ADLB, see “Tools and Technical References”
on the Web at the http://www.microsoft.com/reskit.

Related Help Topics

For best results in identifying Help topics
by title, in Help and Support Center, under the
Search

box, click
Set search options
. Under
Help Topics
, select the

Search in title only

checkbox.



“Active Directory” in Help and Support Center for Windows Server

2003.



“Enable printer location tracking” in
Help and Support Center for Windows Server

2003.



“Create a shortcut trust” in Help and Support Center for Windows Server

2003.




Cache universal group memberships
” in Help and Support Center for Windows
Server

2003.



“Create a site” in Help and Support Cente
r for Windows Server

2003.



“Create a subnet” in Help and Support Center for Windows Server

2003.



“Associate a subnet with a site” in Help and Support Center for Windows Server

2003.



“Enable or disable site link bridges” in Help and Support Center for Windo
ws Server

2003.

Related Job Aids



“Geographic Locations and Communication Links” (DSSTOPO_1.doc) on the

Windows
Server

2003 Deployment Kit
companion CD (or see “Geographic Locations and
Communication Links” on the Web at http://www.microsoft.com/reskit).



“L
ocations and Subnets” (DSSTOPO_2.doc) on the

Windows Server

2003 Deployment Kit
companion CD (or see “Locations and Subnets” on the Web at
http://www.microsoft.com/reskit).



“Domains and Users in Each Location” (DSSTOPO_3.doc) on the

Windows Server

2003
Dep
loyment Kit
companion CD (or see “Domains and Users in Each Location” on the Web
at http://www.microsoft.com/reskit).



“Domain Controller Placement” (DSSTOPO_4.doc) on the
Windows Server

2003
Deployment Kit
companion CD (or see “Domain Controller Placement”

on the Web at
http://www.microsoft.com/reskit).



“Sites and Associated Site Links” (DSSTOPO_5.doc) on the
Windows Server

2003
Deployment Kit
companion CD (or see “Sites and Associated Site Links” on the Web at
http://www.microsoft.com/reskit).



“Associating

Subnets with Sites” (DSSTOPO_6.doc) on the
Windows Server

2003
Deployment Kit
companion CD (or see “Associating Subnets with Sites” on the Web at
http://www.microsoft.com/reskit).