Transcript Module 6: Designing an Active Directory Site Topology

Module 8: Designing an
Active Directory Site
Topology
Overview

Using Sites in Active Directory

Assessing the Need for Active Directory Sites

Using Site Links in a Network

Planning the Inter-Site Replication Topology

Planning for Server Placement in Sites

Sites are used to organize well-connected computers
within an organization to optimize network bandwidth.
Excessive network traffic can occur between remote
locations due to frequent exchange of large amounts of
data and directory information. Designing an
appropriate site topology in Microsoft® Windows® 2000
Active Directory™ directory service helps you better
organize your Windows 2000 network and optimize the
exchange of data and directory information.
At the end of this module, you will be able to:

Describe the purpose of sites and their role in Active
Directory replication.

Assess the need for Active Directory sites.

Plan for the creation of site links and site link bridges.

Plan an inter-site replication topology.

Plan for server placement in sites.
 Using Sites in Active Directory
Sites Control:
 Workstation logon
traffic
 Replication traffic
Redmond Site
192.168.4.0
 Dfs topology
 FRS
 Other Site-Aware
Applications
Paris Site
192.168.2.0
192.168.3.0
nwtraders.msft

A site is a collection of well-connected machines, based
on Internet Protocol (IP) subnets. You use sites in Active
Directory to define the physical structure of your
network. A site consists of one or more subnets. For
example, if a network has one subnet in Redmond and
two subnets in Paris, the administrator can create one
site in Redmond and one in Paris, and add the subnets
to the local sites. Sites may contain domain controllers
from one or more domains.

You can use sites to optimize network bandwidth in the
following ways:

Workstation logon traffic. When a user logs on,
Windows 2000 searches for a domain controller in the
same site as the workstation.

Replication traffic. When a change occurs in Active
Directory, sites can be used to control how and when
the change is replicated to domain controllers in
another site.

Distributed file system (Dfs) topology. When a shared
file or folder has multiple locations, a user will be
directed to a server in his or her own site, if one exists.
Localizing the availability of servers in a site reduces
traffic across slow links.

File Replication service (FRS). FRS is used to replicate
the contents of the SYSVOL directory, which includes
logon and logoff scripts, Group Policy settings, and
system policies for Windows 95, Windows 98 and
Windows NT® version 4.0. FRS uses sites to determine
its replication topology.

By using other site-aware applications. A site-aware
application is a directory-enabled application that
connects a client with a server in its own site, if the
server is available there. As third party applications are
developed, they may also make use of sites to allow
clients to connect to shares within their own sites. Dfs
and FRS point clients to servers within their site before
pointing them to servers outside their site.
Active Directory uses site information in the following
ways:

The Knowledge Consistency Checker (KCC) generates a
replication topology that is primarily used within sites
rather than between sites. This intra-site topology may
increase network traffic, but will reduce replication
latency.

Windows 2000 client computers use site information to
find nearby domain controllers for logon and query
operations.
Factors Affecting Replication
 Replication latency
 Replication efficiency
 Replication cost
nwtraders.msft
Inter-Site
Replication
Redmond
Charlotte
Intra-Site
Replication

To optimize network bandwidth during replication, you
must consider the factors that affect replication. The
three significant replication factors include:



Replication latency. The time needed for one domain
controller to receive a change made on another
domain controller.
Replication efficiency. The ability to batch together
the number of changes sent with each update.
Replication cost. The amount of bandwidth needed
to replicate the changes between domain
controllers.

In a given network, optimizing one of these replication
factors will impact the other factors. For example, a
frequent replication interval lowers the replication
latency and raises the replication cost and efficiency.
Intra-site Replication

Replication latency within a site is low, because of the
high network bandwidth available within a site. Low
latency ensures that users within the site will have
access to the most recent information at all times.
Replication within a site will take place five minutes
after a change has occurred. The originating server will
notify its replication partners of the change, and they
will, in turn, request the change.
Inter-site Replication

Usually there is limited bandwidth available for
replication between sites. Before being replicated, data
is compressed to about 10 percent of original volume to
reduce the amount of data on the network. To optimize
the limited network bandwidth and replication efficiency
even more, you can raise replication latency by
scheduling when replication will occur between sites.
 Assessing the Need for Active Directory Sites

Planning Domain Controller Placement

Evaluating Connectivity and Available Bandwidth

Determining Replication Traffic

