module 8: 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.


Sites Control:

Workstation logon traffic

Replication traffic

Dfs topology

FRS

Other Site-Aware Applications

Paris Site192.168.2.0192.168.3.0

nwtraders.msftnwtraders.msft

Redmond Site 192.168.4.0

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

Redmond

Charlotte

Inter-Site ReplicationInter-Site Replication

Intra-Site ReplicationIntra-Site Replication

Replication latency

Replication efficiency

Replication cost

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.


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

Philadelphia

Pittsburgh

Allentown

Planning Domain Controller Placement

At Least One Domain Controller Per Site for Best Performance

For Sites with Few Users, Use a Slow Link

Total – Used = Net Available


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 medium-sized 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.


Paris

Site Link: Par-ChaSite Link: Par-Cha

Redmond

Charlotte

Atlanta

ATM Backbone

Site Link: Red-Cha-AtlSite Link: Red-Cha-Atl

56KB WAN Link

Site Links Are Defined By:

Transport

Member Sites

Cost

Schedule

Inter-Site Topology Spans All Sites in a Network

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

Redmond

Charlotte

Atlanta

Red-Cha-Atl Site LinkCost=1Available At All Times

Red-Cha-Atl Site LinkCost=1Available At All Times

Red-Atl Site LinkCost=300Available 8 PM to 6 AM

Red-Atl Site LinkCost=300Available 8 PM to 6 AM

Paris

Cha-Par Site LinkCost=500Available 7 PM to 2 AM

Cha-Par Site LinkCost=500Available 7 PM to 2 AM

Red-Par Site LinkCost=500Available 7 PM to 1 AM

Red-Par Site LinkCost=500Available 7 PM to 1 AM

Control Topology by:

Setting Costs

Scheduling Availability

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, inter-site 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 Red-Cha-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 Red-Cha 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

Red-Cha Site LinkCost = 3Red-Cha Site LinkCost = 3

Cha-Atl Site LinkCost = 4Cha-Atl Site LinkCost = 4

Red-Cha-AtlSite Link BridgeCost = 7

Red-Cha-AtlSite Link BridgeCost = 7

Par-Red Site LinkCost = 2Par-Red Site LinkCost = 2


Redmond

Charlotte

Atlanta

Paris

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 Cha-Atl. 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.


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.


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 intra-domain replication. Refer to Notes from the Field by MS Press.

Delegating Bridgehead Servers

Charlotte

Redmond

contoso.msft

Bridgeheads for:contoso.msftSchema & ConfigGlobal Catalog

Bridgeheads for:contoso.msftSchema & ConfigGlobal Catalog

Bridgeheads for:Nwtraders.msftBridgeheads for:Nwtraders.msft

Global Catalog

nwtraders.msft

contoso.msft

nwtraders.msft

Schema & Config

contoso.msft

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

Redmond

contoso.msft

BridgeheadsBridgeheads

BridgeheadsBridgeheads

nwtraders.msft

contoso.msft

nwtraders.msft

nwtraders.msft

Charlotte

contoso.msft

Global Catalog

Schema & Config

ISTGISTG

ISTGISTG

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.

Type of Network LinkType of Network Link Proposed Assigned CostProposed Assigned Cost

Determining the Least-Cost Spanning Tree

Backbone Link 1

T1 to backbone 200

56KB Link 500

Branch Office1000

International Link 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.


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.


Placing global catalog servers

Planning placement of operations masters

Placing Global Catalog Servers

Global Catalog Server

LDAP query port 3289

Exchange2000 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

na.nwtraders.msft sa.nwtraders.msft

Schema MasterDomain Naming MasterRID MasterPDC EmulatorInfrastructure Master

RID MasterPDC EmulatorInfrastructure Master

RID MasterPDC EmulatorInfrastructureMaster

Operations masters control critical single master updates that cannot be easily resolved using multi-master 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






module 8: designing an active directory site topology

Documents

site information

active directory sites

active directory replication

appropriate site topology

use of sites

directory information

creation of site links

msft redmond site