06 chapter 3 designing the site topologyonline.aoi.edu.au/documents/1360208683lr9.pdf · 138...
Post on 13-Jul-2020
7 Views
Preview:
TRANSCRIPT
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 sites, 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 Bridge Design .................................................................................................. 178
Additional Resources ......................................................................................................................... 182
Related Information
For more information about designing the Active Directory logical structure and the DNS
infrastructure needed to support Active 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 2003 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
well-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 locations 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 network 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 your 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 assist you in designing the site
topology, see “Additional Resources” later in this chapter.
Overview of Designing 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 network 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, the 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 replication, 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 compressed 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 another 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 affiliation 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 controller 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 located 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 controllers 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 controller, 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 that 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 Directory 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 printer 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 network 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 capacity 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 Topology
Network Topologies An organization’s network topology reflects its 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, well-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 Before 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 controller 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 the 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) creates 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 object.
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 (intrasite) 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.
Within 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 means 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 Windows 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 other 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 automatically 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 replicate 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 directions 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 domain 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 builds 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 another 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 network 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 usage 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 the 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 specific 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 controllers (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 server. 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 addition, 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 replicating 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 the 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 that 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 distinct 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 represent 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 bridge 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 more 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 controller 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 contain 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 interim 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 replication 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 implements 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 specific 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 Server 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 membership 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 site 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.
Collecting 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 ―Setting 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. Available 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 Monitor, 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 linked 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
Windows 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
between 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 available 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 comparing 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 represented 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 location 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 represented 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 Example 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.
Planning Domain Controller Placement 153
Figure 3.9 Planning Domain Controller Placement
Although 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 controllers 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 resources 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 domains. 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 worksheet, 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 2003 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 whether 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 satellite locations. Eliminating unnecessary regional domain controllers from satellite
locations reduces the support costs required to maintain a remote server infrastructure.
Planning 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 Physical 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 organizations, 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
If 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 domain controller at that
location.
Planning 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 contains 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 the 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 redirection, 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 changing 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 placing 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 of 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, centralize 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 represented 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
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 regional domain controllers
when you deploy regional domains. For more information 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
Planning 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 is 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 whenever 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 include 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 enable 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 universal 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 Domain 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 and 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. However, 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 security 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.
Operations 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. Additionally, 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 original role holder fails. Ensure that the standby operations master is a direct
replication partner of the actual operations master.
Planning 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 does 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 the 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 the
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 server 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 domain 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 emulator 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
password 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 password, 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 needed. 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 which 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 master 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 second 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 the 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 information 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 global 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 domain 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
infrastructure 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 domain.
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 Windows 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 you 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 role 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).
Planning 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 forest 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 domain,
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, number 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 PDC 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 hosting 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 domain 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 domain 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 respectively, 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.
Because 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 in 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 controllers 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.
Creating a Site Design 165
Global 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 location
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 site 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 Design
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 worksheet, 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 objects 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.
Creating a Site Design 167
Document those locations that will become sites and the 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 Sites‖ 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 ―Associating 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 location, 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
Subnets 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 notation 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 Windows 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: Associating 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 potential 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 are 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 to 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.
Figure 3.16 shows the process for creating a site link design.
Creating 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 addition, 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 Directory
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 default-
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
locations 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 Locations 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 site 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
replication 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 enterprise 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_of_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.
Creating a Site Link Design 171
Figure 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 schedule 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 replication 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 usually 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 Geographic 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 Bandwidth‖ 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 Variable 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 second (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.
Creating 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 two 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 according 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 example, 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.
Consider 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 the 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
Washington DC
Seattle 0.25
Boston 0.25
Los Angeles
0.25
New York 0.25
Washington DC
0.25
An average, worst-case latency within a site is estimated to be 15 minutes.
Creating 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 between 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 delay 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 between 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)) as shown in Table 3.4.
Table 3.4 Maximum Latency (in Hours) of Replication Between Sites
Seattle Boston Los
Angeles New York
Washington 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 assigned 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 the 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
sites 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 controller 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 and 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, based 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 between 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 example, 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.
Creating a Site Link Design 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 never 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 cannot establish direct connections between domain controllers in the sites that are connected by
the same site link bridge.
Creating 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 Bridge 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 nontransitive, 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 information 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 Networks 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
controlling 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 controllers 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 links 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
Creating 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
between 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 site 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 each 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 that 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, DC-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 site 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 Controller 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 Planning 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 replication 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 Center 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 Windows 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).
―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).
―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).
―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).
top related