Before planning the site topology of a network, you
need to assess the need for sites in the network. The
unnecessary addition of sites in a network may result in
replication across slow links and inefficient use of
network bandwidth. There are several factors that will
determine where site locations are required:

Available bandwidth

Anticipated replication traffic

Placement of domain controllers

Begin the site design process by documenting the
existing network infrastructure. Document the types of
links between physical locations, the amount of
available bandwidth, and the number of users and
computers at each location.
In this lesson you will learn about the following topics:

Planning domain controller placement

Evaluating connectivity and available bandwidth

Determining replication traffic
Planning Domain Controller Placement
 At Least One Domain
Controller Per Site for Best
Performance
 For Sites with Few Users,
Use a Slow Link
Philadelphia
 Total – Used = Net Available
Pittsburgh
Allentown
nwtraders.msft

The first step in planning a site structure is to determine
where a domain controller is required. A domain
controller must be able to respond to client requests in
a timely manner that suits the requirements of the
clients. For best performance, place at least one domain
controller in each site that contains users or computers
of that domain. With a domain controller at each
location in your network, all users will have a local
computer that can service query requests for their
domain over local area network (LAN) connections.

In some situations, however, it may make sense not to
place a domain controller at each location. For example,
if there is a location with only ten users, you may decide
it is a better use of the available bandwidth to have
those users log on and query the directory over a slow
link.

To help determine domain controller placement, identify
potential speed and net available bandwidth by using
the equation total - used = net available, where total
refers to the total bandwidth available to the network,
used refers to the bandwidth that is being used up by
the network, and net available bandwidth refers to the
bandwidth available to other applications.
Evaluating Connectivity and Available Bandwidth

Connectivity



Fast, Reliable, Inexpensive
If Use is Low Between Locations, Slower Connectivity
May Be Sufficient
Available Bandwidth


Amount of Connectivity Use
If Use is High Between Locations, Consider Separate
Sites

You need to examine connectivity and available
bandwidth when grouping subnets into sites. The
decision to combine multiple subnets to form a
Windows 2000 site is a function of both well-connected
subnets and networks with a lot of available bandwidth.
Connectivity

Only combine subnets that are connected by fast,
inexpensive, and reliable links into a site. The definition
of a fast link will vary from organization to organization,
but a Windows 2000 site should be connected with links
of 10 Megabits per second (Mbps) or greater. For
example, a slow connection, such as a 56Kbit/s RAS
connection, is sufficient if changes happen rarely.
However, if employee turnover at an organization is high
and group memberships change daily, even a mediumsized domain might take up considerable bandwidth on
a 128 Kbps link.
Available Bandwidth

Available bandwidth is also an important consideration
in determining a site plan, because a connection that is
fast, inexpensive, and reliable may be heavily used. For
example, you may consider a 1.544-megabit network
connection between two locations fast, inexpensive,
and reliable. However, if 75 percent of this connection is
used without any traffic from Active Directory or users
logging on, it may be desirable to control the replication
traffic and logon requests that use this connection.
Even though the connection between locations is fast,
inexpensive, and reliable, it still may be advantageous
to create sites on both sides of the connection.
Determining Replication Traffic

Compression Occurs Once Traffic Exceeds 50KB

Use Active Directory Sizer to Determine Replication
Traffic

Size of Organization Is Poor Indicator of Traffic

Increasing Latency Can Also Increase Efficient Use of
Network

When assessing the need for sites, consider the estimated amount
of traffic that replication will generate. Replication between sites is
compressed, but only when the amount of traffic exceeds 50,000
bytes (50KB). Use the Active Directory Sizer utility available in the
Windows 2000 Server Resource Kit to determine replication traffic.

The size of an organization is not a good indicator of traffic. For
example, a medium-sized organization may have regular staff
changes, which will generate a significant amount of replication
traffic, whereas a large organization may be fairly stable, with few
changes occurring on a regular basis. If there are only very small
changes occurring, inter-site replication may cause increased
traffic because of the need to refer to additional naming contexts
outside the site.

You can increase network efficiency by increasing
replication latency. Increasing latency will increase the
amount of traffic, but once the level of traffic exceeds
50KB, it is compressed, thereby reducing overall traffic.

Note: Less information is replicated between domain
controllers of different domains than between domain
controllers in the same domain. The global catalog
server replication only replicates a subset of the object
attributes.
 Using Site Links in a Network
