06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138...

48
CHAPTER 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

Transcript of 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138...

Page 1: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 2: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 3: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 4: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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).

Page 5: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 6: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 7: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 8: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 9: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 10: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 11: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 12: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 13: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 14: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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).

Page 15: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 16: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 17: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 18: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 19: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 20: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 21: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 22: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 23: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 24: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 25: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 26: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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).

Page 27: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 28: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 29: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 30: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 31: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 32: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 33: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 34: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 35: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 36: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 37: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 38: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 39: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 40: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 41: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 42: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 43: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 44: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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

Page 45: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 46: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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.

Page 47: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing

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).

Page 48: 06 CHAPTER 3 Designing the Site Topologyonline.aoi.edu.au/documents/1360208683LR9.pdf · 138 Chapter 3 Designing the Site Topology Overview of Designing a Site Topology Designing