Site Links Are Defined By:

Transport

Member Sites

Cost

Schedule
Paris
Site Link: Par-Cha
56KB WAN Link
ATM Backbone
Charlotte
Redmond
Site Link: Red-Cha-Atl
Inter-Site Topology Spans All
Sites in a Network
Atlanta

The connection between two sites is defined as a site
link. Site links can be used for replication. Planning site
links involves considering the best replication path and
the replication schedule between sites. Replication
paths can be prioritized by assigning costs to different
replication paths.
Lesson Overview
Site links are defined by the following components:

Transport. The transport defines the type of protocol
used, either RPC over IP or SMTP.

Member sites. Two or more sites to be connected by the
site link.

Cost. A number that determines which site link will be
used for replication when there are multiple site links
between two locations.

Schedule. The times when replication will occur.
Lesson Overview

A typical site link connects two sites only and corresponds to a
wide area network (WAN) link, although it could correspond to a
backbone, which connects several sites together. Sites are
connected by different network technologies, such as a T1 line,
network, or dial-up link. Each site in a multiple-site environment
must be connected by at least one site link. Otherwise, domain
controllers within a site will not be able to replicate with domain
controllers in any other site.

Inter-site replication topology spans across all sites in the
organization. As long as a replication route can be constructed
between all sites in the enterprise, the replication topology is
functional. You can create site links that allow domain controllers
from any site to communicate with domain controllers in any other
site.
Planning Site Link Schedules and Costs
Control Topology by:

Setting Costs

Scheduling Availability
Paris
Red-Par Site Link
Cost=500
Available 7 PM to 1 AM
Redmond
Red-Atl Site Link
Cost=300
Available 8 PM to 6 AM
Cha-Par Site Link
Cost=500
Available 7 PM to 2 AM
Charlotte
Red-Cha-Atl Site Link
Cost=1
Available At All Times
Atlanta

Site links are based on the cost of replication, which
reflects the speed and reliability of the underlying
network, and its schedule, which defines a time period
when replication is allowed over the link.
Site Link Schedules

You have the option of controlling when replication will
occur between sites. Unlike intra-site replication, intersite replication does not use a notification process.
Because there is no notification between the replication
partners, a domain controller must check all replication
partitions on the originating domain controller.Try to
schedule inter-site replication when bandwidth
utilization is low. For example, you may schedule the
link to be used only outside of regular business hours.
However, this scheduling will increase replication
latency, and you may decide that updating once a day is
unacceptable. You can offset the increase in latency by
scheduling replication to occur only once an hour.

When setting schedules, be aware of connections that
use multiple site links. For example, you may have a
domain that resides in three sites, A, B, and C. If the site
link for AB is available from 9 p.m. to 1 a.m., and the site
link for BC is available from 2 a.m. to 6 a.m., the
replication partners in A and C will never replicate
directly with each other.
Site Link Cost

Site link cost is a number that represents the priority an
organization assigns to replication traffic between the sites
identified in the site link. For example, an IP site link named RedCha-Atl connects three sites, Redmond, Charlotte, and Atlanta, with
a cost of 1. This tells Active Directory that an IP message can be
sent between all pairs of sites with a cost of 1.
Higher cost numbers represent lower priority replication paths. If
there are multiple site links between two sites, Active Directory
replication will use the link with the lowest cost that is available. For
example, if there is a site link named Red-Cha-Atl that connects
Redmond and Charlotte with a cost of 1, and a site link called RedCha that connects Redmond and Charlotte with a cost of 300, any
replication will attempt to use the Red-Cha-Atl link first.
Options for Controlling Site Links

Any number of site links can connect a site to other
sites. Each site in a multi-site directory must be
connected by at least one site link. You can control and
schedule each site topology independently.
You can control:

Topology by setting the costs on site links. In a common scenario
you might set cost = 1 for site links that are part of your backbone
network, and cost = 100 for site links corresponding to slow
connections to branch offices. Setting costs in this way ensures
that a branch office replicates with a domain controller in a site that
is part of the backbone, never directly with a second branch office.

Replication frequency by setting the number of minutes between
replication attempts on site links. In a common scenario you might
set the global default replication frequency to 15 minutes, and set a
longer frequency on site links corresponding to slow connections
to branch offices. The longer frequency makes more efficient use of
the link but increases replication latency.

Link availability by using the schedule on site links. You would use
the default schedule of 100 percent availability on most links, but
you could block replication traffic during peak business hours on
links to certain branches. By blocking replication, you give priority
to other traffic but increase replication latency.
Assessing the Need for Site Link Bridges
Paris
Par-Red Site Link
Cost = 2
Red-Cha-Atl
Site Link Bridge
Cost = 7
Redmond
Red-Cha Site Link
Cost = 3
nwtraders.msft
Charlotte
Cha-Atl Site Link
Cost = 4
Atlanta

site link bridge connects two or more sites together by
using multiple site links. Site link bridges model the
routing behavior of a network. By default, all site links
are considered transitive. That is, all site links for a
given transport will implicitly belong to a single site link
bridge for that transport. This means site link bridges
are not necessary in fully routed IP networks.

If your IP network is not fully routed, the transitive site
link feature for the IP transport can be turned off. This
will result in all IP site links being considered
intransitive, so site link bridges will need to be
configured to model the actual routing behavior of the
network. Specifying two or more site links creates a site
link bridge object for a specific inter-site transport,
typically RPCs over IP.
For example:

Site link Red-Cha connects sites Redmond and
Charlotte through an IP with a cost of 3.

Site link Cha-Atl connects sites Charlotte and Atlanta
through an IP with a cost of 4.

Site link bridge Red-Cha-Atl connects Red-Cha and ChaAtl. The site link bridge Red-Cha-Atl implies that an IP
message can be sent from Redmond to Atlanta with a
cost of 3 plus 4, or 7.

Each site link in a bridge needs to have a site in
common with another site link in the bridge. If not, the
bridge cannot compute the cost from sites in one link to
sites in other links of the bridge.

Multiple site link bridges for the same transport work
together to model multi-hop routing. Add the following
objects to the preceding example:


Site link Par-Red connects sites Paris and Redmond
through an IP with a cost of 2.
Site link bridge Par-Red-Cha connects Par-Red and
Red-Cha.

Now the site link bridges Par-Red-Cha and Red-Cha-Atl
together imply that an IP message can be sent from site
Paris to site Atlanta with a cost of 2 plus 3 plus 4, or 9.
 Planning the Inter-Site Replication Topology

Choosing Inter-Site Replication Transports

Delegating Bridgehead Servers

Examining the Inter-Site Topology Generator

Determining the Least-Cost Spanning Tree

Inter-site replication topology refers to the configuration
of replication between sites in a network. Planning
replication topology includes choosing a replication
transport and delegating bridgehead servers. The
topology will depend on the scenario in which it is being
applied. For example, a reliable network connection may
use a synchronous transport, while an unreliable
network connection may use an asynchronous
transport.
In this lesson you will learn about the following topics:

Choosing inter-site replication transports

Delegating bridgehead servers

Examining the inter-site topology generator

Determining the least-cost spanning tree
Choosing Inter-Site Replication Transports

Remote Procedure Calls (RPCs) over TCP/IP
Synchronous Transfer
Requires Reliable Connections
Generates Less Traffic
Can be Used with DCs in Same Domain

Simple Message Transport Protocol
Asynchronous Transfer
Used with Unreliable Connections
Generates More Traffic
Cannot be Used with DCs in Same Domain

You will need to select a transport method for inter-site
replication. Windows 2000 provides two transport
methods: Remote procedure calls (RPCs) and Simple
Message Transport Protocol (SMTP).
Remote Procedure Calls over TCP/IP

RPCs sent over a TCP/IP connection uses synchronous
transport. The RPC transport will appear as the IP
transport option. To send data using RPCs, a direct
connection with the replication partner must be
achieved. Thus, if the partner is unavailable, replication
will not occur. With inter-site replication, the replication
partner always pulls data in from its replication partner.
There is no notification of changes.
Simple Message Transport Protocol

SMTP sends replication data as asynchronous e-mail messages.
Since SMTP is capable of storing messages and then forwarding
them, it is the ideal transport in an unreliable network. Active
Directory allows the underlying SMTP messaging system to take
care of routing. Schedules set on a connection using SMTP are
ignored. Because the replication data must be encapsulated within
an SMTP packet, the SMTP transport generates from 80 percent to
100 percent more traffic than RPCs.

The SMTP transport supports schema configuration and global
catalog replication but cannot be used for replication between
domain controllers that belong to the same domain. This is because
some domain operations, such as Group Policy, require the support
of the FRS, which does not yet support asynchronous transport for
replication.

Note: If you plan to use SMTP, you will need to use RPC for intradomain replication. Refer to Notes from the Field by MS Press.
Delegating Bridgehead Servers
Bridgeheads for:
contoso.msft
Schema & Config
Global Catalog
contoso.msft
contoso.msft
Redmond
Schema & Config
nwtraders.msft
Global Catalog
nwtraders.msft
Bridgeheads for:
Nwtraders.msft
contoso.msft
Charlotte
nwtraders.msft

A bridgehead server is a single server in each site used
for replication between sites. Connection objects are
created between bridgehead servers. The KCC
automatically designates the bridgehead server, or you
can manually assign one for the appropriate transport
(IP for RPC over IP, or SMTP for SMTP over IP).
Manual Bridgehead Configuration

If you choose to manually configure a single domain
controller as the preferred bridgehead server for a site,
the KCC will only use that server. If that server is
unavailable, the KCC will not automatically assign
another. The KCC only chooses another bridgehead if
you have not designated a preferred bridgehead server.
However, if you have configured multiple domain
controllers in the same site as preferred bridgehead
servers, the KCC will then arbitrarily select one of these
servers.
Multiple Naming Contexts

Because a bridgehead server must be designated for each naming
context, you may need multiple bridgehead servers. For example,
you have two sites, Redmond and Charlotte, and two domains,
contoso.msft and nwtraders.msft. Each site has a domain controller
from each domain. In this case, replication of the two domain
naming contexts can occur between the two sites only if the
domain controllers for nwtraders.msft and contoso.msft are
selected as bridgehead servers in each site. Therefore, if there is a
single domain controller for a domain in a site, that domain
controller must be a bridgehead server in its site because it can
replicate domain data to only a domain controller in its own domain.
In addition, that single domain controller must be able to connect to
a bridgehead server in the other site that also holds the same
domain naming context.
Examining the Inter-Site Topology Generator
ISTG
contoso.msft
nwtraders.msft
Bridgeheads
Redmond
contoso.msft
nwtraders.msft
ISTG
Global Catalog
Schema & Config
Bridgeheads
contoso.msft
nwtraders.msft
Charlotte

Topology generation for replication between sites is more complex
than for replication within a site. In intra-site replication, the KCC
assumes any server is capable of replicating with any other server.
This is not the case with inter-site replication.
With intra-site replication, the KCC on each domain controller plays
a role in topology generation. Similarly, each site plays a role in
inter-site topology generation. One domain controller in each site
assumes the role of inter-site topology generator (ISTG). By default,
this is the first domain controller in the site. The KCC on this
domain controller is responsible for creating the connections
between the domain controllers in its site and the domain
controllers in other sites. The KCC creates inbound connection
objects between the bridgehead servers in its own site and the
other sites.

There is only one ISTG for each site, regardless of the
number of domains represented in the site. The ISTG
reviews the site topology and creates the appropriate
inbound connections for the site in which it resides.
If the ISTG determines that a connection object needs to
be modified, it makes the change to its local Active
Directory replica. The change propagates to the
bridgehead servers in the site as part of normal
replication. When the KCC on the bridgehead server
reviews the new topology, it makes the received change.
Determining the Least-Cost Spanning Tree
Type of Network Link
Proposed Assigned Cost
Backbone Link
1
T1 to backbone
200
56KB Link
500
Branch Office
International Link
1000
5000

The KCC uses a least-cost spanning tree algorithm to
determine the replication topology between multiple
sites and domains in the same forest. You set cost so
the KCC will prefer certain routes.

To maximize efficiency and minimize cost, the
replication topology must consider your network
environment, physical location, and business needs.
While the KCC generates the inter-site topology
automatically, the settings on the site links are the
factors that the KCC uses to consider the topology.

The default cost of a site link is 100. When setting costs,
try to assign the same number to similar links. For
example, if you have a T-1 connection that is at 30
percent utilization, and another T-1 at 35 percent
utilization, assign the cost of 200 to each of them.
 Planning for Server Placement in Sites

Placing Global Catalog Servers

Planning Placement of Operations Masters

Demonstration: Active Directory Sizer

A site consists of domain controllers, global catalog
servers, operation masters and bridgehead servers. For
the appropriate utilization of these servers, it is
important to plan their placement in sites. Planning
server placement includes determining the need of a
server in a network and, if it is required, determining the
number of servers that will result in optimum utilization
of the servers.
In this lesson you will learn about the following topics:

Placing global catalog servers

Planning placement of operations masters
Placing Global Catalog Servers
LDAP query
port 3289
Global
Catalog
Server
Exchange
2000
Server

In an ideal environment, there would be a global catalog
server at each site that can service query requests for
the entire directory over the LAN. However, this many
global catalog servers may significantly increase
network traffic because of the partial replication of all
objects from all domains.

Consider the following guidelines for placing global catalog
servers:



A global catalog server must have the capacity to hold partial
replicas of all objects from all other domains in the Active
Directory.
The best query performance results from placing a domain
controller designated as a global catalog server at small sites,
thereby enabling the server to fulfill queries about objects in all
domains in the Active Directory.
Once a domain has been placed in native mode, a user will be
unable to log on to the network without a global catalog server,
unless the option allowing a user to log on using cached
credentials is enabled.

Instead of placing a global catalog server at all sites,
you can place one in each major site, in a regional
Information Technology (IT) hub, or in a location on the
WAN in which a large number of people and resources
are present.
Microsoft Exchange 2000

Microsoft Exchange 2000 uses the Active Directory
directory service as its directory. All mailbox names are
resolved through queries that go through Active
Directory. When a query occurs, Exchange queries a
global catalog server. The number of queries a global
catalog server must handle can increase extensively in
a large Exchange environment. Try to place a global
catalog server in each site that contains an Exchange
server.
Planning Placement of Operation Masters
nwtraders.msft
RID Master
PDC Emulator
Infrastructure
Master
na.nwtraders.msft
Schema Master
Domain Naming Master
RID Master
PDC Emulator
Infrastructure Master
RID Master
PDC Emulator
Infrastructure
Master
sa.nwtraders.msft

Operations masters control critical single master
updates that cannot be easily resolved using multimaster replication. The placement of the operation
masters needs to be considered.
Schema Master

The schema master is the only domain controller on
which you can make schema modifications. By default,
it is the first domain controller in the Active Directory
forest. There is one schema master per enterprise.
Domain Naming Master

The domain naming master is used when domains are
added or removed from the Active Directory forest. It
allows the definition of new cross-reference objects
representing domains and external directories, and
prevents duplication of domain names. If the domain
naming master is unavailable, you cannot add or
remove domains. By default, the first server created in
the forest is the domain naming master. There is one
domain-naming master per enterprise.
Primary Domain Controller Emulator

The Primary Domain Controller (PDC) emulator replaces
a Windows NT 4.0 primary domain controller, but is
necessary in Windows 2000-based networks as well.
When a user changes his or her password, the change
is sent to the PDC emulator immediately. If a user is
unable to log on due to an incorrect password, the
authenticating domain controller always checks with the
PDC emulator before denying the logon request. If an
account is locked out, this change is also immediately
sent to the PDC emulator. There is one PDC emulator
per domain.
Relative Identifier Master

Each object created in Active Directory has a security
identifier (SID), a number unique within the domain. A
portion of that number is the relative identifier (RID). To
ensure a unique SID within a domain, each domain
controller is assigned a pool of numbers to use for the
RID of each object. The RID master assigns these
numbers to each domain controller in its domain. By
default, once a domain controller has used 450 of its
500 numbers, it contacts the RID for a new pool of
numbers. There is one RID master per domain.
Infrastructure Master

The infrastructure master for a domain is responsible for updating
the cross-domain references if the name of an object is changed.
When an object name changes, the object receives a new
distinguished name, and possibly a new SID if the object is moved to
another domain. The infrastructure master removes any
inconsistencies by matching the SID and the distinguished name of
the object with its globally unique identifier (GUID). The
infrastructure master updates these references locally and uses
replication to bring all other replicas of the domain up-to-date. If the
infrastructure master is unavailable, these updates are delayed.

It is recommended that only domain controllers that are not global
catalog servers act as infrastructure masters. A global catalog server
would not identify inconsistencies in these cross-domain references
because it has all objects in its directory database. There is one
infrastructure master per domain.
Demonstration: Using Active Directory Sizer
Lab A: Planning Sites to Control Active Directory
Replication
Review

Using Sites in Active Directory

Assessing the Need for Active Directory Sites

Using Site Links in a Network

Planning the Inter-Site Replication Topology

Planning for Server Placement in Sites