Site Plan (Book 4 of 5)

© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents

1. INTRODUCTION TO SITE PLAN..............................................................................................31.1. SITE PLAN OBJECTIVE......................................................................................................31.2. SITE PLAN SCOPE............................................................................................................31.3. BACKGROUND INFORMATION.............................................................................................31.4. SITE PLAN APPROACH......................................................................................................41.5. SITE PLAN PROCESSES....................................................................................................41.6. DELIVERABLES OF SITE PLAN PROCESSES........................................................................51.7. INTER-PROCESS DEPENDENCIES.......................................................................................51.8. PROCESS TO DESIGN THE SITE PLAN................................................................................72. ANALYSIS OF CURRENT AND PROPOSED NETWORK INFRASTRUCTURE.................................82.1. BACKGROUND INFORMATION.............................................................................................82.2. PREREQUISITES FOR PROCESS EXECUTION.......................................................................82.3. PROCESS COMPONENTS...................................................................................................82.4. DELIVERABLES OF PROCESS COMPONENTS.......................................................................82.5. INTER-COMPONENT DEPENDENCIES..................................................................................92.6. PROCESS TO ANALYSE THE CURRENT AND PROPOSED NETWORK INFRASTRUCTURE...........92.7. PROCESS CONSIDERATIONS..............................................................................................93. DETERMINATION OF THE NUMBER OF SITES REQUIRED.......................................................203.1. PROCESS OBJECTIVES....................................................................................................203.2. BACKGROUND INFORMATION...........................................................................................203.3. PROCESS APPROACH.....................................................................................................223.4. PROCESS COMPONENTS.................................................................................................223.5. DELIVERABLES OF PROCESS COMPONENTS.....................................................................223.6. INTER-COMPONENT DEPENDENCIES................................................................................223.7. PROCESS TO DETERMINE THE NUMBER OF SITES REQUIRED............................................233.8. PROCESS CONSIDERATIONS............................................................................................234. DESIGN FOR DOMAIN CONTROLLERS AND GC SERVERS.....................................................354.1. PROCESS OBJECTIVES....................................................................................................354.2. PROCESS SCOPE............................................................................................................354.3. BACKGROUND INFORMATION...........................................................................................354.4. PROCESS APPROACH.....................................................................................................364.5. PROCESS COMPONENTS.................................................................................................374.6. DELIVERABLES OF PROCESS COMPONENTS.....................................................................374.7. INTER-COMPONENT DEPENDENCIES................................................................................374.8. PROCESS TO DESIGN DOMAIN CONTROLLERS AND GC SERVERS.....................................374.9. PROCESS CONSIDERATIONS............................................................................................385. DESIGN FOR PREFERRED BRIDGEHEAD SERVERS...............................................................665.1. PROCESS OBJECTIVES....................................................................................................665.2. BACKGROUND INFORMATION...........................................................................................665.3. PROCESS APPROACH.....................................................................................................665.4. PROCESS COMPONENTS.................................................................................................675.5. INTER-COMPONENT DEPENDENCIES................................................................................675.6. DELIVERABLES OF PROCESS COMPONENTS.....................................................................675.7. PROCESS TO DESIGN PREFERRED BRIDGEHEAD SERVERS...............................................685.8. PROCESS CONSIDERATIONS............................................................................................686. DESIGN FOR MAPPING OF TCP/IP SUBNETS TO SITES........................................................816.1. PROCESS OBJECTIVE......................................................................................................816.2. BACKGROUND INFORMATION...........................................................................................816.3. PROCESS APPROACH.....................................................................................................816.4. PROCESS COMPONENTS.................................................................................................816.5. INTER-COMPONENT DEPENDENCIES................................................................................816.6. DELIVERABLES OF PROCESS COMPONENTS.....................................................................816.7. PROCESS TO DESIGN THE MAPPING OF TCP/IP SUBNETS TO SITES.................................826.8. PROCESS CONSIDERATIONS............................................................................................827. DETERMINATION OF REQUIREMENTS FOR MULTIPLE SITE LINK OBJECTS............................867.1. PROCESS OBJECTIVES....................................................................................................867.2. BACKGROUND INFORMATION...........................................................................................867.3. PROCESS APPROACH.....................................................................................................87

Page 1 of 174 Last printed 28/05/2004 12:21 PM


7.4. PROCESS COMPONENTS.................................................................................................887.5. INTER-COMPONENT DEPENDENCIES................................................................................887.6. DELIVERABLES OF PROCESS COMPONENTS.....................................................................887.7. PROCESS TO DETERMINE REQUIREMENTS FOR MULTIPLE SITE LINK OBJECTS..................897.8. PROCESS CONSIDERATIONS............................................................................................898. DESIGN OF A SITE LINK TOPOLOGY...................................................................................958.1. PROCESS OBJECTIVES....................................................................................................958.2. BACKGROUND INFORMATION...........................................................................................958.3. PROCESS APPROACH.....................................................................................................968.4. PROCESS COMPONENTS.................................................................................................978.5. INTER-COMPONENTS DEPENDENCIES..............................................................................978.6. DELIVERABLES OF PROCESS COMPONENTS.....................................................................978.7. PROCESS TO DESIGN THE SITE LINK TOPOLOGY..............................................................978.8. PROCESS CONSIDERATIONS............................................................................................989. DESIGN FOR THE CONFIGURATION OF THE SITE LINK OBJECTS.........................................1099.1. PROCESS OBJECTIVES..................................................................................................1099.2. PROCESS SCOPE..........................................................................................................1099.3. BACKGROUND INFORMATION.........................................................................................1099.4. PROCESS APPROACH...................................................................................................1109.5. PROCESS COMPONENTS...............................................................................................1109.6. INTER-COMPONENT DEPENDENCIES..............................................................................1109.7. DELIVERABLES OF PROCESS COMPONENTS...................................................................1119.8. PROCESS TO DESIGN THE CONFIGURATION OF THE SITE LINK OBJECTS.........................1129.9. PROCESS CONSIDERATIONS..........................................................................................11210. DESIGN OF SITE LINK BRIDGE OBJECTS........................................................................14010.1. PROCESS OBJECTIVES................................................................................................14010.2. BACKGROUND INFORMATION.......................................................................................14010.3. PROCESS APPROACH..................................................................................................14410.4. PROCESS COMPONENTS.............................................................................................14410.5. INTER-COMPONENT DEPENDENCIES............................................................................14410.6. DELIVERABLES OF PROCESS COMPONENTS.................................................................14410.7. PROCESS TO DESIGN SITE LINK BRIDGE OBJECTS.......................................................14510.8. PROCESS CONSIDERATIONS........................................................................................14511. DESIGN FOR CUSTOM CONNECTION OBJECTS................................................................15211.1. PROCESS OBJECTIVES................................................................................................15211.2. BACKGROUND INFORMATION.......................................................................................15211.3. PROCESS APPROACH..................................................................................................15411.4. PROCESS COMPONENTS.............................................................................................15511.5. INTER-COMPONENT DEPENDENCIES............................................................................15511.6. DELIVERABLES OF PROCESS COMPONENTS.................................................................15511.7. PROCESS TO DESIGN CUSTOM CONNECTION OBJECTS................................................15611.8. PROCESS CONSIDERATIONS........................................................................................15612. DESIGN OF REPLICATION TOPOLOGIES FOR ADPS.........................................................16312.1. PROCESS OBJECTIVE..................................................................................................16312.2. BACKGROUND INFORMATION.......................................................................................16312.3. PROCESS APPROACH..................................................................................................16412.4. PROCESS COMPONENTS.............................................................................................16412.5. DELIVERABLES OF PROCESS COMPONENTS.................................................................16412.6. INTER-COMPONENT DEPENDENCIES............................................................................16512.7. PROCESS TO DESIGN REPLICATION TOPOLOGIES FOR ADPS........................................16512.8. Process Considerations............................................................................................165



1. Introduction to Site Plan

This design methodology requires the design of a single Site Plan for each required forest within a Windows Server 2003 Active Directory infrastructure for an organisation.

1.1. Site Plan Objective

The objective of the generation of a Site Plan is to assist an organisation in the generation of a design of only those components of an Active Directory infrastructure that require analysis and design at the Site level. The execution of the processes within this Site Plan will generate a design for a Site infrastructure to support the distributed replication requirements of a Windows Server 2003 Active Directory forest.

1.2. Site Plan Scope

The logical and physical boundaries of the Active Directory forest (see the Organisation Wide Plan process “determination of the boundaries and content of each required forest”) this Site infrastructure will support will define the scope of this Site Plan.

1.3. Background Information

The function of this process is to design a Site infrastructure that supports a distributed replication topology for the Active Directory database of a forest.

Active Directory provides a foundation for distributed replication of the database for the forest, and supports granular configuration and control of the routing and scheduling of replication traffic between domain controllers.

The design of a Site infrastructure is hence essential to the implementation and continued operation of a distributed Active Directory infrastructure for an organisation.

It is important to note that in addition to the control of forest-wide replication between domain controllers, the designed components of the Site Plan will exert an influence upon authentication, and other operations that rely upon the Active Directory, such as Site-aware services like Distributed File System (DFS).

The production of a Site Plan for a forest is critical to the normal operation of an Active Directory forest infrastructure. Note that a Site Plan is required for an Active Directory forest where the components of an organisation represented within the forest are currently logically and / or physically distributed, or require logical distribution via a Site Plan.

It is possible for a Site Plan to generate a logically distributed replication topology for an Active Directory forest since Sites do not necessarily map to physical locations, although the terms can become interchangeable and the distinctions between the two vague.

The Active Directory represents each Site within a forest as an object. It is possible to define a Site object as “one or more linked high-speed networks that are logically grouped via complete subnets within the TCP/IP architecture that supports the forest.”

Based upon this definition, it is hence important to understand the concept that it is possible to segregate (for example) four subnets within a single LAN into four Active Directory Sites within one office / physical location.

The objectives of this process are to assist an organisation in the identification of such requirements to allow an organisation to develop a Site infrastructure that will meet their specific business and technical requirements.



1.4. Site Plan Approach

When generating the design of an Active Directory Site infrastructure, it is necessary to consider all of the business and technical requirements and objectives, for the control of a replication topology for an Active Directory forest.

The introduction of a new Active Directory infrastructure within a mature production environment for an organisation will increase, for the majority of organisations, the volume of network traffic transmitted by the network infrastructure, unless the forest owner(s) pay careful consideration to the design of the supporting Site infrastructure.

This design methodology hence proposes the following approach to the design of a Site infrastructure to support the distributed replication of an Active Directory forest:

1. Execute a detailed analysis of the current and proposed network infrastructure for the organisation, which resides within the physical boundaries of the forest and hence corresponding Site infrastructure.

2. Determine the number of Active Directory Sites required for the forest this Site infrastructure will support.

3. Generate a design for the domain controllers and Global Catalog (GC) servers for the forest.

4. Generate a design for Preferred Bridgehead Servers, where required.

5. Generate a design for the mapping of TCP/IP subnets to Sites.

6. Determine the requirements for multiple Site Link objects

7. Generate a design for a Site Link topology

8. Generate a design for the configuration of Site Link objects

9. Generate a design for Site Link Bridge objects.

10. Generate a design for custom connection objects for inter- and intra-Site replication.

11. Generate a design for a replication topology for Application Directory Partitions (ADPs) within the forest, where required.

1.5. Site Plan Processes

Based upon the above approach, each required Site Plan, for each required Active Directory forest, consists the following processes:

Analysis of the current and proposed network infrastructure

Determination of the number of Active Directory Sites required for a forest

Design for domain controllers and Global Catalog servers

Design for Preferred Bridgehead Servers, where required

Design for the mapping of TCP/IP subnets to Sites

Determination of the requirements for multiple Site Link objects

Design of a Site Link topology

Design of the configuration of Site Link objects

Design of Site Link Bridge objects



Design for custom connection objects

Design for a replication topology for ADPs

1.6. Deliverables of Site Plan Processes

The Site Plan processes will have the following deliverables:

A detailed analysis report on the current and proposed network infrastructure for the organisation

The determined number of Active Directory Sites required for a forest, and the business and technical justifications for their requirement

The determination of the numbers and placement of domain controllers and Global Catalog servers within the Site infrastructure for the forest

The design for preferred bridgehead servers for the Site infrastructure for the forest

A design for the mapping of TCP/IP subnets to Sites

A design for Site Link objects and the Site Link topology

A design for Site Link Bridge objects

A design for custom connection objects

A design for the replication topology for each application directory partition within the forest

1.7. Inter-Process Dependencies

Each process within the Site Plan will have the following inter-process dependencies:



Site Plan – Inter-Process Dependencies for Site Plan

Design for domain controllers and GC

servers

Design for Site Link Bridge objects

Design for the mapping of TCP/IP subnets to

Sites

Design of replication topologies for ADPs

Determination of the number of Active

Directory Sites required for the forest

Conduct an analysis of the current and

proposed network infrastructure for the

forest

Design for custom connection objects

START

Design for Preferred Bridgehead Servers

Design of a Site Link topology

Determination of requirements for multiple Site Link

objects

Design for Configuration of Site

Link objects

© 2 0 0 4 M U S T A N S H I R B H A R M A L



1.8. Process to Design the Site Plan

Site Plan – Process to Execute Site Plan

NO

YES

YES

NO

Execute process “design of custom

connection objects”

Execute process “design of replication

topologies for ADPs”

END

Execute process “determination of requirements for multiple Site Link

objects”

Execute process “design of Site Link

Bridge objects”

Does the organisation

intend to create ADPs within the

forest?

Execute process “design of custom

connection objects”

Execute process “design of domain controllers and GC

servers”

Execute process “design of Preferred

Bridgehead Servers”

Execute process “design for

mapping of TCP/IP subnets to Sites”

START

Execute process “analysis of current

and proposed network

infrastructure”

Execute process “determination of

the number of Active Directory Sites required”

Is there a requirement for

>1 Site?


multiple Site Link objects?

NO


topology”YES


configuration of Site Link objects”




2. Analysis of Current and Proposed Network Infrastructure

This process requires execution by all organisations planning the design and implementation of an Active Directory forest and supporting Site infrastructure.

A component of the design of a Site Plan involves the mapping of the logical Active Directory infrastructure to the physical location(s) and network infrastructure for an organisation. In order to accomplish this, it is necessary to understand and document the current and proposed network infrastructure that will support and facilitate access to an Active Directory forest.


The network infrastructure for the organisation that will support and facilitate access to the Active Directory infrastructure will include:

All network (WAN and LAN) links that will carry Active Directory-related network traffic for the forest

All servers and clients that will generate and receive Active Directory-related network traffic for the forest

Active Directory-related network traffic includes traffic generated:

Between domain controllers for referrals of queries, replication of naming contexts, and so on

Between member servers / clients, domain controllers, and DNS servers for:

Logon

Authentication

Authorisation

DNS and LDAP queries

Object management via Group Policy objects, and so on.

2.2. Prerequisites for Process Execution

The execution of this process depends upon the results of the Organisation-Wide Active Directory Plan process “determination of the boundaries and content of each forest”. This information will assist in identification of the boundaries for the LAN and WAN infrastructures that will support the Active Directory forest, and thus define the scope for this analysis.

2.3. Process Components

The process to analyse the current and proposed network infrastructure for a forest consists of the following components:

The determination of the details of the current and proposed LAN and WAN network infrastructure that will support the Active Directory forest

The determination of the details of the architecture(s) for the network transport protocol(s) used on the network infrastructure for the forest

2.4. Deliverables of Process Components

This process will have the following deliverables:



The identification of the details of the current and proposed LAN and WAN network infrastructure that will support the forest

The identification of the network transport protocols and architecture for the network infrastructure that will support the forest

2.5. Inter-Component Dependencies

Each component of this process will have the following inter-component dependencies:

Site Plan – Inter-Component Dependencies for Process to Analyse Current and Planned Network Infrastructure

STARTDetermination of the details of the current and proposed

network infrastructure

Determination of the details of the supporting network protocol architecture(s)


2.6. Process to Analyse the Current and Proposed Network Infrastructure

Site Plan – Process to Analyse Current and Planned Network Infrastructure

START ENDExecute

A2 – A13

Execute

B1 – B2© 2 0 0 4 M U S T A N S H I R B H A R M A L

2.7. Process Considerations

Consider the following information when executing an analysis of the current and proposed network infrastructure for an organisation.

Presented within the following two sections are the considerations for this process:

1. Considerations for the determination of the details of the current / proposed network infrastructure for a forest

2. Considerations for the determination of the details of the supporting network protocol architecture(s)

2.7.1. Analysis of LAN / WAN Infrastructure

Consider the following information when executing an analysis of the current and proposed LAN and WAN network infrastructure:

Factor B1: Understanding the scope of analysis into network infrastructure

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the scope of the network infrastructure within the organisation that requires analysis to support the design of this Site Plan.

Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

The results of the Organisation-Wide Active Directory Plan process, “determination of the boundaries and content of each required forest” will define the scope of analysis for this process.

It is hence necessary to examine the results of this process, and ensure all analysis, for this Site Plan and the corresponding forest this plan supports, is restricted to the defined logical and physical boundaries.



Factor B2: Understanding the types of LAN and WAN network infrastructures

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has:

A mixture of LAN and WAN network infrastructures

A mixture of LAN and WAN network types


Very few organisations have simple, one network type, network infrastructures. Most organisations that have grown via mergers and acquisitions usually have a broad mixture of network types.

Identification of the types of network infrastructures within an organisation is important as the specifications and capabilities of each network type differ greatly. This can in turn influence the design for the Site infrastructure required to support an Active Directory infrastructure.

A large variety of network link types are available that range from Ethernet, Token Ring, Gigabit Fibre, and VPNs, to ATM and Frame-Relay, and so on. It is hence necessary to document the details of all the types of network links present within the network infrastructure for an organisation.

It is important to understand the distinctions between LANs and WANs. The distinctions between LANs and WANs traditionally reflect the following four factors:

The speed of the network links. LANs typically operate at network speeds of between 4Mbs (for example, Token Ring) through to 100Mbs (Ethernet), and even 1000Mbs (Gigabit). Historically, WANs operate at much slower speeds than LANs, and this is still true for the majority of organisations. However, the latest WAN speeds can rival, match, and even exceed LAN speeds.

The length of the network links. LANs have typically shorter network links (shorter than 1000m) than WANs, which may span many kilometres in length.

The cost (financial) of the network links. The network components for LANs are very inexpensive when compared to the similar components for WANs.

The ownership of the management tasks associated with these links. The majority of organisations own and manage their own LANs. However, due to the comparative high-costs for implementation and management of WANs, the ownership and management of these networks typically lies with third-party service providers.

Because of this gradual dissolution of the boundary between LANs and WANs, with respect to network link speeds, it is possible to consider and use some WANs as LANs. However, for the execution of this process, WANs and LANs will continue to be distinguished based on the other three factors, and not primarily the speed of the network links.

Factor A1: Determination of the presence and configuration of active, redundant, and backup network links between the organisation’s network segments and geographical locations.




Local Area Network (LAN) segments present within, and / or that span, one or more geographic locations

Wide Area Network (WAN) links that connect local area network segments between geographic locations

Redundant or backup LAN segments and WAN links within or between geographic locations


Within most organisations, it is possible to identify a mixture of active, redundant, and backup WAN links and LAN segments. The identification and classification of these network links is essential to the design of the Site Link infrastructure for this forest.

Using the above information, conduct an analysis to determine the following:

Identify all active LAN segments and WAN links

Identify all currently redundant LAN segments and / or WAN links

The “WAN” topology currently in use, or proposed for use within an organisation, which connects, or will connect together the physical locations where one or more components of an Active Directory forest requires representation.

All “WAN” links that an organisation has commissioned as dedicated backup network links for redundancy in case of failure of primary WAN links.

The “LAN” topology within each physical location, which will require representation within the Active Directory forest

Collate and document the results of the analyses, and generate diagrams to illustrate the results.

Factor A2: Determination of the details of the active and backup network links

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the details of all identified active and backup WAN links and LAN segments


This design methodology requires the determination and documentation of the following details for each identified network link that will carry Active Directory-related network traffic for the forest:

The current speed, committed information rates (CIRs) (for WAN links), and latency values

The details of the cable length, grade, and approximate physical paths for the wiring

For network links that are not managed by the organisation but instead by a 3rd-party service provider, the details of any service level agreements for continuity of the network links

Using the above information, execute an analysis to determine the required information for all identified network links within the boundary of the forest this Site Plan supports.



Factor A3: Determination of the net available bandwidth statistics

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the net available bandwidth statistics for all identified active and backup WAN links and LAN segments


When determining the net available bandwidth for network paths with a network infrastructure, consider the following information:

The definition of the available bandwidth for a network path is “the maximum throughput that the path can provide to a flow, without reducing the throughput of the cross traffic in the path”. Available bandwidth is sampled using a “bytes divided by dispersion” (or “bytes over time”) calculation and then filtered. Typical notations for available bandwidth for a network path would hence be “512Kbps”.

The statistics for the net available bandwidth within network links are key factors for consideration in the execution of many processes within the Site Plan.

This design methodology recommends the use of any of the proprietary or free (freeware / shareware) utilities available that can monitor network links between two points and record net bandwidth availability statistics. It is important to execute these utilities against all WAN and LAN network links during the course of low, normal, and high network utilisation, during and out of normal business hours (taking into account time zone differences for WAN / VPN links that cross time zones).

The data gathering exercise for available bandwidth analysis requires execution of a defined period, such as 1 or more weeks, to support the generation of statistically viable results. Where an organisation has identified plans to upgrade the bandwidth for a network link, then it is necessary to gather the net available bandwidth statistics prior to the upgrade, to create baseline values for comparison after the upgrade.

The use of baseline statistics for net available bandwidth are also essential for measuring the impact of Active Directory-related traffic on the network links following the implementation of the Active Directory infrastructure into the production environment of the organisation.

Using the above information, execute the following:

Select one or more utilities to analyse each in-scope LAN segment and WAN link for net available bandwidth statistics

Determine a suitable schedule for execution of an analysis into available bandwidth levels, using the selected utility / utilities

Define the minimum period for execution of the data collection by the required utilities, such as a week or longer (this design methodology does not recommend statistic collection to operate for less than one week).

Execute the analysis to determine the net available bandwidth statistics for each in-scope LAN segment and WAN link

Document the results, and note that there may be a requirement to re-execute this analysis during the pre-migration phase of the project



Factor A4: Determination of any plans for the upgrade / consolidation / decommission of any of the current network links within the security boundary for the forest


A LAN and / or WAN infrastructure that is becoming outdated and unable to meet the networking requirements for the organisation, and / or

Plans to merge with another organisation and subsequently consolidate the LAN/WAN infrastructures, and / or

Plans to scale down and hence decommission network links that may hence become redundant, and

The details of these plans are essential to the planning and design of the Site Link topology for the forest


When determining the details of proposals / current projects to upgrade, consolidate, and / or decommission any of the current network links, consider the following:

It is necessary to execute an analysis into the potential impact of plans to decommission any existing network links. For example, the removal of a network link between two or more physical locations may cause the re-direction of network traffic onto other network links, thus increasing the volume of traffic on these links.

It is necessary to execute an analysis to determine the potential impact of any plans to consolidate network links on the final, consolidated, network links. For example, the volume of traffic each consolidated network link is required to transport may be significantly beyond its designed capacities, and it may be possible to notice increases in network latencies.

It is necessary to execute an analysis to determine the specific network bandwidth requirements for each application, process, department, and so on, directly affected by a plan to upgrade a network link. For example, an organisation wishes to upgrade the capacity on a WAN link to a remote office location. It may be possible to identify that the source of the majority of bandwidth demands on this WAN link are client applications accessing the server components across the WAN link. This may influence the capability of the WAN link, even after upgraded, to support any Active Directory replication requirements of a local domain controller.

Using the above information, execute an analysis to determine the potential influence of any plans to upgrade, consolidate, and / or decommission any existing WAN links on the design for this Site Plan.

Factor A5: Determination of the feasibility to upgrade the bandwidth capacity, where possible, for the network links


WAN links that were established quite early in the organisation’s history and are now operating at maximum capacity, and



WAN links that have the potential to increase in bandwidth without significant changes in the physical infrastructure to support the WAN link, and

Wishes to determine the feasibility for upgrading the bandwidth capacity of the network links


When determining the feasibility of upgrading the bandwidth capacity of in-scope network links within the organisation, consider the following:

The upgrade of the bandwidth on any network links should take into account the future requirements for the capacity within a link. If the organisation is planning to design and implement applications and services that will use a great deal of bandwidth, such as streaming media services, then it is necessary to anticipate and consider the potential requirements for these services. It is also necessary to anticipate and consider the replication requirements for the Active Directory via inter-Site network links.

The cost to upgrade the bandwidth requires comparison to the cost of implementation of new network links with higher bandwidth capacities, from the same and other service providers. The details of the cost of upgrade of network links will become considerations within later processes in the Site Plan

Execute the following:

Identify all in-scope WAN links that may require an upgrade in bandwidth capacity

Determine the presence of any existing feasibility studies into upgrades for these WAN links. Where it is not possible to identify any existing feasibility studies, then propose the execution of an analyses into the costs and options to upgrade the links.

Factor A6: Determination of the current and proposed use for each in-scope network link

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Has identified multiple LAN segments / WAN links within the organisation, and

Wishes to determine the current and proposes use(s) for each identified network link


When determining the current and proposed use(s) for each identified network link, consider the following:

It may be possible to identify certain WAN links / LAN segments within the organisation dedicated to the support of specific users, computers, applications, processes, services, and so on.

It is important to identify these network links for inclusion and exclusion from the scope of the Site Plan. Note that the scope of exclusion may be



complete or partial exclusion, where partial exclusion implies the identification of a network link as a backup / high cost link.

Where it is possible to identify WAN links / LAN segments dedicated or almost exclusively used by specific users, computers, and so on, it is necessary to assess the potential influence on net available bandwidth via the introduction of Active Directory replication traffic. The introduction of Active Directory replication traffic to a highly utilised WAN link may generate data transfer latencies, which in turn may be detrimental to the performance of the primary users / computers of the link.


Identify all in-scope network links either formally or informally dedicated to specific applications / services, users, computers, and so on within the organisation.

Where it is possible to identify such network links, then it is important to assess their potential role in supporting Active Directory replication.

Determine the potential influence of Active Directory replication traffic on the or performance of the primary employers of the network links

Factor A7: Determination of the current and proposed placement and configuration of network devices


Has a LAN / WAN network infrastructure that hosts multiple network devices such as routers, switches, modems and so on, which will participate / carry Active Directory-related network traffic, and

Wishes to determine the details of their logical and physical placement and configuration within the network infrastructure


The design for routing of Active Directory replication traffic across the network infrastructure relies upon a detailed understanding of the following information for all network devices (routers, switches, hubs, and so on)

Their placement (logical and physical) within the network infrastructure and organisation

Their specification and model

Their configuration (high-level), to illustrate (for example) for a router, the following information:

The routing tables and the network segments the router links

The routing protocols used (RIP, OSPF, and so on)

The IOS version, and so on

Using the above information, execute an analysis to determine the following:

The details of all network devices potentially involved in the routing of Active Directory replication network traffic



Collect, document, and illustrate all identified information in a detailed network diagram that correlates both the physical and logical aspects of the network infrastructure.

Factor A8: Identification of users with remote access requirements for Active Directory-controlled resources / services


Has users that work from home or are mobile and are provided with remote access mechanisms (such as dial-up accounts / VPN configurations and so on) to gain access to Active Directory controlled resources and services, and

Wishes to determine all details of their remote access requirements to Active Directory-controlled resources and services


The design of a Site Plan must accommodate all access requirements to the Active Directory and resources and services controlled by the Active Directory. Mobile and home users that require access to Active Directory-controlled resources are required to authenticate to the Active Directory. Their point of entry into the internal network infrastructure for the organisation (via direct dial-up or via VPN connections, and so on) will hence represent a concentrated source for authentication requests.

When determining the details of all remote access requirements, execute the following:

Determine the numbers and distribution of these remote access users

Determine the details of the network and authentication infrastructure currently supported / required by the organisation for remote access to Active Directory-controlled resources / services

Factor A9: Identification of any current issues associated with the network infrastructure


Is able to identify the presence of one or more network issues that require resolution prior to the implementation of the Active Directory infrastructure, and

Failure to resolve these networking issues may influence execution of normal Active Directory operations


It is important to identify and resolve / action all issues associated with the network infrastructure prior to the implementation of a distributed Active Directory infrastructure.

This design methodology recommends the execution of an analysis to gather and document the following information:

The details of all currently unresolved network issues within the organisation



The details of the nature of each identified networking issue

The details of any existing action plans and timescales for resolution of these issues

2.7.2. Analysis of Network Transport Protocol Architecture

Consider the following information when executing a detailed analysis into the network protocol architecture within the organisation:

Factor A10: Determination of the details of the network protocols and protocol gateways currently in use and proposed for implementation within the network infrastructure


Has multiple network transport protocol currently in use within the network infrastructure for the organisation, such as IPX/SPX and TCP/IP and so on, and / or

Has protocol gateways that link together different network transport protocols, and

Wishes to determine the details of the network protocols and protocol gateways currently in use, and proposed for implementation with the organisation


When determining the details of the network protocols and protocol gateways currently in use and planned for implementation, this design methodology proposes determination of the following information:

The number of different transport protocol currently in use

The details of any plans to consolidate to a pure TCP/IP network infrastructure

The details of the functions and architecture of the non-TCP/IP transport protocols

The details of the scope of implementation within the network infrastructure of the organisation of the non-TCP/IP transport protocols (such as limited to three out of 20 physical locations)

The details of any protocol gateways currently in use and their distribution within the network infrastructure for the organisation

Factor A11: Determination of the details of the current and proposed TCP/IP architecture(s) within the network infrastructure


Has one or more TCP/IP architectures currently in use within the organisation, and

Wishes to determine all relevant details for each identified TCP/IP architecture




When determining the details for all identified TCP/IP architectures, within the scope of this Site Plan, this design methodology proposes determination of the following information:

Determine whether one or more TCP/IP architectures are purely internal or Internet-facing, employing Internet-registered IP addresses

Determine the subnet mask architecture(s)

Determine the following IP address information:

The total number of IP addresses available within this architecture

The number of IP addresses currently in use and those currently not in use / reserved for future requirements

Determine the details of the scalability of the current TCP/IP architecture based upon predicted growth statistics / merger or acquisition plans of the organisation

Document the identified details of all TPC/IP architectures, and the details of all supporting network infrastructure components.

Factor A12: Determination of the requirements to consolidate multiple TCP/IP architectures


Has multiple TCP/IP architectures, developed through mergers / acquisitions, or because of the lack of scalability of earlier architectures, and

Is considering the requirement to consolidate the multiple TCP/IP architectures to either a new version 4 architecture or a new version 6 architecture


Where it is possible to identify plans to consolidate multiple TCP/IP architectures, then this design methodology requires determination of the following information:

Determine the details of the feasibility studies for any plans to consolidate multiple TCP/IP architectures. Many applications and services can be hard-coded to connect to specific IP addresses and the tasks and timescales required to identify these instances and change these settings to new IP addresses should not be underestimated.

Determine the details of the action plans and timescales for the TCP/IP consolidation project

Determine the details of the design for the final proposed TCP/IP architecture(s)

Factor A13: Determination of the details of any VLANs configured within switches on the network infrastructure




Currently employs the use of VLANs within switches on the network infrastructure, which reside within the scope of the Active Directory forest, and

Wishes to determine the details of the virtual LAN segments


Where it is possible to identify the presence of one or more VLAN infrastructures within the organisation, then this design methodology proposes determination of the following information:

Determine the function of each VLAN

Determine the number of IP addresses assigned to each VLAN

Determine the number of IP addresses that are currently in use within the VLAN, and the number of IP addresses that are available / reserved for use

Identify all computers and network devices supported by each identified VLAN



3. Determination of the Number of Sites Required


3.1. Process Objectives

The objectives of this process are to assist an organisation in the determination of the number of Active Directory Sites required for the Site Infrastructure.

The execution of this process, to determine the number of Sites, is essential not only to support distributed Active Directory replication, but also to support many other applications and services that rely upon a Site infrastructure for operation.

This process is hence required to consider the Site design requirements for Active Directory and all other applications and services within an organisation that will use the Site infrastructure.


Prior to the execution of this process, it is important to understand the following:

1. High-level overview of Active Directory Sites

2. Terminology used within this process

3.2.1. Overview of Active Directory Sites

The following facts are pertinent to the execution of this process:

The Site infrastructure for a forest (as a derivative of the Site Plan) will provide the design for the rules and logical infrastructure that will control the following aspects of an Active Directory forest:

Replication of the Active Directory naming contexts (NCs) within a forest, which will include the naming contexts for all the Active Directory domains within the forest and any application directory partitions (ADPs) that are created within a forest.

Replication of the SYSVOL volume for each domain within the forest (utilises the File Replication Service (FRS) to replicate changes in the Group Policy Objects (GPOs))

The point of access by clients of Site-aware services to services published within the Active Directory such as the Kerberos Key Distribution Centre (KDC) (for authentication) and the (Distributed File Service (DFS)

A Site infrastructure will provide support for the existing or planned installations of Active Directory aware applications such as Systems Management Server (SMS) 2003. Recommendations for the design of an SMS 2003 infrastructure require use of Active Directory Sites to define the SMS Site boundaries. Adoption of this recommendation allows SMS administrators to split or combine IP boundaries based on logical, not physical, criteria, and provides the advantage that subnet changes or additions made within an Active Directory site do not require additional configuration in SMS 2003. Hence, the Active Directory site boundaries for SMS 2003 automatically reflect all changes to the Subnet-to-Site mappings within the Active Directory Site infrastructure.

Active Directory represents a Site as an object and is stored within the Configuration partition for a forest. Hence, it is:

Independent of any domain or domain hierarchy within the forest



Able to be referenced by any domain controller within the forest

The Site infrastructure for a forest can represent the physical topology or a hybrid of the physical and logical topologies of an organisation.

3.2.2. Terminology Used Within This Process

Prior to the determination of the number of Sites required, it is important to understand the following terminology used in this process, and the context of their use, to prevent any misunderstandings:

A “physical location” may represent an office or other fixed and / or mobile location, such as an oil rig or a marine vessel, which supports users and computers that:

Belong to the organisation and have Active Directory domain accounts assigned to them

Will authenticate against the Active Directory using their domain accounts

Will access resources controlled by the security infrastructure of the Active Directory

A “Wide Area Network (WAN) link” refers to a communications link that, as part of the network topology for an organisation, permits network connectivity between one physical location and another. The connection may be directly between the locations, or via a Service Provider, across the Internet as a Virtual Private Network (VPN), and so on. The form factors for WAN links range from leased lines and dial-up connections to optical, wireless and satellite connections. With the evolution of the technologies that are the foundations of WAN links, and the reductions in their cost of deployment and use, the typical WAN links that are available today can rival LAN connections in speed (bandwidth), availability, quality, and resilience. It is hence possible to see a blurring between the boundaries and classification of LAN and WAN infrastructures.

A “LAN segment” refers to one or more TCP/IP subnets, on a high speed network, separated from other LAN or WAN links via routers.

“Net available bandwidth” refers to actual levels of available bandwidth capacity a network link supports, whilst carrying routine network traffic. For example, although a WAN link may advertise a bandwidth of 10Mbps, this does not typically represent the actual amount of bandwidth that is available for use by such services as Active Directory replication. When attempting to understand “net available bandwidth”, consider the following:

There is seldom dedication of an entire WAN link to a single service, as this may not be cost effective. Hence, it may be possible to identify several services actively competing for bandwidth from the WAN link. For each service added to the scope of a WAN link, the levels of net available bandwidth will decrease. Hence, after investigation of a 10Mbps WAN link, it is possible to identify only about 64Kbps of available bandwidth left for use by new services.

The amount of bandwidth available within a WAN link will also vary with the time of day and the day of the week as the frequency and duration of use of the WAN link by various services will vary. Hence, in order to determine a reasonably accurate figure for the amount of available bandwidth for a WAN link, it may be necessary to monitor the WAN link, using a performance monitoring tool (such as System Monitor in Windows Server 2003), over one or two weeks (or longer.) The gathered data can then be analysed to determine any patterns in the availability and usage of the WAN link. This information is invaluable in the design of the Site topology.



3.3. Process Approach

When executing this process, the recommended approach is to keep it simple, which implies the determination of the minimum number of Sites required.

Hence, to support this recommendation, this design methodology states the following null hypothesis to guide the execution of this process:

“The automatically generated first Active Directory Site (called “Default-First-Site-Name”) can adequately support all the replication and service provision requirements for the forest and the organisation, and all other applications and services that rely upon Active Directory Sites, without the requirement to create additional Sites”

Following the statement of this null hypothesis, it is necessary to execute an investigation to disprove this null hypothesis, and hence determine the requirements for the design and implementation of two or more Sites. If it is possible to disprove this null hypothesis, then it is necessary to determine the total number of Sites required for the forest.

To support this null hypothesis, and the requirements to execute an analysis to disprove it, this design methodology proposes the following approach for this process:

1. Understand the factors that will influence the number of Active Directory Sites required for this Site infrastructure

2. Define the criteria to support determination of the number of Sites required

3. Identify all relevant factors and scenarios and evaluate against defined criteria to determine number of Sites required


Based upon the above approach, this process to determine the number of Sites required is composed of the following components:

Understanding the factors that will influence the number of Sites required

Definition of the criteria to support determination of the number of Sites required

Determination of the number of Sites required



An understanding of the factors that will influence the determination of the number of Sites required

The criteria to support the determination of the number of Sites required

The determination of the number of Sites required for this Site infrastructure



Site Plan – Inter-Component Dependencies for Process to Determine the Number of Active Directory Sites Required

STARTUnderstand the factors that will influence the number of

Sites required

Determination of the number of Sites required

Definition of criteria to support determination of number of Sites required




3.7. Process to Determine the Number of Sites Required

Site Plan – Process to Determine the Number of Sites Required

START ENDExecute

A1 – A2

Execute

B1 – B6© 2 0 0 4 M U S T A N S H I R B H A R M A L


Consider the following when identifying the opportunity to disprove the null hypothesis for this process, and hence determine the number of Sites required for this Site infrastructure.

Presented within the following three sections are the considerations for this process:

1. Understanding the factors that will influence the number of Sites required

2. Definition of the criteria to support determination of the number of Sites required

3. Determination of the number of Sites required

3.8.1. Understanding the Factors that Influence Number of Sites Required

Consider the following when attempting to understand the factors that may influence the number of Sites required, and hence the opportunity to disprove the null hypothesis for this process:

Factor B1: Understanding the factors that will influence the number of Sites required

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the factors that will influence the number of Active Directory Sites required for this Site infrastructure


This design methodology recognises four primary factors that may provide opportunities to disprove the null hypothesis for this process, and support justification for the design and implementation of a multiple Site infrastructure. The four factors are:

The presence and number of physical and geographical locations for an organisation

The presence of network links and their levels of network traffic

The requirements for local domain controllers

The administrative and financial overheads

It is important to understand that this design methodology requires identification of opportunities to disprove the null hypothesis for this process, based upon the use of all or a combination of the above factors. This is necessary to provide justifiable reasons to design and implement a multiple Site infrastructure.

The following steps within this process discuss the influence of each of the above factors in determination of the number of Sites required.

Factor B2: Understanding the influence of the presence and number of physical and geographical locations on the number of Sites required




Has multiple physical locations that will support users and computers that will authenticate against the Active Directory and access resources controlled via the security infrastructure of the Active Directory, and

Wishes to understand the influence of the presence and number of physical and geographical locations on the number of Sites required


It is important to understand that the presence or absence of multiple physical locations for an organisation cannot exclusively disprove the null hypothesis for this process, and hence determine the number of Active Directory Sites that require design and implementation. It is necessary to consider the presence and absence of physical locations, and the present or proposed number of physical locations in conjunction with the other three factors identified above.

For example, it is possible to identify the following scenarios within organisations:

It is possible for an organisation, with a single physical location and a LAN infrastructure, to disprove the null hypothesis justifiably, and hence design and implement a multiple Site infrastructure.

It is possible for an organisation, with multiple physical locations and a WAN infrastructure connecting the locations together, to be unable to disprove the null hypothesis and hence design and implement a single Site.

Note, however, that the presence or absence of multiple physical locations does determine the influence of the other factors in the determination of the number of Sites required. For example:

Within an organisation, with multiple geographical locations and an extensive WAN infrastructure (as VPN links or leased lines, and so on), the presence of network links, and levels of net available bandwidth are applicable factors.

Within an organisation, with a single geographical location and a single LAN segment, the requirements for a location domain controller may not be an applicable factor.

Within an organisation supporting many autonomous divisions, with boundaries for autonomy defined by geographical locations for offices, the requirements for administrative and financial autonomy are applicable factors.

Factor B3: Understanding the influence of the presence of network links, and their levels of network traffic, on the number of Sites required


Has one or more WAN links and two or more LAN segments within the scope and boundary of the forest, and

Wishes to understand the influence of the presence of network links, and the levels of network traffic within these links, on the number of Sites required




When attempting to understand the influence of a network infrastructure on the determination of the number of Sites required, consider the following:

The most significant aspects of a network (LAN and WAN) infrastructure within an organisation, which will influence the number of Sites required, are:

The presence and absence of network links within an organisation, and

The net levels of available bandwidth, within the appropriate network links, to support Active Directory replication traffic

The process “analysis of current and proposed network infrastructure” will identify all current and proposed network links (as LAN segments and WAN links) within the boundary and scope of the forest for this Site Plan.

Note that when determining the influence of levels of net available bandwidth within network links on the number of Active Directory Sites required, this design methodology requires consideration for WAN links and LAN segments. The objective of a Site infrastructure is to control Active Directory replication traffic, and within some organisations, this requirement may extend to LAN segments, as well as WAN links.

Inter-Site Active Directory replication traffic is, by default, compressed to almost 90% of the original size. Improvements in Windows Server 2003 Active Directory to enhance replication extend to other areas as well. For example, linked value replication allows the replication of individual group members across the network instead of treating the entire group membership as a single unit of replication. This hence reduces the volume of data that requires replication between domain controllers in separate Sites. Note, however, it is necessary to raise the forest functional level to “Windows Server 2003” to enable linked value replication.

When attempting to understand the influence of a network infrastructure on the ability to disprove the null hypothesis and hence increase the number of Sites required, consider the following:

Note that all of the following example considerations require consideration in conjunction with the other factors within this process prior to determining the requirements for a multiple Site infrastructure.

The presence of low net available bandwidth network links between geographical locations may warrant the designation of the terminus location as a Site.

The presence of network links between physical locations with high levels of latency may not support frequent intra-Site Active Directory replication, and hence may support the designation of locations as Sites.

The presence of network links with historically low reliability statistics may support the designation of the connected locations as Sites. A historically unreliable network link, with significant downtime and latency values, may not support intra-Site Active Directory replication, and would instead support scheduled inter-Site replication.

The presence of historically low available bandwidth levels within LAN segments for one or more physical locations for an organisation. This design methodology strongly recommends the execution of an analysis into levels of available bandwidth on LAN segments as well as the obvious WAN



links. Many organisations overlook execution of an analysis of a LAN segment because of automatic assumptions that a LAN means “high bandwidth and availability”. However, network utilisation has historically increased within most organisations, such that a 10Mbps Ethernet infrastructure may prove to be unable to meet the “typical” networking requirements of the organisation. Applications, systems and services that can push the network to its limits, such as video and data conferencing and other media streaming, can substantially reduce the amount of available bandwidth within a LAN infrastructure. This may be detrimental to intra-Site Active Directory replication, and vice versa. Hence, it may be possible to identify the requirements to partition one or more LAN segments into Sites, to support the following:

To control the impact of typical LAN network activity on Active Directory replication, and

To control the impact of frequent intra-Site Active Directory replication on typical LAN network activity

It is important to understand that it is not possible to identify any “set-in-stone” minimum levels of available bandwidth within a network link that justifies the creation of multiple Sites. The onus is with the organisation to judge whether significantly low levels of available bandwidth within network links will support frequent intra-Site Active Directory replication or scheduled inter-Site replication.

When attempting to understand the influence of a network infrastructure on the ability to support the null hypothesis and hence retain a single Site infrastructure, or reduce the number of Sites required, consider the following:

The presence of network links between locations with high levels of net available bandwidth may support intra-Site replication, and hence negate the requirement for designation of connected locations as Sites. For example, after execution of an analysis of the levels of bandwidth utilisation in the network link, during a typical working week, it is possible to identify that the network link has more than 50% available bandwidth, even during peak hours when users logon and logoff.

The presence of network links between locations with high levels of net available bandwidth, during peak and non-peak business hours, and a historically high level of availability may support intra-Site replication.

Factor B4: Understanding the influence of the requirements for local domain controllers on the number of Sites required


Has two or more geographical locations, and

Wishes to understand the influence of the requirements for local domain controllers on the number of Sites required


When attempting to understand the influence of requirements for local domain controllers on the number of Active Directory Sites required, consider the following:

Where a remote location requires one or more local domain controllers for one or more domains within this forest, then it is necessary to support



replication between these domain controllers and other domain controllers within the forest, in other geographical locations. The Active Directory replication traffic between these domain controllers must hence travel across any network links between geographical locations. The subsequent capabilities of any network links between the geographical locations to support intra-Site or inter-Site replication will hence determine the requirements for the designation of remote locations as Sites.

This design methodology identifies a number of possible scenarios where local domain controllers may or may not be required, and hence may or may not influence the requirements for the creation of Sites.

When understanding the scenarios where a remote location may warrant the implementation of one or more local domain controllers, consider the following:

The requirements to maintain business continuity and productivity may warrant the implementation of a local domain controller in a geographical location. For example, it may be possible to note the following scenarios within an organisation where the presence of one or more local domain controllers may be essential to business continuity and productivity:

It is possible to identify users within a remote geographical location that make a notable and significant contribution to the overall productivity of the organisation, and do so via reliance upon access to Active Directory-controlled network resources and services. Any disruptions to their productivity, due to the inability to logon and access a domain controller because of a failed network link and so on, may hence disrupt the productivity of the organisation. The presence of one or more local domain controllers may abstract these users from temporary network failures. The presence of two or more local domain controllers may protect against the failure of one local domain controller.

It is possible to identify applications or other processes within a remote geographical location that actively contribute to the productivity of the organisation via the access, use, and management of business data supported by the Active Directory. These applications and processes hence rely upon the uninterrupted access to the Active Directory-controlled / supplied data, and one or more location domain controllers may hence support these requirements.

The requirements to improve authentication latency within and between geographical locations may warrant the implementation of a local domain controller. For example, an organisation is able to identify a large number of users that require authentication to the Active Directory, and request authentication for access to resources and services. The supporting network topology (WAN and LAN) may result in the generation of uneven silos of users, hence producing bottlenecks in network traffic, which result in authentication and authorisation latencies. In these scenarios, it may be necessary to implement domain controllers in close network proximity to these silos of users, thus alleviating network bottlenecks and any authentication and authorisation latencies. The creation of additional Sites and the subsequent distribution of users amongst the separate Sites (via subnet-to-Site mappings) may support these requirements.

The requirements to control client access points to services published within the Active Directory may support the design and implementation of additional Sites. The placement of local domain controller(s), in their own



Site, will control client access to Active Directory published services, and can ensure such requests do not cross any WAN links.

The requirements to support local applications and services that generate queries against a domain controller / Global Catalog server may warrant the implementation of a local domain controller in a geographical location. For example, a remote geographical location supports one or more applications that generate queries to Active Directory domain controllers on ports 389 and 3268, such as an Exchange 2003 server. The placement of a local domain controller / GC server can enhance the performance of these applications. However, although the local placement of a GC server may support local user logon, the GC server may generate greater amounts of Active Directory replication traffic (for a multiple domain forest) across any network links. A new feature of Windows Server 2003 allows the caching of Universal Group memberships by domain controllers. This feature, enabled at the Site level, can negate the requirement to place a local GC server at a Site to facilitate user logon. However, this feature does not assist applications that query port 3268. It important to note that there are security implications associated with the caching of Universal Group memberships. The process “design of domain controllers and Global Catalog servers” discusses the design for the caching of Universal Group memberships.

The requirements to support plans and procedures for disaster recovery (DR) may warrant the implementation of one or more local domain controllers, for each domain within the forest, within one or more DR locations. Most organisations, where the business continuity is directly dependent upon continuity of the IT infrastructure, will design and implement one or more disaster recovery (DR) locations, to protect against site-specific disasters. To ensure the continuity of the Active Directory forest, it is imperative to ensure the implementation of domain controllers representing each required domain, within in each required DR location. As these domain controllers must support the execution of DR plans and procedures, it is necessary for their participation within the Active Directory replication topology, and hence each DR location not currently represented within the Site infrastructure, will require representation as a Site.

When understanding the scenarios where a remote location may not support the implementation of one or more local domain controllers, consider the following:

The nature of the Active Directory requirements of users within a remote geographical location may not support the implementation of a local domain controller. For example, the geographical location may be outside of the scope of the forest (and within the scope of another Active Directory forest), or the users are within the scope of this forest but do not require any Active Directory controlled network services or resources. Where it is possible to identify such scenarios, then these locations may be excluded from the scope of the Site infrastructure, and hence not require representation as a Site. Note that it is possible to create an Active Directory Site that does not host a domain controller. The Active Directory clients within this Site may be subsequently “covered” by domain controllers from another Site via the “autositecoverage” feature of Windows Server 2003 domain controllers, or via the custom configuration of the registry entries “SiteCoverage” and “GcSiteCoverage” within the registry sub-key “HKLM\System\CurrentControlSet\Services\Netlogon\Parameters”. See the “Organisation-Wide Active Directory Plan” process “Design of a DNS infrastructure” for details.



The users within a geographical location exclusively use a remote server based computing (SBC) solution, hosted in another location. In this scenario, there is no requirement to place one or more local domain controllers at that physical location, and hence that physical location will not require representation within the Active Directory as a Site. The users within this location may logon via cached credentials when using a server-based computing solution. Note, however, that this scenario will not support access to resources on local servers, controlled via the Active Directory, using cached credentials. This is due to the functionality and use of Kerberos as the default authentication protocol within Windows Server 2003.

There is a requirement to ensure that certain domain controllers that will share an Active Directory database will have a consistent and up-to-date copy of the database at all times. Placing the domain controllers within separate Sites may result in a replication interval and schedule for the replication of the Active Directory database that may not meet this requirement. Domain controllers within the same Site replicate on a change-notification basis. This requirement, to maintain a consistent and up-to-date Active Directory database between certain domain controllers, may arise where, for example, an organisation has directory-enabled applications that will query the Active Directory for application data stored there. The applications may have a requirement to ensure that only the most recent data is used. Although placing domain controllers within the same Site may reduce the number of Sites required, the supporting network infrastructure must be able to support frequent and unscheduled replication between the domain controllers. Without this supporting infrastructure, the opportunity to consolidate the Sites may not be realisable. Note the following about this scenario and requirement:

It is possible to enable inter-Site change notification for replication, as a property of an RPC over IP Site Link object. However, it is important to evaluate and carefully monitor the impact on any WAN links that connect the physical locations together, as the frequency of Active Directory replication traffic across the WAN link may increase substantially. Because inter-Site change notification for replication is a property of the Site Link object that connects that Site to other Sites, its scope of impact will be all Sites within the Site Link object and all domain controllers within each Site in the Site Link object. Hence, enabling this feature may not be beneficial for all Sites and all domain controllers within each Site of a Site Link object, especially if it is required only for specific domain controllers. Note that inter-Site change notification is not a configuration option for SMTP over IP Site Link objects. See the process “Design of Site Link Topology and Site Link Objects” for details of the considerations for the design for inter-Site change notification for Site Links.

Where the implementation of change notification between two domain controllers in separate physical location is required, the consolidation of the physical locations into one Site to meet this requirement can only be accomplished upon compliance with the following primary criteria (Note that there may be other factors that require consideration for the implementation of this option to consolidate two potential Site locations into one Site):

A potential Site Link object, between these two physical locations that are potential Sites, will not contain any other Sites. If this is true, then it is possible to enable change notification on this potential Site Link object, and hence it may not be necessary to consolidate the locations into one Site.



The network link between the two physical locations has “high” net available bandwidth (according to the organisation) and reliability, and is able to handle unscheduled and frequent replication traffic. If this is not true, then the two locations should retain their potential Site status.

Factor B5: Understanding the influence of administrative and financial overheads on the number of Sites required

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of administrative and financial overheads on the number of Sites required


When attempting to understand the influence of administrative and financial overheads on the number of Active Directory Sites required, consider the following:

There may be a requirement to reduce the management overheads associated with, for example, a vast and complex Active Directory replication topology. It is possible to support this requirement via a reduction in the number of Sites that organisation is planning to design and deploy.

A reduction in the number of Sites that require design and implementation for a forest can hence eliminate the following administrative tasks, associated with each required Site:

The management of Site-level GPO links

The management of custom replication connection objects for inter- and intra-Site replication

The management of preferred bridgehead servers for each Site

The management of the Site Licensing server for each Site

The management of Inter-Site RPC and SMTP Site Links to and from each Site

The management of the physical security for each local domain controller at each Site location

The management of the domain controller(s) at each location

There may be a requirement to reduce the financial overheads associated with each required Site for a forest. For example, an organisation may determine that it is more cost effective to centralise all domain controllers for a domain within a data centre and upgrading appropriate WAN links, rather than deployment of domain controllers to each remote location.

Placement of domain controllers in remote physical locations is costly as it is possible to identify a concurrent requirement for the following:

A greater number of server hardware platforms

A requirement to design and implement secure storage locations for the domain controllers in each remote location

A requirement to support local administrators to manage local domain controllers



Factor B6: Understanding the factors that do not influence the determination of the number of Sites required

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the factors that exclusion from consideration to determine the number of Active Directory Sites required for this Site infrastructure.


When determining the number of Sites required for an Active Directory forest, this design methodology requires the organisation to exclude the following factors from the consideration:

The types of network links that exist between geographical locations do not influence the number of Sites required. The net available bandwidth within the network links is the primary influential factor.

The Active Directory namespace(s) for the forest do not influence the number of Sites required. The Site infrastructure for a forest is independent of the Active Directory namespace(s).

The logical and physical boundaries for the Active Directory domains within the forest do not influence the number of Sites required. A single Site can support domain controllers from one or more domains within a forest.

Requirements to partition a hub Site into multiple Sites to facilitate outbound replication to more that 100 branch office Sites is no longer an influential factor in the determination of the number of Sites required. In Windows 2000 Active Directory, the KCC process, if left to select the bridgehead server for a Site, could select a single domain controller as the bridgehead server for outbound replication to all connected Sites. This could overload that domain controller and introduce replication latency between the hub and branch office Sites. To prevent this scenario, it either was necessary for an administrator to manually designate preferred bridgehead servers for a transport protocol, or split the hub Site into multiple Sites to prevent the selection of a single bridgehead server. However, in Windows 2003 Server Active Directory, substantial improvements to the algorithm used by the Inter-Site Topology Generator (ISTG) provides the capability to handle up to 5000* (*this is a non-specific and arbitrary figure) Sites (but only in the forest functional level of Native Mode) within an Active Directory forest.

Requirement to delegate control at the Site level do not influence the number of Sites required. For example, local administrators within an organisation, with a distributed administration model, may deem it necessary to create a local Site to leverage the delegation of control functionality. However, this requirement is not viable because delegation of control at the Site level does not the give the delegate full control over all objects held within that Site. This is because there is no mapping of Site to domain boundaries and structure. Instead, a user delegated, for example, Full Control at the Site level will have only the following permissions:

Open connector queue

Read and Write gpOptions

Read and Write gpLink

Read and Write managed by

Create and Delete Site Settings object



3.8.2. Definition of Criteria to Support Determination of Number of Required Sites

Consider the following when defining the criteria to support the determination of the number of Active Directory Sites required for this Site infrastructure:

Factor A1: Definition of the criteria to support determination of the number of Sites required

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to define the criteria to support the determination of the number of Active Directory Sites required for this Site infrastructure.


When defining the criteria to support the determination of the number of Active Directory Sites required, consider the following:

When determining the number of Sites required, it is necessary to justify each requirement for a Site. This is because the creation of each required Site is associated with financial and administrative overheads, which the organisation may have to justify.

The criteria to support the determination of the number of Sites required represent the business and technical requirements of the organisation for the Site infrastructure of a forest. Hence, compliance with the defined criteria implies compliance with business and technical requirements. This hence justifies the creation of Sites due to compliance with these criteria.

Although the onus is with the organisation to define their criteria, this design methodology proposes the following examples of criteria to support the requirements for Sites:

A Site is required where:

A network link between two geographical locations has a historically (based upon statistics) low level of available bandwidth during peak and non-peak business hours (where peak hours are 8am to 9:30am and 4:30pm to 6pm), and

The levels of available bandwidth are (for example) less than 512Kbps

A Site is required where:

A remote geographical location supports key business applications that contribute a significant percentage of the productivity / turnover of the organisation, and

The application relies upon the ability to connect to a domain controller without any latencies or disruptions.

Using the above examples, execute the following:

Execute an analysis of the organisation to identify all applicable factors that may influence the number of Sites required

Define criteria to control the number of Sites required, as a reflection of business and technical objectives and requirements



3.8.3. Determination of the Number of Sites Required

Consider the following when determining the number of Active Directory Sites required for this Site infrastructure:

Factor A2: Determination of the number of Sites required

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the number of Active Directory Sites required for this Site infrastructure.


When determining the final number of Sites required, it is also important to determine whether any of these Site locations may potentially become redundant after implementation. Where it is possible to identify these scenarios, then it is necessary for the organisation to re-evaluate their requirements for these Sites, and / or seek alternative solutions.

This design methodology proposes execution of the following approach to determine the number of Sites required:

Identify all potential geographical locations within an organisation, which host users, computers, servers, and so on, and connected to other locations by one or more network links. Evaluate each location, and contents of each location, against the defined criteria. Where it is possible to identify compliance with one or more of the defined criteria, then mark that location as a potential Site.

Execute an analysis of all network links (WAN and LAN) and evaluate against the defined criteria. Identify the requirements to partition entire subnets connected by these network links into Sites based upon compliance with the defined criteria.

Execute an analysis of all potential Site locations and evaluate against the following criteria to determine the potential redundancy of these Site locations:

It is possible to identify a potential decrease in the numbers of users and computers at a potential Site that could hence negate the requirement for local domain controllers, and hence the Site

It is possible to identify the potential / proposed requirements for the consolidation of multiple physical locations due to restructuring processes within the organisation, and hence the consolidation of potential Sites

It is possible to identify proposals / plans to upgrade the bandwidth and availability of an existing WAN link that connects a potential Site, and hence may negate the requirements for that Site (if based upon compliance with the criteria to reflect low bandwidth availability of a network link)

It may be possible to identify proposals / plans to implement a dedicated WAN link that connects the potential Site, and hence negate the requirements for that Site

It may be possible to identify the proposals / plans to relocate or discontinue Site-aware Active Directory published services from a potential Site. This may hence negate the requirements for that Site.



Using the above information and approach, execute the following:

Execute an analysis to determine all potential Site locations

Define criteria for the potential redundancy of a Site location

Evaluate all potential Sites against the defined redundancy criteria. Where it is possible to identify compliance with the criteria for the potential redundancy of a proposed Site, then it is necessary to determine the requirements to proceed with the design and implementation of that Site, or seek alternative solutions, where possible. Where it is not possible to identify compliance with the defined redundancy criteria, then each potential Site is a valid requirement.

For all valid Sites, document their justifications for design and implementation.

Generate a diagram illustrating the logical and physical placement and boundaries of these Sites within the organisation.



4. Design for Domain Controllers and GC Servers



The objectives of this process are to assist an organisation in the execution of the following tasks associated with domain controllers and Global Catalog servers for this forest:

Mapping of required Sites to domain boundaries

Determination of the minimum number of domain controllers each required Site will support

Determination of the requirements for Universal Group Caching

Determination of the minimum number of GC servers each required Site will support

4.2. Process Scope

The following factors define the scope of this process:

The number of domains within the forest this Site infrastructure will support, and the boundaries of these domains

The number of Sites required for this Site infrastructure (using the results from the process “determination of the number of Sites required”)

Note that the scope of this process is to determine the minimum number of domain controllers and GC servers required, and the requirements for their placement within the organisation, and the use of Universal Group Caching by non-GC domain controllers. The design for the server hardware specifications of the domain controllers and GC servers is outside of the scope of this process, and is instead a component of the Domain Plan process “design for domain controllers for this domain”.


Each required Site may support one or more domain controllers, representing one or more domains within the forest. When determining the number of domain controllers each domain will require, the first step is to identify the mandatory requirements for domain controllers, and then the optional requirements.

This design methodology hence proposes that the requirements for Sites, which have dictated the requirements for local domain controllers, will hence define the minimum number of domain controllers each domain will require, as mandatory requirements.

When determining the number of GC servers required, it is first necessary to consider a new feature that represents an alternative to a GC server in Windows Server 2003 Active Directory, which is “Universal Group Caching”. This feature involves the caching of the Universal security groups, and their members, on normal (non-GC) domain controllers within a Site.

This design methodology hence proposes that it is first necessary to determine the requirements for Universal Group Caching. Where it is possible to identify such requirements, then this may negate the requirements for GC servers, and vice versa.




When executing the process to design domain controllers and GC servers for this forest and Site infrastructure, the recommended approach is to “keep it simple”, with respect to the number of domain controllers and GC servers required.

To support this recommendation, this design methodology states the following null hypotheses for this process:

“For each Site that has been identified for creation, the minimum of one domain controller for each domain to be represented within that Site and one GC server per Site is sufficient to meet the Active Directory requirements of all users, computers, applications, processes, services and so on within that Site.”

Analysis of this null hypothesis provides the following facts:

It is not necessary to design and implement two or more domain controllers for each domain represented within an Active Directory Site, unless it is possible to disprove this null hypothesis.

The design and implementation of Universal Group Caching is not necessary, unless it is possible to disprove the null hypothesis and hence the requirement for a minimum of one GC server in a Site.

It is not necessary to design and implement two or more domain controllers configured as GC servers within an Active Directory Site, unless it is possible to disprove this null hypothesis.

This design methodology does not support the design and implementation of an Active Directory Site without at least one GC server, unless it is possible to disprove this null hypothesis.

This design methodology strongly advises against the design and implementation of new “features” within Windows Server 2003 Active Directory, simply because they are “new”. It is imperative to support every design decision by one or more qualified business and / or technical objectives and requirements. Hence, the null hypothesis for this process does not support the design and implementation of Universal Group Caching, unless it is possible to disprove this aspect of the null hypothesis with qualified business and technical requirements.

Following the statement of this null hypothesis, it is necessary to execute an analysis to disprove it, and hence determine:

The minimum number of domain controllers required for each Site

The requirements for the design and implementation of Universal Group Caching

The minimum number of GC servers required for each Site

When executing the process to design the domain controllers and GC servers for the Site infrastructure of the forest, this design methodology proposes the following approach:

1. Map domain boundaries to Sites

2. Determine the minimum number of domain controllers required for each Site

3. Determine the requirements for Universal Group Caching

4. Determine the minimum number of GC servers required for each Site




Based upon the above approach, the process to design domain controllers and GC servers is composed of the following four components:

Mapping of domain boundaries to Sites

Determination of the minimum number of domain controllers required for each Site

Determination of the requirements for Universal Group Caching

Determination of the minimum number of GC servers required for each Site



The mapping of the boundaries of each required domain within the forest to each required Site within the forest

The determination of the minimum number of domain controllers required for each Site within the forest

The determination of the requirements for Universal Group Caching (UGC)

Determination of the minimum number of Global Catalog servers required within each Site within the forest



Site Plan – Inter-Component Dependencies for Process to Design Domain Controllers and GC Servers

START

Mapping of domain boundaries to Sites

Determination of the minimum number of domain controllers

required

Determination of the requirements for Universal Group

Caching

Determination of the minimum number of GC

servers required© 2 0 0 4 M U S T A N S H I R B H A R M A L

4.8. Process to Design Domain Controllers and GC Servers

Site Plan – Process to Design Domain Controllers and GC Servers

START

END

Execute

A1

Execute

B1

Execute

B2 – B12

Execute

A2 – A3

Execute

B13-B15

Execute

A4 – A5

Execute

B17-B18

Execute

A6

Is there a requirement to

disprove the null hypothesis?

NO

YES



YES



NO

YES

NO

For numbers of domain controllers

For design of UGC

For numbers of GC servers





Consider the following when generating the design for domain controllers and GC servers within this forest.

Presented within the following four sections are the considerations for this process:

1. Considerations for the mapping of domain boundaries to Sites

2. Considerations for the determination of the minimum number of domain controllers required within each Site

3. Considerations for the determination of the requirements for Universal Group Caching

4. Considerations for the determination of the minimum number of GC servers required within each Site

4.9.1. Mapping of Domain Boundaries to Sites

Consider the following when mapping domain boundaries to Sites:

Factor B1: Understanding the requirements to map domain boundaries to Sites


Has identified the requirements for the design and implementation of multiple Active Directory Sites and domains within the forest, and

Wishes to understand the requirements to map domain boundaries to Sites


Where the earlier process within this Site Plan, “determination of the number of Sites required”, has identified the opportunity to disprove its null hypothesis, and hence the requirements for the design and implementation of multiple Active Directory Sites, it is now necessary to map domain boundaries to these Sites.

The Sites identified for design and implementation strictly reflect the business and technical requirements for the following four factors that influence the requirements for Sites:

The presence and number of physical and geographical locations for an organisation

The presence of network links and their levels of network traffic

The requirements for local domain controllers

The administrative and financial overheads

Hence, the requirements for Sites do not specifically reflect the requirements for the local representation of a domain, as one or more domain controllers for that domain, within the subnets of the required Sites. This is the objective of this step within this process.

Factor A1: Mapping of domain boundaries to Sites





Wishes to map domain boundaries to Sites


This design methodology proposes execution of the following approach to map domain boundaries to Sites:

Execute an analysis of the results of the Forest Plan process, “determination of the boundaries and contents of each domain”, to identify the logical and physical boundaries for each domain within the organisation.

Execute an analysis of the results of the earlier process within this Site Plan, “determination of the number of Sites required”, to identify the logical and physical boundaries for each required Site within the organisation.

Correlate the logical and physical boundaries of each required domain with those of each required Site, and generate a diagram to illustrate the correlations. For example, an organisation has identified the requirements for the design of four Active Directory domains (“Root.com”, “ChildA.root.com”, “ChildB.root.com” and “ChildC.root.com”) within a forest, and the requirements for four Active Directory Sites (“Site1”, “Site2”, “Site3”, and “Site4”) for the forest. The organisation mapped the boundaries of the four domains to the four Active Directory Sites using the above approach to retrieve the following results:

The results of the Forest Plan process, “determination of the boundaries and contents of each domain” identifies the following:

The forest root domain, “root.com” is a placeholder domain and has a logical boundary represented by the exclusive representation on one subnet within building A, in the London HQ for the organisation.

The domain, “ChildA.root.com”, is a primary production domain and requires representation within all locations (London, Paris, Frankfurt, and Tokyo) for the organisation

The domain “ChildB.root.com”, assigned to an autonomous division, requires representation in:

Buildings 1 and 2 of the Paris offices for the organisation, and

Building 1 of the Frankfurt offices for the organisation

The domain “ChildC.root.com”, assigned to another autonomous division, requires representation in:

Building 1 and 2 of the Frankfurt offices for the organisation, and

Building 1 of the Tokyo offices for the organisation

The results of the Site Plan process, “determination of the number of Sites required”, identifies the following:

All subnets within the London HQ require representation within “Site 1” of the Site infrastructure

All subnets within all buildings for the organisation in Paris require representation within “Site 2” of the Site infrastructure



All subnets within all buildings for the organisation in Frankfurt require representation within “Site 3” of the Site infrastructure

All subnets within all buildings for the organisation in Tokyo require representation within “Site 4” of the Site infrastructure

The mapping of domain boundaries to Sites hence produces the following results:

“Site 1” must support domain controllers for both the “root.com” and “ChildA.root.com” domains

“Site 2” must support domain controllers for the following domains:

“ChildA.root.com”

“ChildB.root.com”



“ChildB.root.com”

“ChildC.root.com”



“ChildC.root.com”

These results are illustrated in the following diagram:



TOKYOFRANKFURT

PARIS

LONDONDC1.root.comDC2.root.com

DC3.ChildA.root.com

DC4.ChildA.root.com

DC5.ChildA.root.com

DC6.ChildA.root.com

DC7.ChildB.root.com

DC8.ChildB.root.com

DC9.ChildC.root.com

DC10.ChildC.root.com

SITE 1

SITE 2

SITE 3 SITE 4© 2 0 0 4 M U S T A N S H I R B H A R M A L

Figure 21.1: Example Illustration of the Mapping of Domains to Sites

Note in the following diagram, that the mapping of domains to Sites using this approach provides the first indication of the minimum number of domain controllers required for each Site. The execution of the next step within this process will evaluate all other considerations that may influence the requirements for more domain controllers within each Site.


Analyse the results of the Forest Plan process, “determination of the boundaries and contents of each domain”, to identify the required boundaries of each domain.

Analyse the results of the Site Plan process, “determination of the number of Sites required”, to identify the required boundaries for each Site.

Correlate the results of these two processes and document the required mapping of domains to Sites. Generate a diagram to illustrate the required domain-to-Site mapping.



4.9.2. Determination of the Minimum Number of Domain Controllers for Each Site

Consider the following when determining the minimum number of domain controllers required for each Site:

Factor B2: Understanding the approach towards determination of the minimum number of domain controllers for each Site


Has identified the requirements for the design and implementation of multiple Active Directory Sites and domains within the forest

Has mapped the boundaries for each required domain to each required Site, and

Wishes to understand the approach towards determination of the minimum number of domain controllers for each Site


The results of the previous step, to map domain boundaries to Sites, will identify the minimum number of domain controllers each Site will be required to host, to support the requirements for the representation of the domains within the Sites. The result of this step complies with the null hypothesis for this process, and does not disprove this hypothesis.

The execution of this step within this process, to determine the minimum number of domain controllers required for each Site, will evaluate all other factors that may influence the opportunity to disprove the null hypothesis for this process.

This design methodology proposes execution of the following approach toward determination of the minimum number of domain controllers required for each Site:

Understand the factors that will support the opportunity to disprove the null hypothesis for this process, and hence require the design and implementation of two or more domain controllers for each domain, within the appropriate Site or Sites.

Understand the factors that will support the null hypothesis for this process, and hence require the implementation of the minimum number of domain controllers (one) for each domain that requires representation within each Site.

Define the criteria for the determination of the minimum number of domain controllers required for each domain, within the appropriate Site(s)

Identify all applicable factors and evaluate against the defined criteria, and hence determine the minimum number of domain controllers for each domain, within the appropriate Sites.

Presented within the following three sections are the considerations for the execution of this step within this process:

1. Considerations for the factors that will support the opportunity to disprove the null hypothesis for this process

2. Considerations for the factors that support the null hypothesis for this process



3. Considerations for the determination of the number of domain controllers required for each domain in each appropriate Site

4.9.2.1. Factors that Support the Opportunity to Disprove the Null Hypothesis

Consider the following information when attempting to understand the factors that support the design and implementation of multiple domain controllers for a domain within each appropriate Site. Identification of the requirements for one or more of the following factors hence supports the opportunity to disprove the null hypothesis for this process:

Factor B3: Understanding requirements to support the numbers and distribution of users within each domain and within the Site infrastructure for the forest


Has identified the requirements to support users geographically distributed within a multiple Site and domain infrastructure within the forest, and

Wishes to understand the influence of this requirement on the opportunity to disprove the null hypothesis for this process


The number of local domain controllers required within a Site is dependent upon the numbers of users the domain controllers are required to support.

The typical support functions provided by a local domain controller include authentication and authorisation to Active Directory controlled resources and services, and LDAP lookup operations to port 389 via users and applications.

Note that it may also be necessary for a domain controller to host infrastructure services such as DNS, WINS, and DHCP, and hence provide these services to local users and computers.

The server CPU and memory specifications of the domain controllers will determine the capability of the domain controller to support the required numbers of users, computers, applications, services and so on.

Although the design for the hardware specifications of the domain controllers for a domain requires execution as a process component of the Domain Plan, this design methodology provides the following considerations for guidance only:

A single Windows Server 2003 domain controller for a domain is capable of supporting between 10 and 500 users of that domain, in a single Site, with a hardware configuration of a single Pentium IV XEON CPU of 1 GHz or greater and 512Mb of RAM.

A single Windows Server 2003 domain controller for a domain is capable of supporting between 500 to 1000 users of that domain, in a single Site, with a hardware configuration of two Pentium IV XEON CPU of 2 GHz or greater and 1Gb of RAM.

A single Windows Server 2003 domain controller for a domain is capable of supporting between 1000 to 5000 users of that domain, in a single Site, with a hardware configuration of four Pentium IV XEON CPU of 2 GHz or greater and between 2Gb and 4GB of RAM. This specification of Windows Server 2003 domain controller can support each addition 5000 users in a Site.



Note that these examples are for illustration purposes only and do not take into account the requirements for redundancy, high-availability, Global Catalog server presence, and so on, which are all factors discussed later within this process.

The above examples illustrate that a Windows Server 2003 domain controller is capable of supporting a significant number of users within an Active Directory Site.

However, where it is possible to identify requirements to reduce intra-Site authentication and authorisation latency then the numbers and specifications of the domain controllers placed within a Site will influence this requirement. Too few domain controllers for many users within a Site will result in authentication and authorisation latencies for these users. Under resourced domain controllers within a Site will be unable to cope with a high volume of authentication, authorisation, and query requests generated by local users, computers and applications, hence resulting in delays in the response to these requests.

Factor B4: Understanding the requirements for redundancy / high-availability of a domain controller and a domain


Has identified the requirement to maintain business continuity within a Site with many users, and where business critical applications and processes operate that rely upon the uninterrupted presence of a domain controller for a domain, or a domain itself, and



The design and implementation of multiple domain controllers for a domain within a Site can ensure business continuity in an environment with many users and business critical applications and processes. Where a domain is represented within a Site by only one domain controller, then the failure of this single domain controller (via hardware and / or software) would disrupt business continuity until the server could be repaired, rebuilt, or replaced.

Where an organisation can identify that the function and role of a domain is critical to the business continuity of the organisation, then it is necessary to protect this domain against any Site-specific disasters. Hence, there is a requirement to ensure the distribution of multiple domain controllers for this domain within specific Sites and across multiple Sites, to ensure the availability of this domain. Examples of such domains include the forest root domain of each forest.

The time required to execute any contingency plan procedures, to resolve a domain controller contingency, will influence the number of domain controllers required for the domain.

The following are examples of the factors that will influence the time required to resolve a domain controller contingency:

The presence of documented and practised contingency plan procedures

The presence of local administrators trained in the execution of the contingency plan procedures



The presence and availability of spare hardware components for the servers

The presence and availability of a spare standby server

The presence of a standard and automated server build for a Windows Server 2003 member server

The size of the Active Directory database and the presence of other local domain controllers for the same domain

The presence of automated processes to support execution of the Active Directory Installation Wizard to replicate from media

The presence of two or more domain controllers for a domain within a Site reduces the pressure on local administrators to execute a contingency plan procedure successfully, within a specified time limit, for a failed domain controller.

Factor B5: Understanding the requirement to support and control access to Active Directory published services


Has identified the presences of services, published within the Active Directory, regularly and heavily accessed by users, computers, applications and so on within a Site, and



The Site infrastructure of a forest controls access to Active Directory published services by users and computers within a Site.

The mapping of subnets-to-Sites ensures that clients within a Site requesting access to Active Directory published services are directed by DNS to a domain controller within the local Site first, where one exists. This hence prevents any unnecessary inter-Site transfers of service access requests, and the corresponding network traffic.

Where it is possible to identify frequent requirements to access Active Directory published services within a Site, this may increase resource demands on the local domain controller(s). In such scenarios, it may be feasible to design and implement a local domain controller dedicated to the support of access to specific frequently accessed Active Directory published services. It is also possible to modify the DNS SRV resource records for the service to support redirection of such requests to the dedicated domain controller(s). This approach may hence reduce and distribute the workload on other domain controllers within that Site.

Factor B6: Understanding the requirements to support local directory-enabled applications that will query application directory partitions (ADPs) within the forest


Has identified the requirement to host and / or replicate copies of a custom ADP to a local domain controller within a Site



Has identified that the custom ADP will store data that will be frequently accessed and possibly updated by applications and services within the local Site, and



A deliverable of the Site Plan process “design of a replication topology for ADPs” (see later) is the identification of the domain controllers that will host replicas of application directory partitions identified for creation and deployment within the Active Directory forest.

For custom ADPs required to store frequently accessed data, there may hence be a reciprocal increase in the resource utilisation on the host domain controller(s) to manage the frequent queries.

Where it is possible to identify such scenarios, this design methodology recommends the following options:

Design and implement a dedicated domain controller within a Site to host a custom ADP, or

Upgrade the appropriate hardware components (CPU, RAM, Disks, and so on) for a designated domain controller required to host a custom ADP.

Note that the second option may be detrimental to the provision of the other support functions of the designated domain controller within a Site.

Factor B7: Understanding the requirements to support directory-enabled applications that will frequently query the domain partition for a locally represented domain


Has identified the presence and use of mission critical directory-enabled applications within a Site that will perform frequent queries to port 389 of a domain controller, and



Directory-enabled applications that will make frequent queries to a domain controller’s domain partition may increase the utilisation of hardware resources on the target domain controllers.

Where it is possible to identify such types of queries, it is necessary to monitor the resource utilisation of the targeted domain controllers to determine the impact of the directory-enabled application on the normal routine operation of the domain controller.

Where it is possible to identify such scenarios, this design methodology recommends the following options:

Upgrade the hardware resources of a domain controller to meet the demands of a directory-enabled application, or



Design and implement a dedicated domain controller, to ensure minimal latencies in the provision of other services by peer domain controllers.

Factor B8: Understanding the requirement to load balance inter-Site replication for a Site


Has identified the requirement where a Site must replicate with many other Sites within the forest (for example, a hub Site in a hub-and-spoke configuration), and



Within a Site linked to multiple other Sites, the window for replication to one or more of these remote Sites may influence the requirements for multiple domain controllers in that Site, to ensure timely replication within each 24 hour period.

The later process within this Site Plan, “design for preferred bridgehead servers”, assists an organisation in the determination of the requirements to design and implement dedicated bridgehead servers to ensure load balancing of replication into and out of the Site.

Where it is possible to identify a very large number of Sites within a forest, connected for example in a hub-and-spoke / hybrid hub-and-spoke arrangement, then Microsoft recommends that for every 15 outbound Sites that are connected to a Site, one additional domain controller will be required within that Site to allow load-balancing of outbound replication from that Site.

4.9.2.2. Factors that Support the Null Hypothesis

Consider the following information when attempting to understand the factors that support the null hypothesis for this process:

Factor B9: Understanding the influence of domain controller server hardware availability


Has identified the presence of hardware restrictions on the design and implementation of domain controllers, and

Wishes to understand the influence of this requirement to support the null hypothesis for this process


Many organisations face restrictions on server hardware for domain controllers, and do no have the luxury of procuring new server hardware for all required Windows Server 2003 domain controllers. The restrictions may be financial, administrative, or political in nature within the organisation.

It may be possible to identify one or more of the following example scenarios:



An organisation may identify the requirement to reuse server hardware where possible, until approval of a budget for the next scheduled hardware refresh programme for the servers. Hence, the number of servers currently available will not increase until approval of the budget for the hardware refresh programme.

An organisation has an inflexible support contract with an incumbent managed services organisation, which dictates the use of specific hardware platforms and configurations for all servers within the organisation to meet SLAs or application management / support services. Hence, it is necessary to reuse all existing server hardware for the domain controllers until initiation of a renewal programme within the support contract, based upon compliance with predefined criteria for renewal.

Where it is possible to identify such scenarios and restrictions on server hardware, then the number of domain controllers may have to remain static, assuming the minimum number of domain controllers required (based upon domain to Site mapping) is met.

Factor B10: Understanding the influence of the financial and administrative overheads for domain controllers


Has identified the requirements for compliance with financial and administrative overheads for domain controllers, and

Wishes to understand the influence of these requirements to support the null hypothesis for this process


The design and implementation of each domain controller within a Site is associated with financial and administrative overheads. The cumulative effect of all overheads may justify the requirements to reduce the numbers of domain controllers within Sites, and hence support the null hypothesis for this process.

For example, for each additional domain controller for a domain, there will be an incremental increase in the administration overhead for that domain controller. This may hence increase the utilisation of administration resources within the IT department(s) of the organisation, which may in turn lead to a decrement in the service provision by these resources. An IT department with budget limitations may be unable to react to resource over utilisation and hence require the imposition of a limit on the number of domain controllers that require design and deployment.

Factor B11: Understanding the influence of requirements to assure the physical security of the domain controllers in the Sites


Has identified the requirement for compliance with security policies that dictate the physical security and access control requirements for domain controllers in remote Sites, and

Wishes to understand the influence of this requirement to support the null hypothesis for this process




The physical security of domain controllers in remote Site should be a key concern to all organisations. Compromise of the physical access to a domain controller can lead to the compromise of the security of organisation resources and data that is controlled by the Active Directory forest.

The infrastructure required to guarantee the physical security of a domain controller in a remote physical location for the organisation may be costly to implement and manage, and the target location will require the physical space to accommodate such requirements as well.

Where an organisation already has a physically secure “server room” infrastructure then this cost can be negated as long as the current infrastructure can accommodate all of the new domain controllers required for that physical location.

Where it is not possible to extend the current infrastructure (due to physical or budget limitations) to handle the extra server requirements, this may hence influence the number of local domain controllers that can be placed in the remote physical location.

However, where an organisation does not have an existing security infrastructure within a remote physical location or the budget to implement such an infrastructure, then this may influence the decision to place no domain controllers in the remote physical location at all, until it is possible to guarantee their physical security.

Factor B12: Understanding the influence of Active Directory replication bandwidth overheads for multiple domain controllers within a domain


Has identified the requirement to limit the impact on the local area network of a Site of intra-Site Active Directory replication traffic, and

Wishes to understand the influence of these requirements to support the null hypothesis for this process


Each additional domain controller within a Site, and naming context replicated to and from a Site, will add to the volume of intra- and inter-Site replication traffic for the Site.

Although intra-Site replication is unscheduled and very frequently generated, the impact of the intra-Site replication traffic generated by just a few domain controllers on the LAN traffic will be negligible.

However, where the numbers of domain controllers on a LAN infrastructure exceeds, for example, tens of domain controllers, then the impact may be significant, especially on bandwidth sensitive applications and processes operating within the LAN. Only in extreme circumstances would it be necessary to reduce the number of domain controllers that will operate within a Site to support the requirement to limit LAN bandwidth use by intra-Site replication traffic. Hence, this design methodology provides this factor for background consideration only, and it must not exclusively influence the numbers of domain controllers required for a Site.



Imposing a limitation on the number of domain controllers implemented within a Site will contribute to a lower utilisation of the bandwidth resources.

4.9.2.3. Determination of the Minimum Number of Domain Controllers Required

Consider the following when determining the minimum number of domain controllers required within each Site:

Factor A2: Definition of the criteria to support determination of the minimum number of domain controllers required for each Site

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to define the criteria to support the determination of the minimum number of domain controllers required for each Site.


When defining the criteria to support the determination of the minimum number of domain controllers required for each Site, consider the following:

When determining the minimum number of domain controllers required for each Site, it is necessary to justify each requirement for a domain controller. This is because the creation of each required domain controller is associated with financial and administrative overheads, which the organisation may have to justify.

The criteria to support the determination of the minimum number of domain controllers required for each Site represent the business and technical requirements of the organisation for the Site infrastructure of a forest. Hence, compliance with the defined criteria implies compliance with business and technical requirements. This hence justifies the creation of additional domain controllers due to compliance with these criteria.

Although the onus is with the organisation to define their criteria, this design methodology proposes the following examples of criteria to support the opportunity to disprove the null hypothesis for this process:

Each domain represented within a Site requires a minimum of two domain controllers to support redundancy and availability

Each Site required to support domain controllers, which advertise heavily accessed services, will require an additional dedicated domain controller for those services

Each Site required supporting 5000 or more users from a single domain will require a minimum of three domain controllers for that domain with the following minimum hardware specifications <hardware specifications stated in criterion>.

Using the above examples, execute the following:

Execute an analysis of the organisation to identify all applicable factors that may influence the number of domain controllers that require design and implementation within each required Sites

Define criteria to control the number of domain controllers for each required Site, as a reflection of business and technical objectives and requirements

Factor A3: Determination of the minimum number of domain controllers required in each appropriate Site




Has identified the requirements to disprove the null hypothesis for this process, and

Wishes to determine the number of domain controllers required in each appropriate Site


This design methodology proposes execution of the following approach to determine the number of domain controllers required in each appropriate Site:

Identify all factors applicable to the organisation, which may influence the opportunity to disprove the null hypothesis for this process. Evaluate each identified factor against the defined criteria. Where it is possible to identify compliance with one or more of the defined criteria, then determine the minimum number of domain controllers required within each Site to support these criteria.

Identify all factors applicable to the organisation, which support the null hypothesis for this process. Evaluate each identified factor against the defined criteria. Where it is possible to identify compliance with one or more of the defined criteria, then determine the minimum number of domain controllers required within each Site to support these criteria.

Correlate the results of these analyses and evaluations against the defined criteria and determine the minimum number of domain controllers required for each Site.


Execute an analysis to identify all applicable factors that will influence the requirements for more domain controllers within Sites

Execute an analysis to identify all applicable factors that will influence the requirements to reduce the numbers of domain controllers within Sites

Correlate the results of these analyses and evaluations and determine the minimum number of domain controllers required for each Site.

Document the justifications for the design and implementation of each required domain controller within each required Site.

Generate a diagram illustrating the minimum numbers of domain controllers for each domain in each Site, and their logical and physical placement within the required Sites for the organisation.

4.9.3. Determination of the Requirements for Universal Group Caching

Consider the following when determining the requirements for Universal Group Caching:

Factor B13: Understanding the approach towards determination of the requirements for the design and implementation of Universal Group Caching

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach towards determination of the requirements for the design and implementation of Universal Group Caching.




The null hypothesis for this process states that it is not necessary to design and implement Universal Group Caching unless it is possible to disprove this hypothesis.

This approach and supporting hypothesis reflect the limited scope of application of Universal Group Caching within most organisations.

Note that the design and implementation of Universal Group Caching negates the requirements to configure one or more Windows Server 2003 domain controllers within a Site as GC servers. Hence, requirements to disprove the null hypothesis for this process must hence reflect the requirements to replace GC servers within a Site with Universal Group Caching.

This design methodology hence proposes execution of the following approach towards determination of the requirements for the design and implementation of this feature:

Understand the features and functionality of Universal Group Caching

Understand the factors that will influence the opportunity to disprove the null hypothesis for this process, and hence support the design and implementation of Universal Group Caching within a Site

Define the criteria to support determination of the requirements for the design and implementation of Universal Group Caching

Identify all applicable requirements and evaluate against the defined criteria to determine the requirements for Universal Group Caching

Where it is possible to identify compliance with criteria to support the design and implementation of Universal Group Caching, and the appropriate Active Directory Sites where this feature is required, then it is necessary to exclude these Sites from the scope of deployment of GC servers.

Factor B14: Understanding Universal Group Caching

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the features of Universal Group Caching, prior to determination of the requirements for design and implementation.


Prior to determination of the requirements for the design and implementation of Universal Group Caching, it is necessary to understand the following concepts about this feature:

Universal Group Caching is a new feature introduced into Microsoft Windows Server 2003 Active Directory. This feature provides the ability to implement caching of universal group memberships on non-GC domain controllers.

The objective for the design and implementation of Universal Group Caching is to negate the requirements to configure one or more Windows Server 2003 domain controllers within a Site as Global Catalog (GC) Servers. The foundation for this objectives are:



To reduce the volume of Active Directory replication traffic to and from a Site specific to the Global Catalog

To reduce the resource overheads associated with the server hardware for domain controllers configured as GC servers within a Site, such as:

Local storage overheads associated with the Global Catalog “partition” for a forest on a domain controller

CPU and RAM resource overheads to support the GC role

The implementation of this feature requires the minimum forest functional level to be set to “Windows 2000”. This is the default forest functional level that permits the support for Windows NT 4.0, Windows 2000 and Windows Server 2003 domain controllers. The forest functional levels “Windows Server 2003 Interim” and “Windows Server 2003” will also support Universal Group Caching (see the Forest Plan process “selecting and raising the forest functional level” for details).

It is only possible to implement Universal Group Caching:

On Windows Server 2003 domain controllers, and

Only at the Site level, and not on individual Windows Server 2003 domain controllers

Hence, this design methodology deduces the following facts:

Because it is only possible to implement Universal Group Caching at the Site level, this feature requires consideration for design and implementation as a component of the Site Plan, and not the Domain Plan.

It is not possible to implement Universal Group Caching on individual Windows Server 2003 domain controllers within a Site

It is not possible to implement this feature on a Site supporting legacy Windows domain controllers (Windows NT 4.0 (BDCs) or Windows 2000)

It is important to note that although implementation of this feature at the Site level will enable Universal Group Caching for all Windows Server 2003 domain controllers (not configured as GC servers) within the configured Site, it will not prevent the configuration of Windows Server 2003 domain controllers as GC servers within the configured Site.

Implementation of this feature at the Site level creates a Universal Group Cache on Windows Server 2003 domain controllers in the configured Site. Each Windows Server 2003 domain controller will update the cache automatically every 8 hours from another Site that hosts a GC Server. The other Site is either a default Site (selected by the KCC process) or a Site manually nominated by an administrator.

It is possible to upgrade up to 500 universal group memberships within each scheduled refresh of the Universal Group Cache.

Windows Server 2003 domain controllers, not configured as GC servers and within a Site configured to enable Universal Group Caching, will not respond to LDAP queries on port 3268.

Factor B15: Factors influential in the opportunity to disprove the null hypothesis for this process



Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the factors, in the design and implementation of Universal Group Caching, influential in the opportunity to disprove the null hypothesis for this process.


This design methodology requires that it is only necessary to design and implement Universal Group Caching within one or more Sites where it is possible to disprove the null hypothesis for this process.

This design methodology hence proposes consideration of the following factors influential in the opportunity to disprove the null hypothesis for this process:

The numbers of domains within the forest and hence the size of the GC database

The number of changes that require replication to the Global Catalog within a typical working day

The levels of net available bandwidth within network links between Sites

The security considerations for the user of Universal Group Caching

The presence of applications and services that require connection to a GC server

The numbers of users in a remote Site

When attempting to understand the influence of the number of domains within a forest on the opportunity to disprove the null hypothesis for this process, consider the following:

The number of domains within a Windows Server 2003 forest will have a direct influence on the opportunity to disprove the null hypothesis for this process.

Where a Windows Server 2003 forest only supports a single domain, then this scenario does not support the opportunity to disprove the null hypothesis for this process. This is because the objectives for the design and implementation of Universal Group Caching are to reduce the volume of GC-related Active Directory replication traffic to and from a Site, and reduce storage overheads associated with the GC role, and so on. Within a single domain forest, the size of the Active Directory database (ntds.dit) on a domain controller configured as a GC server is the same as for a non-GC domain controller. Hence, it is not possible to identify any advantages associated with replacement of GC servers with Universal Group Caching in this scenario.

Note that all other scenarios in which the size of the Active Directory database on a GC server is either the same or not significantly larger than the size of the Active Directory database on a normal domain controller, will also not support the opportunity to disprove the null hypothesis for this process. For example, within a Windows Server 2003 forest with a dedicated (placeholder) forest root domain and one “production” domain, as the forest root domain will not support a significant number of custom objects, the size of the Active Directory database on a GC server is not significantly larger than on a non-GC domain controller.

The number of objects within an Active Directory forest will influence the size of the Global Catalog database, and hence the opportunity to disprove



the null hypothesis for this process. Hence, when attempting to understand whether the size of a GC database and the volume of GC-specific Active Directory replication traffic will support the opportunity to disprove the null hypothesis for this process, consider the following:

It is necessary to determine the size of the Active Directory database on a GC server, and execute a comparison to the Active Directory database size for domain controllers for each domain within a Site.

A GC server will hold all of the objects within each replicated naming context within a Windows Server 2003 forest, but only selected attributes of each object class. The Active Directory Schema for the forest defines the attributes for object classes replicated to a GC server. Note that it is possible to configure within the Schema the replication of attributes and their data values to the Global Catalog servers for the forest.

When attempting to perform a comparison of the size of an Active Directory database on a GC server and on a non-GC domain controller, the following formula provides an approximate guide:

(The full size of the domain partition for the domain a GC server belongs to) + (50% of the size of every naming context published to the Global Catalog for the forest).

Note that the result of this formula only provides an approximate guide to the size of the Active Directory database on a GC server. This is due to the variance in the objects held within the different naming contexts, the attributes of those objects published to a Global Catalog server, the values for the attributes published, and so on.

Where a Windows Server 2003 Active Directory forest supports a number of Active Directory domains (such as four or more), with each supporting many hundreds or thousands of objects, then the size of the Active Directory database on a GC server may be significantly larger than on a non-GC domain controller. In these scenarios, the design and implementation of Universal Group Caching may have a significant impact on reducing the volume of Active Directory replication data sent to and from the Site, and so on.

When attempting to understand the influence of the number of changes replicated to the Global Catalog in a typical working day on the opportunity to disprove the null hypothesis for this process, consider the following:

GC servers, in each Site within a forest, are required to update their database with all changes to each replicated naming context. Within an Active Directory forest where the number of changes generated, and that require replication, are significant, then this may influence the performance of a target GC server and / or the network link supporting the replication traffic.

It is only possible to identify an opportunity to disprove the null hypothesis for this process where the following is true:

The GC server(s) within a remote Site will exhibit significant degradations in performance (via over utilisation of hardware resources) during each replication cycle, and / or

The network link to a remote Site will exhibit a significant degradation in levels of available bandwidth during each replication cycle, to specifically support Global Catalog replication



Note that the onus is with the organisation to define the extent of “significant degradation in performance” of GC servers and network links (see later for definition of criteria).

Where it is not possible to identify compliance with either or both of these scenarios, then the volume and frequency of changes, which require replication to Global Catalog servers, will not support the opportunity to disprove the null hypothesis for this process. Hence, the design and implementation of Universal Group Caching is not justifiable.

Where it is possible to identify compliance with either or both of the above scenarios, then the design and implementation of Universal Group Caching at the relevant remote Site may generate the following results:

An improvement in the performance of domain controllers in the Site, as they will not be required to replicate vast volumes of Active Directory changes destined for Global Catalog servers

An improvement in the performance on network links to and from the Site, as they will not be required to transport vast volumes of Active Directory changes destined for Global Catalog servers in the Site

When attempting to understand the influence of the security considerations for Universal Group Caching on the opportunity to disprove the null hypothesis for this process, consider the following:

The default refresh period for a universal group membership cache on a Windows Server 2003 domain controller is eight hours. This parameter is not configurable, and the completion of a refresh cycle depends upon the following:

The presence of a functioning WAN link to another Site that hosts a GC server

The presence of a functioning GC server in the source Site

The latency associated with the connection and retrieval of the universal group cache from the source GC server in the remote Site

Any of these variables can influence the convergence of a universal group membership cache on a Windows Server 2003 domain controller in a remote Site with that on the source GC server. Hence, where there is a delay or inability to complete a refresh cycle, any changes made to the memberships of universal groups between updates will not be available within the remote Site. It is hence necessary to consider the potentially unwanted security implications associated with the implementation of this feature.

Where an organisation identifies this potential security risk as significant, then this risk supports the null hypothesis for this process, and hence negates the opportunity to design and implement Universal Group Caching.

When attempting to understand the influence of the requirements to support applications that access Global Catalog servers on the opportunity to disprove the null hypothesis for this process, consider the following:

The implementation of Universal Group Caching at a Site level logically negates the requirements for the configuration of local GC servers (although this is still possible). In this scenario, the Site will hence not provide local support for any applications or processes that require connection to a Global Catalog server, via LDAP on port 3268. Normal domain controllers, not configured as GC servers, will only respond on port 389, and not 3268.



Hence, all locally generated queries directed to LDAP port 3268 may travel across a network link to another Site.

In this scenario, the requirement to support local application queries on port 3268, such as the queries generated by an Exchange 2000 or Exchange Server 2003 server, negate the requirements to design and implement Universal Group Caching.

When attempting to understand the influence of the numbers of users in remote Sites on the opportunity to disprove the null hypothesis for this process, consider the following:

Normal domain controllers configured with a Universal Group Cache can only efficiently support the simultaneous logon requirements of up to 100 local users. Where the number of users that may simultaneously logon within a Site exceeds this capacity, then this design methodology recommends against the design and implementation of this feature, and instead recommends the configuration of one or more GC servers.

Note the following about the recommended figure of 100 simultaneous logons:

Within most Sites supporting many hundreds of users, not all users may simultaneously logon. For example, the users may work in shifts, and hence generate staggered logon requests.

This figure of 100 users is provided for guidance only and the actual number of users that can be supported using this feature is dependent upon many other variables that include (for example):

The server hardware specifications of the local domain controller(s)

The workload pattern and statistics of the local domain controller(s)

Monitoring of these variables on local domain controllers may provide indication of the capabilities of these servers to handle caching of universal group memberships.

Factor A4: Definition of criteria to support determination of the requirements for the design and implementation of Universal Group Caching

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to define criteria to support the determination of the requirements for the design and implementation of Universal Group Caching.


When defining the criteria to support the determination of the requirements for the design and implementation of Universal Group Caching, consider the following:

The implementation of Universal Group Caching within one or more Sites for a forest can have a significant impact on Active Directory operations within those Sites. It is hence necessary to justify the execution of this design activity via the definition of criteria that reflect the business and technical objectives and requirements for this feature.

Although the onus is with the organisation to define their criteria, this design methodology provides the following examples of criteria. These criteria



reflect requirements for compliance with strict prerequisites for the design and implementation of Universal Group Caching.

This design methodology deems it only possible to disprove the null hypothesis, and hence design and implement Universal Group Caching, for an Active Directory Site, where the following (example criteria) are true:

The Site only supports Windows Server 2003 domain controllers

The Site will support no more than 100 concurrent logons by users

The Site belongs to an Active Directory Forest supporting more than three production domains

The size of the Active Directory database on a GC server in the forest is greater than 25% of the size of the Active Directory database on a domain controller for a domain hosting the largest number of objects in the forest

The levels of net available bandwidth will drop to less than 10% during each scheduled replication of the Global Catalog to the Site

The hardware resource utilisation on a GC Server within the Site will exceed 90% CPU and disk queue lengths of greater than 2 for sustained periods greater than 10 minutes, during and after each scheduled replication of the Global Catalog to the Site


Execute an analysis of all proposed Sites within the organisation, and identify all applicable factors that may influence the opportunity to disprove the null hypothesis for this process.

Define criteria to determine the requirements for the design and implementation of Universal Group Caching, to reflect specific business and technical objectives and requirements.

Factor A5: Determination of the requirements for the design and implementation of Universal Group Caching



Wishes to define criteria to support the determination of the requirements for the design and implementation of Universal Group Caching


When determining the requirements to design and implement Universal Group Caching, consider the following:

This design methodology proposes execution of the following approach to determine the requirements for the design and implementation of Universal Group Caching on one or more Sites within a forest:

Select a Site within the forest and evaluate against all defined criteria to support the determination of the requirements for Universal Group Caching.



Where it is not possible to attain compliance with all of the defined criteria, then it is necessary to determine the requirements for the design and implementation of Global Catalog servers in that Site.

Where it is possible to attain compliance with all of the defined criteria, then it is possible to design and implement Universal Group Caching.

Where there is a requirement to design and implement Universal Group Caching, then consider the following:

Enabling Universal Group Caching at a Site provides the option to either manually select a source Site for the cache updates, or the option to allow the Knowledge Consistency Checker (KCC) to select the appropriate update Site.

This design methodology recommends allowing KCC to manage the identification and use of the source Site for the cache updates. However, when determining the requirements to manually select a source Site for the cache updates, or allow KCC to select the Site, consider the following:

Allowing the KCC process to select the Site for refreshing the cache permits the following:

A minimum of one hop between the source Site and the destination Site

KCC will ensure redundancy for the refresh cycle, where the forest supports three or more Sites. When a GC server within a source Site is not available, the KCC process will automatically reselect another suitable Site where this is possible. The manual selection of a source Site will require the manual reselection of an alternative Site in this scenario.

Note that where the manual reselection of an alternative Site is only initiated after a period of time, which exceeds one refresh cycle, there will be a delay in updating of the universal group membership cache on the Windows Server 2003 domain controllers.

However, allowing the automatic selection of a source Site for refreshing the universal group membership cache by the KCC process does not provide any control over the selection of specific GC servers. This may be an issue where the GC servers selected by the KCC process are already very heavily utilised and would not benefit from an additional workload.

Note that there may not be a measurable impact on the performance and responsiveness of a source GC server, due to the static configuration of the refresh cycle to execute only once every eight hours. However where multiple remote Sites are configured by the KCC process to contact a single Site (for example, the hub Site of a hub-and-spoke Site Link topology) then the source GC server may be overwhelmed by refresh requests from multiple remote Sites.


Evaluate the defined criteria against each required Site within the forest and determine the requirements for the design and implementation of Universal Group Caching.

Where it is possible to identify the requirements for the design and implementation of Universal Group Caching, for one or more Sites, then



determine the requirements for the manual or automatic selection of the source Site for cache updates.

4.9.4. Determination of the Minimum Number of GC Servers Required

Consider the following when determining the minimum number of GC servers required for each Site within the forest:

Factor B16: Understanding the approach towards determination of the minimum number of GC servers for each Site



Wishes to understand the approach towards determination of the minimum number of GC servers for each Site


The null hypothesis for this process states that each Site will require a minimum of one GC server. Hence, the objective of this step is to determine the opportunity to disprove this null hypothesis and hence identify the following requirements:

The requirement to design and implement two or more GC servers within a Site, or

The requirement to design and implement a Site with no GC servers

The execution of this step within this process will evaluate all factors that may influence the opportunity to disprove the null hypothesis for this process.

This design methodology proposes execution of the following approach toward determination of the minimum number of GC servers required for each Site:

Understand the factors that will support the opportunity to disprove the null hypothesis for this process, and hence require the design and implementation of either or both of the following:

Two or more GC servers within the appropriate Site or Sites

No GC servers within the appropriate Site or Sites

Define the criteria for the determination of the minimum number of GC servers required for each Site.

Identify all applicable factors and evaluate against the defined criteria, and hence determine the minimum number of GC servers for each Site.

Factor B17: Understanding the approach to disprove the null hypothesis for this process, with respect to the number of GC servers required within each Site.

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach to disprove the null hypothesis for this process, with respect to the number of GC servers required within each Site.




This design methodology recognises the following two requirements to disprove the null hypothesis for this process (with respect to GC servers):

To identify the requirements for the design and implementation of two or more GC servers within a Site

To identify the requirements to design and implement an Active Directory Site without any GC servers

Where an organisation wishes to identify the requirements to design and implement two or more GC servers within an Active Directory Site, consider the following:

Due to the generation of administrative and financial overheads, the design and implementation of two or more GC servers within an Active Directory Site must reflect specific business and technical requirements.

This design methodology proposes execution of the following approach to determine the requirements for two or more GC servers within an Active Directory Site:

Determine compliance with the prerequisites to the design and implementation of two or more GC servers within an Active Directory Site

Understand the factors that may influence the requirements for the design and implementation of two or more GC servers

Define the criteria to support the determination of the requirements for the design and implementation of two or more GC servers within a Site

Evaluate all applicable factors against the defined criteria

Where an organisation wishes to identify the requirements to design and implement an Active Directory Site without any GC servers, consider the following:

As the implementation of an Active Directory Site without any GC servers also supports the design and implementation of Universal Group Caching at that Site, this design methodology does not consider this requirement here, but within the previous step for this process.

This design methodology proposes execution of the following approach to determine the requirements for the design and implementation of an Active Directory Site with no GC servers:

Determine compliance with the prerequisites to the design and implementation of an Active Directory Site with no GC servers

Understand the factors that may influence the requirements for the design and implementation of an Active Directory Site with no GC servers

Define the criteria to support the determination of the requirements for the design and implementation of an Active Directory Site with no GC servers

Evaluate all applicable factors against the defined criteria

Factor B18: Understanding the factors influential in the determination of the number of GC servers required within each Site.



Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the factors influential in the determination of the number of GC servers required within each Site.


When determining the requirements for the design of two or more GC servers within an Active Directory Site, consider the following:

Prior to the design and implementation of multiple GC servers, it is necessary to ensure compliance with the following prerequisites:

The network link to a Site has sufficient bandwidth capacity to support the transfer of Active Directory replication traffic specifically for multiple GC servers within the Site.

It is possible to identify within the Site domain controllers with adequate hardware resources to support configuration as GC servers

The Site, as a physical location, has adequate facilities to ensure the physical security of each additional GC server

The factors that influence the requirements to design and implement two or more GC servers within a Site include:

The requirements for redundancy / high-availability of the GC server role within a Site

The increase in inter-Site replication traffic from GC replication

The impact on hardware resource utilisation for the domain controller host of the Global Catalog service

When understanding the requirements for redundancy / high-availability of the GC role, consider the following:

The dependency on the presence and normal operation of a GC server for the forest may be critical to user logon and to directory-enabled applications that query the forest via a GC server on port 3268. Examples of such applications include Microsoft Exchange 2000 and Exchange Server 2003 that generate the Global Address List from a query sent to a GC server for the forest.

The requirement to implement more than one GC server within a Site to meet these stated requirements is dependent upon the following:

The impact on business continuity of the absence of a GC server within a Site

The impact on business continuity of the time required to rebuild a GC server for a forest

The feasibility and capability for failover of GC queries to allow them to be diverted to other GC servers within other connected Sites in the forest

As discussed earlier for the redundancy / high-availability of domain controllers, rebuilding a domain controller need not be a lengthy process. However, re-population of a Global Catalog may take time, depending upon the:

Presence of another local GC server within the Site / within a remote Site



The net available bandwidth in a WAN link to another Site that hosts a GC server where the local Site does not have an additional GC server

The number of naming contexts that are replicated to the Global Catalog for the forest

The number of attributes replicated to the Global Catalog for the forest

The number of objects within the forest that are replicated to the Global Catalog for the forest

For example (at a very high-level), in a forest with only one or two domains and only a couple of thousand objects replicated to the Global Catalog, re-population of a Global Catalog for a rebuilt GC server may not take a long time, even across a WAN link. However, for a forest with tens of domains and hundreds of thousands of objects, re-population of a GC server may take a very long time. There is hence a requirement to consider the repopulation time when determining the requirements for multiple GC servers. The presence of an additional local GC may hence reduce the time required to restore a failed GC in the same Site.

When understanding the increase in inter-Site replication traffic from GC replication on the requirements to design and implement multiple GC servers within a Site, consider the following:

Because a GC server holds a copy of every object published to the Global Catalog for the forest, the potential number of changes to any of the published attributes of these objects that have to be replicated to all GC servers within a forest may be vast.

For a forest with a large number of domains and objects widely distributed across a large Site infrastructure, the impact on a supporting WAN infrastructure of GC replication may be substantial. The greater the number of GC servers created within a forest, the greater (linearly) the volume of replication traffic generated and hence requires transmission across network links.

Where the supporting WAN infrastructure is unable to handle the extra inter-Site GC replication traffic, there may be replication latencies between GC servers within the forest.

Where applications and processes rely upon an up to date GC database, database divergence due to replication latencies may be unacceptable.

When understanding the impact on hardware resource utilisation for the domain controller host of the Global Catalog service on the requirements to design and implement multiple GC servers within a Site, consider the following:

The addition of the Global Catalog service to a domain controller that is already over utilised / under resourced may impair the service that the domain controller can provide for the domain partition it hosts.

The selection of a domain controller to host the Global Catalog service should hence take into account the current function, role, and usage of the potential domain controller host.

Where all potential domain controllers within a Site are all heavily utilised and the addition of the Global Catalog service would impede their service provision, it may be necessary to create an additional domain controller for a domain in that Site, dedicated to hosting the GC server role for the Site.



The number of queries a GC server is able to handle on port 3268 is dependent upon the type of query the source of the query, and the server hardware resources available on the GC server.

Queries to determine the Universal security group memberships of users (generated by a domain controller) are not so resource intensive as queries generated by, for example, a Microsoft Exchange 2000 or Exchange Server 2003, to generate a Global Address List. The CPU and RAM resources on a GC server should reflect the number of queries it is expected to handle

It is necessary to monitor the utilisation of these resources on a GC server to determine the impact of a high volume of queries to the GC server. The implementation of an additional GC server may assist in load balancing the queries and hence improve the performance of the GC servers and the applications / processes that are generating the queries.

The selection of a domain controller for hosting the Global Catalog for the forest must take into account the disk space requirements for the GC server. For each naming context a Global Catalog holds objects for, approximately 50% of the full size of that naming context is replicated to a Global Catalog server.

Realistically, with most new servers bought / leased, there are usually many gigabytes of disk space available and disk space is not very expensive. However, the extensibility of the disk space on a domain controller may be an issue and requires consideration for scalability.

Factor A6: Determination of the requirements for two or more GC servers within an Active Directory Site



Wishes to determine the requirements for the design and implementation of two or more GC servers within an Active Directory Site


This design methodology proposes execution of the following approach to determine the number of GC servers required in each appropriate Site:

Define criteria to reflect business and technical requirements to support either two or more GC servers, or no GC servers at all, in specific Sites

Identify all factors applicable to the organisation, which may influence the opportunity to disprove the null hypothesis for this process. Evaluate each identified factor against the defined criteria.

Where it is possible to identify compliance with one or more of the defined criteria, then determine the minimum number of GC servers required within each Site to support these criteria.


Identify all applicable factors that will influence the requirements to design and implement two or more GC servers within a Site

Define the criteria to qualify these requirements



Analyse all Sites and evaluate against the defined criteria

Identify all Sites that will require either two or more GC servers or no GC servers. For Sites requiring two or more GC servers, determine the minimum number of GC servers required within these Sites.



5. Design for Preferred Bridgehead Servers

This process requires execution by all organisations planning the design and implementation of a multiple Site Active Directory forest.


The objectives of this process are to assist an organisation in the execution of the following tasks associated with bridgehead servers in this Site infrastructure:

Determination of the requirements for the manual designation of preferred bridgehead servers within one or more Sites in the Site infrastructure, and

Where there is a requirement for the manual designation of preferred bridgehead servers, then determination of the number of preferred bridgehead servers required in the appropriate Sites


The Knowledge Consistency Checker process on the first domain controller introduced to a Site will function, by default, under the context of the role of the Inter-Site Topology Generator (ISTG) for the Site. The responsibilities of the ISTG role are:

To select the bridgehead servers for the Site, and

To ensure that the KCC process running on this domain controller reviews the inter-Site topology, to create inbound replication connection objects to bridgehead servers within that Site

It is possible to take manual control over these responsibilities of the ISTG role, and hence manually designate specific domain controllers within a Site as “preferred bridgehead servers”. Note that the role of “preferred bridgehead server” is only applicable to a transport protocol and naming context within a Site.

The manual designation of “preferred bridgehead servers” may be required to control the manifestation of replication latencies or failures, as discussed later within this process.

Note that execution of this procedure requires the following security context:

A member of the Domain Admins group (in the domain of the selected domain controller), or

A member the Enterprise Admins group in Active Directory, or

An account that has been delegated the appropriate authority


This design methodology strongly recommends the automatic selection and management of preferred bridgehead servers for Active Directory Sites, and only supports manual intervention where it is possible to identify qualified business and / or technical requirements to justify this action.

Hence, this design methodology states the following null hypothesis for this process:

“The automatic selection of the bridgehead servers for each Active Directory Site by the KCC (within the context of the ISTG role within each Active Directory Site) will allow the successful replication of all of the naming contexts within the Active Directory forest without any replication latency or failures”



It is then necessary to execute investigations to disprove this null hypothesis, and hence identify the requirements for the manual designation of preferred bridgehead servers.

Where it is not possible to disprove this null hypothesis, then the null hypothesis stands, and there is no requirement to generate a design for preferred bridgehead servers within this Site Plan.

To reflect the requirements to disprove these null hypotheses, this design methodology proposes the following approach for the execution of this process:

1. Determine the requirements for the manual designation of preferred bridgehead servers via consideration of the factors that:

a. Support the opportunity to disprove the null hypothesis for this process and hence support the manual designation of one or more preferred bridgehead servers

b. Support the null hypothesis and hence prevent the manual designation of preferred bridgehead servers

2. Where it is possible to identify the requirements for the manual designation of preferred bridgehead servers, then determine the number of bridgehead servers required in each appropriate Site


Based upon the above approach, the process to design preferred bridgehead servers is composed of the following two components:

Determination of the requirement to use preferred bridgehead servers within a Site infrastructure for a forest

Determination of the number of preferred bridgehead servers required within each appropriate Site



Site Plan – Inter-Component Dependencies for Process to Design Preferred Bridgehead Servers

START

Determination of the number of preferred bridgehead servers

required in Sites

Determination of the requirements for the design of preferred bridgehead servers




Identification of the requirements to manually designate preferred bridgehead servers for an Active Directory forest, and

Identification of the number of bridgehead servers that will be required within each appropriate Site



5.7. Process to Design Preferred Bridgehead Servers

Site Plan – Process to Design Preferred Bridgehead Servers

STARTExecute

A1

Execute

B1 – B8

Execute

A2



NO

YES

END



Consider the following information when determining the design requirements for preferred bridgehead servers within the Site infrastructure.

Presented within the following two sections are the considerations for this process:

1. Considerations for the determination of the requirements for preferred bridgehead servers

2. Considerations for the determination of the number of preferred bridgehead servers required

5.8.1. Determination of the Requirements for Preferred Bridgehead Servers

Consider the following when determining the requirements for the manual designation of preferred bridgehead servers within one or more Sites for this Site infrastructure:

Factor B1: Understanding the approach towards determination of the requirements for preferred bridgehead servers



Wishes to understand the approach towards determination of the requirements for preferred bridgehead servers


The null hypothesis for this process states that it is necessary to allow the KCC process within each Site to automatically designate and manage the bridgehead servers for that Site. Hence, the objective of this step is to determine the opportunity to disprove this null hypothesis and hence identify the requirement to designate preferred bridgehead servers manually.

Where it is possible to identify this requirement, then it is necessary to execute the following steps:

Determine the Sites that require manual designation of preferred bridgehead servers, and

Determine the number of preferred bridgehead servers required within each identified Site



The execution of this step within this process will assist an organisation in the evaluation of all factors that may influence the opportunity to disprove the null hypothesis for this process. It is important to execute this step regardless of any preconceptions as the requirements for preferred bridgehead servers, as even where none of the factors discussed below may currently apply within an organisation, it is important to raise awareness of their influence in case they arise in the future.

This design methodology proposes execution of the following approach toward determination of the requirements for the manual designation of preferred bridgehead servers:

Understand the factors that will support the opportunity to disprove the null hypothesis for this process, and hence require the manual designation of preferred bridgehead servers

Understand the factors that will support the null hypothesis and hence favour the automatic designation and management of bridgehead servers by the KCC process

Determine the requirements for the manual designation of preferred bridgehead servers

This design methodology recognises the following factors as been influential in the determination of the requirements for the manual designation of preferred bridgehead servers:

The presence of firewalls between Sites

The requirements to facilitate troubleshooting of inter-Site replication issues

The requirements to load balance inbound and outbound replication traffic across domain controllers within a Site

This design methodology recognises the following factors as been influential in supporting the null hypothesis for this process:

The improved design for the ISTG algorithm

The consequences of bridgehead server failure

The administrative and financial overheads associated with the manual designation and management of multiple preferred bridgehead servers

The consequences of moving manually designated bridgehead servers between Sites

Factor B2: Understanding the influence of the presence of a firewall protecting an Active Directory Site on the opportunity to disprove the null hypothesis for this process


Has one or more Active Directory Sites protected by a firewall implementation, and

Wishes to understand the influence of the presence of a firewall on the opportunity to disprove the null hypothesis for this process




Within most organisations distributed across multiple physical locations, the network links between the physical locations are typically VPN connections, and not leased lines. A VPN connection is much cheaper to implement and maintain than dedicated leased lines, and most ISPs can provide VPN connections with high levels of guaranteed bandwidth and / or minimal contention.

However, as the connection is not a dedicated point-to-point network link, there are significant security issues to address. The ingress and egress points for Internet connectivity for a Site require firewall protection. The firewall implementation may be a single firewall or a dual-firewall implementation to generate a perimeter network or “demilitarized zone” (DMZ).

Within an organisation, where a remote location, protected by a firewall implementation, requires representation within the Active Directory forest as a Site, then it is necessary to designate a preferred bridgehead server manually, to become the “firewall proxy server”. The firewall proxy server hence becomes the contact point for exchanging information with other domain controllers in remote Sites.

Without the manual designation of a preferred bridgehead server, as the “firewall proxy server”, the Site may be unable to retrieve directory updates from other Sites within the forest.

In this scenario, it is also important to ensure that all inter-Site network traffic is encrypted using, for example, IPSec. Note that to support the implementation of IPSec, it is necessary to enable IP forwarding and the following input and output filter configurations:

Input Filters

IP Protocol ID of 51 (0x33) for inbound IPSec Authentication Header traffic

IP Protocol ID of 50 (0x32) for inbound IPSec Encapsulating Security Protocol traffic

UDP port 500 (0x1F4) for inbound IKE negotiation traffic

Output Filters

IP Protocol ID of 51 (0x33) for outbound IPSec Authentication Header traffic

IP Protocol ID of 50 (0x32) for outbound IPSec Encapsulating Security Protocol traffic

UDP port 500 (0x1F4) for outbound IKE negotiation traffic

Factor B3: Understanding the influence of the requirements to facilitate troubleshooting of inter-Site replication issues on the opportunity to disprove the null hypothesis for this process

Criteria for Execution: The considerations for this factor are to be explored where an organisation:

Has a large number of Sites within their Active Directory forest, and

Wishes to understand the influence of the requirements to facilitate inter-Site troubleshooting on the manual designation of preferred bridgehead servers




An important step in troubleshooting exercises for inter-Site replication is to identify the domain controller(s) acting as bridgehead servers for a transport protocol and naming context within the Site.

Within an organisation, with a Site infrastructure supporting a large number of Sites, multiple replicated naming contexts, and a centralised administration model, identification of the bridgehead server within a Site for a transport protocol and naming context is not a simple process if KCC is required to automatically designate and managed the bridgehead servers.

In this scenario, the only way to determine the bridgehead server for a Site is to inspect the properties of connection objects created by KCC for each Server within the Site.

The domain controller with a connection object to pull directory information for a naming context from a domain controller within a remote Site will be a bridgehead server for that Site. For a Site with many domain controllers and many connection objects representing intra-Site and inter-Site replication, identification of a bridgehead server for a Site may be time consuming.

Hence, these scenarios support the opportunity to disprove the null hypothesis for this process, and hence the manual designation of one or more preferred bridgehead servers for transport protocols and naming contexts within a Site.

Factor B4: Understanding the influence of the requirement to load balance inbound and outbound replication traffic for a Site on the opportunity to disprove the null hypothesis for this process

Criteria for Execution: The considerations for this factor are to be explored where an organisation:

Has multiple Sites arranged within a hub-and-spoke arrangement, and

Wishes to understand the influence of the requirements to load balance intra-Site and inter-Site replication


Where one or more Sites within a Site infrastructure support inbound and outbound replication to multiple other Sites, the Windows Server 2003 KCC process automatically load balances inbound and outbound connections across all available bridgehead servers.

Where a Site supports a list of preferred bridgehead servers (that support all applicable transport protocols and replicated naming contexts), then the KCC process will use this list to load balance the inbound and outbound connections. However, the KCC process will load balance inbound and outbound connections across all domain controllers within that Site where:

A Site does not support a list of preferred bridgehead servers or

The list of preferred bridgehead serves does not support all applicable transport protocols and / or all replicated naming contexts, and hence the KCC process will ignore this list of preferred bridgehead servers

It is important to note that load balancing by the KCC process is not dynamic, and does not check if the bridgeheads are in a symmetric balance, or reassign



existing connections to other bridgehead servers where there is a requirement to move these servers out of the Site or the servers become unavailable.

Within an Active Directory Site, it may be possible to identify the following requirements to control the selection of bridgehead servers by the KCC process:

An organisation may wish to ensure that certain domain controllers within a hub Site, not powerful enough to reliably perform and handle the inter-Site replication requirements for that Site, are not selected by the ISTG to act as a bridgehead server for the Site.

An organisation may wish to define a list of preferred bridgehead servers to ensure that specific domain controllers receive an equal workload in handling inbound and outbound replication traffic. Inbound replication is serialised, which means that a single domain controller associated with multiple inbound replication connection objects will only be able to process the replication traffic from one domain controller at a time. Bridgehead servers process outbound replication traffic in parallel, and hence send out replication traffic simultaneously to multiple domain controllers. Because inbound replication traffic is serialised, it is subject to the following bottlenecks:

Low bandwidth availability within a WAN link that will send the replication traffic. Low bandwidth will mean low data throughput, which may hence result in replication latency.

Substantial demands placed upon the domain controller’s hardware resources (CPU and memory) during inbound replication will result in slower writes to the Active Directory database on the domain controller. This may also result in replication latency.

Because inbound replication is resource intensive on the domain controllers processing this traffic, the selection of specific domain controllers to act as preferred bridgehead servers with the required hardware resources can improve replication performance.

Factor B5: Understanding the influence of the improved algorithm for the ISTG role in Windows Server 2003 on the opportunity to support the null hypothesis for this process.


Is considering the manual designation of preferred bridgehead servers based upon the legacy capabilities of Windows 2000 Active Directory and the ISTG role, and

Wishes to understand the influence of the improved ISTG algorithm on the opportunity to support the null hypothesis for this process


Within Windows 2000 Active Directory Site infrastructures, the ISTG algorithm was unable to accurately calculate the inter-Site replication topology for over 200* (*this is a non-specific and arbitrary figure) Sites. This resulted in replication latency and failures, and demanded the manual intervention to designate preferred bridgehead servers, and so on.



However, in Windows Server 2003 Active Directory Site infrastructure, the ISTG algorithm is significantly improved, and can support in the region of 5000* (*this is a non-specific and arbitrary figure) Active Directory Sites for a forest.

Note that in order to activate these advanced features of the ISTG algorithm, it is necessary to raise the functional level of the forest to “Windows Server 2003”. This hence implies the cessation of support for all legacy (Windows NT 4.0 and Windows 2000) domain controllers within any domain in the forest. See the Forest Plan process “selecting and raising the forest functional level” for details.

Because of this increased capability and scalability of the ISTG algorithm, this may hence support the null hypothesis for this process, and hence negate the requirements for the manual designation of one or more bridgehead servers.

Factor B6: Understanding the influence of bridgehead server failure on the opportunity to support the null hypothesis for this process.

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of bridgehead server failures on the opportunity to support the null hypothesis for this process, and hence negate the manual designation of one or more bridgehead servers.


Following the manual designation of one or more preferred bridgehead servers within an Active Directory Site, this automatically changes the behaviour of the ISTG role within that Site to support this change. The ISTG role will now no longer automatically designate or maintain the bridgehead server role for that Site.

Hence, if a manually designated preferred bridgehead server suffers a failure and requires downtime for repairs or maintenance, then the ISTG role holder will not automatically designate a replacement bridgehead server.

This may result in the absence of replication to and from that Site to other remote Sites within the forest, until the manual designation of another bridgehead server or the removal of all manual designations for preferred bridgehead servers within the Site, which will re-instate the full role of the ISTG for that Site.

It is important to note that the ISTG role will only generate inbound replication connection objects and not outbound.

For example, a domain (domain A) has two Sites (Site1 and Site2) with two domain controllers within each Site (Site1 = DC1 and DC2; Site2 = DC3 and DC4). Within Site1, DC1 is the manually designated preferred bridgehead server, and within Site2, DC3 is the manually designated preferred bridgehead server. The following diagram illustrates this scenario:



DC1

DC2

SITE 1

Preferred bridgehead

server

DC3

DC4

SITE 2

Preferred bridgehead

server

Figure 22.1: Example Scenario for Bridgehead Server Failure

If, in this scenario, DC1 experiences a failure, then DC2 would be unable to communicate to DC3 or DC4 in Site2. It is possible to designate DC2 the role of the bridgehead server for Site1, and create a connection object to DC3, however DC3 and DC4 in Site2 will still not be able to communicate to DC2 because they will have no knowledge of DC2s new status as the bridgehead server for Site1. This is because there is no inbound replication connection object from DC2 to DC3.

Hence, to resolve this issue, an administrator in Site2 at DC3 would have to designate DC2 in Site1 as the preferred bridgehead server for Site1. Active Directory will write the designation of DC2, as the preferred bridgehead server for Site1, to the Configuration partition. DC4 in Site2 will hence receive this Configuration partition update from DC3 via intra-Site replication. DC3 would now be aware of DC2’s status and create an inbound connection object from DC2, and hence reinstating full two-way inter-Site replication.

Factor B7: Understanding the influence of administrative and financial overheads for multiple preferred bridgehead servers on the opportunity to support the null hypothesis for this process


Has a multiple Site and domain forest infrastructure, and

Wishes to understand the influence of administrative and overheads on the opportunity to support the null hypothesis for this process, and hence negate the manual designation of preferred bridgehead servers




The manual designation of bridgehead servers within a Site must support each required transport protocol (IP and / or SMTP) and each naming context replicated to and from the Site (except for Application Directory Partitions with a selective replication topology). Hence, if an organisation has multiple domains represented within each Site, and there are multiple Sites within the forest, this could represent a large number of bridgehead servers to manage within each Site.

Note that this design methodology recommends that each preferred bridgehead server is a GC server as well, and this hence has an impact on the minimum hardware specifications for these servers, and the volume of replication traffic.

Factor B8: Understanding the influence of the requirements to move preferred bridgehead servers between Sites on the opportunity to support the null hypothesis for this process

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has multiple Sites, preferred bridgehead servers within a few Sites and may wish to move domain controllers between Sites.


It is important to note that the designation of a domain controller to be a preferred bridgehead server within a Site is a function of the domain controller and not the Site. Hence, moving a preferred bridgehead server to another Site will retain its status as a preferred bridgehead server and now operate under that context within the destination Site.

If the destination Site does not have any preferred bridgehead servers designated, then the arrival of a preferred bridgehead server into the Site will change the behaviour of the ISTG role within that Site to support the use of preferred bridgehead servers. This may hence have serious consequences for that Site. For example, there may be a lack of failover to another preferred bridgehead server within that Site should the new preferred bridgehead server fail; lack of replication of a directory partition should the newly arrive preferred bridgehead server not require a specific directory partition that other domain controllers within the Site do, and so on.

Note that the source Site, for the moved bridgehead server, may also suffer serious consequences because of the move. For example, if the domain controller that is moved represented the only preferred bridgehead server within that Site and no other bridgehead servers are manually selected, there will be a delay in replication whilst the ISTG role resumes its full functionality for that Site and automatically designates replacement bridgehead servers for that Site and created inbound replication connection objects.

If there were, however, other preferred bridgehead servers still in the source Site but they did not replicate a same directory partition(s) as the moved domain controller, then replication for that directory partition to that Site will cease until a replacement bridgehead server for that partition is manually designated for the Site.

Factor A1: Determination of the requirements to designate preferred bridgehead servers within one or more Active Directory Sites in the Site infrastructure


Has considered all factors that will support the opportunity to disprove the null hypothesis and factors that support the null hypothesis, and



Wishes to determine the requirements for the manual designation of one or more preferred bridgehead servers


Following evaluation of all factors outlined above, it is necessary to determine the requirements to designate preferred bridgehead servers within specific Sites within the Site infrastructure.

This design methodology proposes execution of the following approach to determine the requirements to disprove the null hypothesis for this process:

Evaluate all factors that will support the opportunity to either disprove the null hypothesis for this process, or support the null hypothesis, and then identify all applicable factors within the organisation.

If it is possible to identify one or more requirements for the manual designation of preferred bridgehead servers, then identify the Sites for these requirements. If it is not possible to identify any applicable factors that support the null hypothesis, then it is not necessary to designate preferred bridgehead servers.

Following the identification of the requirements for preferred bridgehead servers, it is necessary to execute the next step within this process, to determine the number of bridgehead servers required in each appropriate Site.


Identify all applicable factors that will support and / or disprove the null hypothesis

Determine the requirements for the manual designation of preferred bridgehead servers

Where there is a requirement to designate preferred bridgehead servers, then identify the Sites

Document all requirements for the manual designation of preferred bridgehead servers and the justifications for the requirements.

5.8.2. Determination of the Number of Preferred Bridgehead Servers Required

Consider the following where an organisation has identified the requirements for the manual designation of preferred bridgehead servers and wishes to determine the number of bridgehead servers required for each applicable Site:

Factor A2: Determination of the number of preferred bridgehead servers required within the appropriate Active Directory Sites in the Site infrastructure


Has identified the requirements for the manual designation of preferred bridgehead servers and identified the appropriate Sites, and

Wishes to determine the number of preferred bridgehead servers required in each appropriate Site




When attempting to determine the number of preferred bridgehead servers required for each appropriate Site, this design methodology proposes execution of the following approach:

Understand the factors directly influential in the determination of the number of preferred bridgehead servers required for appropriate Sites

Understand the factors indirectly influential in the determination of the number of preferred bridgehead servers required for appropriate Sites

Evaluate and identify the factors applicable to the organisation

Determine the minimum number of preferred bridgehead servers required for each applicable Site, to support all identified values for these variables

This design methodology recognises the following variables that may directly influence the number of preferred bridgehead servers required for an Active Directory Site:

The following factors influential in the manual designation of preferred bridgehead servers:

The presence of firewall implementations in between inter-Site replication links

The requirements to facilitate troubleshooting of inter-Site replication

The requirements to control the load balancing of inbound and outbound replication across specific domain controllers

The number of naming contexts that require full and partial (to GC servers) replication to and from a Site, as bridgehead servers must support all required naming contexts

The presence of a centralised or decentralised change control infrastructure within the organisation will have a direct influence on the number of preferred bridgehead servers required. For example, where an organisation has a centralised change control infrastructure and all changes to the Active Directory are performed in one or a few central Sites, then these changes can be pushed out (as parallel outbound replication) to the connected remote Sites. However, where the organisation has a decentralised change control infrastructure, and it is hence possible to create changes in any Site in the forest, then there will be a mixture of serialised inbound and parallel outbound replication traffic between the Sites.

The volume of replication traffic generated on a daily basis will have a direct influence on the number of preferred bridgehead servers required. Accordingly, variables such as the number of domains, domain controllers, users, member computers, directory-enabled applications that store information in the Active Directory, and so on (see process to design the Site Link topology for more details on volume, frequency, and direction of inter-Site replication traffic) are all indirectly influential.

The maximum number of outbound replication partners for each bridgehead server

The maximum number of inbound replication partners for each bridgehead server

This design methodology recognises the following variables that may indirectly influence the number of preferred bridgehead servers required for an Active Directory Site:



The following factors will directly influence the maximum number of inbound replication partners for a bridgehead server, and hence indirectly influence the number of bridgehead servers required:

The length of the window for completion of all replication is a variable defined within the properties of the Site Link objects that will connect the Sites together. A short window for replication may result in incomplete replication between domain controllers in separate Sites.

The time required by a bridgehead server to replicate (pull and write) all changes to the Active Directory is influential in the determination of the maximum number of inbound replication partners for a bridgehead server. This variable is influenced by the following factors:

The hardware (network I/O; CPU; Memory; Disk I/O) specifications and capabilities of the source and destination bridgehead servers

The volume and size of data to be read and written within each replication cycle

Whether inter-Site replication traffic compression is enabled (default) or disabled. If compression is disabled, then this will reduce the CPU load on the bridgehead server and hence increase performance. However, it will also result in an increase in the bandwidth utilisation of the WAN link between the Sites, as a larger volume of data will require transportation.

The amount of available bandwidth within the network connection that will connect the remote Sites together during the replication cycle

The time required to establish dial-on-demand network connections to remote Sites each time a replication cycle commences.

The following factors will directly influence the maximum number of outbound replication partners for a bridgehead server, and hence indirectly influence the number of bridgehead servers required:

The total number of hours (per 24 hour period) that are allocated to the bridgehead server for outbound replication

The maximum number of simultaneous connections that the bridgehead server can handle during a replication cycle, which is influenced by the following factors:

The hardware (network I/O; CPU; Memory; Disk I/O) specifications and capabilities of the bridgehead server

The amount of available bandwidth within the network connection that will connect the remote Sites together during the replication cycle

The number of replication cycles permitted within each 24-hour period. The business and technical requirements and objectives, which reflect the importance of inter-Site replication latency within the organisation, will define the value for this variable.

The time required by a bridgehead server to replicate (read and push) all changes to the Active Directory. The factors outlined earlier will influence this variable.

The following diagram provides and overview of the interrelationships between these factors, the direct and indirect influence on the number of preferred bridgehead servers for a Site, and the formulas to calculate the maximum number of inbound and outbound replication partners for bridgehead servers:



The number of naming contexts that will be

required to be replicated between

Sites

A centralised or decentralised change

control infrastructure for the Active Directory

The length of the replication window

The time required by a bridgehead server to

replicate (pull and write) all changes to the Active Directory

The total number of hours (per 24 hour

period) that are allocated to the

bridgehead server for outbound replication

Number of bridgehead servers required

Maximum number of inbound replication

partners per replication cycle

Maximum number of outbound replication

partners per replication cycle

The time required by a bridgehead server to replicate (read and

push) all changes to the Active Directory

The maximum number of simultaneous

connections that the bridgehead server can

handle during a replication cycle

Number of replication cycles required per 24

hour period

Smallest value

The requirement to manually designate bridgehead servers:o For Sites separated

by firewall implementations

o To facilitate troubleshooting of inter-Site replication

o To implement load balancing of inter-Site replication across specific domain controllers within each Site

TH x MaxCNo.RC x Time

RWTime

o The amount of available bandwidth within the network connection that will connect the remote Sites together during the replication cycle

o The amount of available bandwidth within the network connection that will connect the remote Sites together during the replication cycle

o The hardware specifications of source and destination bridgehead servers

o The time required to establish dial-on-demand network connections to remote Sites for each replication cycle

o The compression of inter-Site replication traffic (enabled (by default) or disabled)

o The volume and size of data that requires replication during each replication cycle

o The volume of replication traffic generated on a daily basis

RW

TH No. RC MAXC

TIME

TIME

LEGEND:

RW Formula Input

Influence

Result


Figure 22.2: Factors and Formulas to Determine Number of Bridgehead Servers Required

Using the above information and formulas, execute the following:

Select an appropriate Site where bridgehead requires require manual designation, and determine the values for the variables of all applicable factors

Input into the above formulas and considerations and determine the number of bridgehead servers required for transport protocol and naming context within that Site

Repeat the above steps for each other Site within the Site infrastructure that requires preferred bridgehead servers.

Document all preferred bridgehead server requirements, and generate a diagram to illustrate their distribution within the Sites and the transport protocols and naming contexts supported by each preferred bridgehead server.



6. Design for Mapping of TCP/IP Subnets to Sites


6.1. Process Objective

The objective of this process is to assist an organisation in the mapping of TCP/IP subnets, within the network infrastructure that supports the corresponding forest, to the required Sites within this Site infrastructure.


The process of mapping of TCP/IP subnets to Sites provides definition to the boundary and scope of the Sites. All Site-aware clients and services will use this information to determine their host Site, based upon the TCP/IP address and subnet assigned to a computer.

When executing this process, this design methodology requires organisations to observe the rule that it is not possible to map a single subnet to more than one Site, but a single Site can support multiple subnets.


This design methodology proposes the following approach to execute this process:

1. Identify the boundary of the network infrastructure for this Site infrastructure

2. Understand the details of the current TCP/IP architecture within this network infrastructure

3. Identify any requirements to modify or redesign any aspects of the current TCP/IP architecture within this network infrastructure

4. Map the current / proposed TCP/IP subnets to the required Sites within this Site infrastructure


Based upon the above approach, the process to design the mapping of TCP/IP subnets to Active Directory Sites within this Site infrastructure is composed of the following two components:

Determination of the details of the current / proposed TCP/IP environment

Mapping of TCP/IP subnets to each required Site



Site Plan – Inter-Component Dependencies for Process to Map TCP/IP Subnets to Sites

START Design for mapping of TCP/IP subnets to Sites

Determination of the details of the current /

proposed TCP/IP environment



The deliverables for this process are:



The identification of the details of all current and proposed TCP/IP environments and architectures within the supporting network infrastructure

The design for the mapping of the TCP/IP subnets to the Active Directory Sites within the forest

The definition of the network boundaries for the forest within the organisation

6.7. Process to Design the Mapping of TCP/IP Subnets to Sites

Site Plan – Process to Design Mapping of TCP/IP Subnets to Sites

START ENDExecute

D1

Execute

A1

Execute

A2© 2 0 0 4 M U S T A N S H I R B H A R M A L


Consider the following when generating the design for the mapping of TCP/IP subnets to Active Directory Sites within this Site infrastructure:

Factor A1: Understanding the boundary of the network infrastructure supporting this Site infrastructure, and hence the corresponding forest

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the network boundary for the Site infrastructure, prior to execution of an analysis of the network and TCP/IP infrastructure


Prior to execution of an analysis into the current and proposed TCP/IP infrastructure, and the subsequent mapping of TCP/IP subnets to Sites, it is important to understand the boundary for the network.

Within most organisations, it may be possible to identify many network aspects and components of the network infrastructure that reside within and outside of the boundary for the forest.

The following are simple examples of network infrastructure components that may reside outside of the scope of a Site infrastructure:

A LAN segment that logically represents a perimeter network (or DMZ) will support computers not represented or supported by a forest. These LAN segments, and corresponding subnet(s), are hence outside of the scope of the forest and this Site infrastructure.

A LAN segment, represented as a VLAN within a switch, exclusively supports non-Site aware network resources, such as print devices. Although an Active Directory forest may provide access control to these network aware resources, because these resources are not Site aware, there is no requirement to represent their corresponding subnet(s) within the Site infrastructure.

A collection of subnets within a network infrastructure exclusively supports a test environment or a parallel forest. As the computers and resources on these subnets are outside of the scope of this Site infrastructure and forest, there is no requirement for their representation within the Site infrastructure.

This design methodology advises consultation of the results of the Organisation-Wide Active Directory Plan process, “determination of the



boundaries and contents of each forest”, for details of the logical and physical boundaries for the forest this Site infrastructure will support.


Analyse the results of the Organisation-Wide Active Directory Plan process, “determination of the boundaries and contents of each forest”, and understand the logical and physical boundaries for the supporting network infrastructure for the forest.

Generate a diagram mapping the boundaries of the network infrastructure, to identify in and out of scope LAN segments, network links, and network infrastructure components such as switches, routers, and so on.

Factor A2: Analysis into current and proposed TCP/IP infrastructure

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to execute a detailed analysis into their current and proposed TCP/IP infrastructure, prior to designing the mapping of TCP/IP subnets to Sites.


Most organisations will have a mature TCP/IP infrastructure in place, and this may represent the only network protocol in operation. However, where organisations have merged or acquired other organisations, it may be possible to identify multiple TCP/IP architectures in operation.

The objective of this step is hence to assist an organisation in the determination of the information required about their current TCP/IP architecture(s), to support the design for the mapping of TCP/IP subnets to sites.

This design methodology proposes execution of the following approach:

Determine and document the following details of all Internet-facing and private IP address ranges and subnet masks currently in operation within the in-scope network infrastructure:

The address classes in use and the use of supernetting (Classless Inter-Domain Routing (CIDR)) solutions

The presence of variable length subnet masks (VLSM)

The presence and use of IP multicast scopes

The use of VLAN and NAT solutions

The presence and distribution of Site-aware computers, resources, and services on the in-scope network infrastructure

Determine the details for any proposals for a TCP/IP architecture redesign to, for example, consolidate and simply multiple TCP/IP architectures to a single new IP version 4 or even an IP version 6 architecture.

Identify any requirements to redesign the current TCP/IP architecture to support the Site infrastructure where, for example, it is possible to identify:

Fewer existing subnets than required Sites

Subnets that span the logical boundaries for two or more required Sites



Identify any requirements to distribute Site-aware computers, resources, and services among multiple subnets, to avoid authentication and authorisation bottlenecks. For example, an organisation may wish to partition one or more adjoining LAN segment, each with multiple subnets, into Sites to avoid network latency associated with all authentication and authorisation network traffic passing through one or two switches or routers, and hence place “local” domain controllers in each Site. The subnets for these LAN segments must hence map to the corresponding Sites.

Identify any specific requirements to support other applications and services that use the Site infrastructure for routine operation, such as SMS 2003, and so on.


Determine and document all relevant details of any current and proposed TCP/IP architectures within the in-scope network infrastructure for the forest.

Identify all requirements for the redesign of the current TCP/IP architecture to support the proposed Site infrastructure and the requirements for this infrastructure.

Factor D1: Design for mapping of TCP/IP subnets to Sites


Has determined the logical and physical boundary for the network infrastructure that will support the forest, and hence this Site infrastructure

Has executed the detailed analysis of any current and proposed TCP/IP architectures within the in-scope network infrastructure, and

Wishes to design the mapping of TCP/IP subnets to Sites


The final step in this process is to design the mapping of TCP/IP subnets to the appropriate Sites.

This design methodology proposes that the design for the mapping of subnets to Sites adopt the following format and content:

A design document detailing the requirements for the mapping of specific TCP/IP subnets to Site objects within this Site infrastructure.

A detailed diagram illustrating the following:

The logical distribution of the TCP/IP subnets within the in-scope network infrastructure, which require mapping to Sites

The logical boundaries of each required Site, mapped to the in-scope network infrastructure and the corresponding TCP/IP subnets

The logical distribution of the Site-aware computers, services, and resources on the TCP/IP subnets and the local domain controllers within each Site

When generating the design for the mapping of TCP/IP subnets to Sites, it is important to verify that the design supports access to Active Directory



published services adopts the required network paths, and avoids bottlenecks, where possible.



7. Determination of Requirements for Multiple Site Link Objects



The objective of this process is to determine the requirements for the design and implementation of a multiple Site Link topology for this Site infrastructure.


Prior to investigation of the factors that will require consideration for this process, it is important to acknowledge and understand the following facts about Site Link objects:

It is possible to consider a Site Link as a virtual circuit (VC) that can link together two or more Active Directory Sites for replication.

The Knowledge Consistency Checker (KCC) (a process that runs on all domain controllers within an Active Directory forest) is responsible for the automatic generation of a replication topology for an Active Directory forest. It accomplishes this via the creation of “Connection Objects” that represent a replication connection from one domain controller to another within the forest.

A connection object created by the KCC process has the following properties:

The connection object exists as a child of the NTDS Settings object, which in turn is a child of a domain controller within a Site object

The connection object identifies the:

Source domain controller

The Site in which the source domain controller resides

The transport protocol that is to be used for the replication

The schedule for replication

The naming contexts (NCs) that supported for full or partial replication via the connection object.

The KCC process is unaware of the physical topology of an organisation’s network infrastructure and hence is unable to determine the most appropriate routes required for replication of the Active Directory across a WAN infrastructure. Hence, KCC relies upon the definition of Sites and Site Links for the creation of an inter-Site replication topology.

Upon initial creation of the Active Directory forest, the first Site (called “Default-First-Site-Name”) is automatically associated within the default Site Link (called “DEFAULTIPSITELINK”).

The DEFAULTIPSITELINK has the following properties:

It uses RPC over IP as the transport protocol

It has a schedule of 24 X 7 (always allow replication)

It has a replication interval of 180 minutes

It has a cost of 100



It can be renamed and the values for the schedule, replication interval and cost can be adjusted as required

Upon initial creation of the Active Directory forest, there is only one Site (the “Default-First-Site-Name”) associated with the “DEFAULTIPSITELINK”. The minimum number of Sites required for a Site Link is two Sites. Hence, it is only possible to attain compliance with this minimum number of Sites, after initial creation of the Active Directory Site infrastructure, following the creation of another Site, and association of this additional Site with the “DEFAULTIPSITELINK”. Once two or more Sites are associated with the “DEFAULTIPSITELINK”, it can no longer exist with less than two associated Sites. If no other Site Links are created prior to (or after) the creation of a Site, then all Sites require association with the “DEFAULTIPSITELINK” during creation.

A Site Link can support two or more Sites. When a Site Link contains more than two Sites, then:

All of the Sites within the Site Link are considered to be connected in a n*n fully connected star topology

The cost value for the Site Link governs all inter-Site replication that will occur between those Sites contained within that Site Link, and all replication follows the replication schedule and interval set by the Site Link.

KCC will not create, delete, or recreate Site Link objects. The KCC will only create “connection objects”. A connection object represents incoming replication only. Hence, for two-way replication between two domain controllers, the KCC will create two one-way connection objects.

The KCC algorithm to create the connection objects will use the presence and configuration of the Sites and Site Link objects as inputs into the calculations it will perform to create the intra-Site and inter-Site replication topology for the forest. The connection objects are the results of these calculations. Hence, connection objects that will link two domain controllers together between two Sites and across a Site Link will use the configuration information of the Site Link to determine the required protocol and the replication interval and schedule.

The cost values of the Site Links are inputs into the calculation performed by KCC to determine the creation of the connection objects using the least-cost spanning tree algorithm.


When executing the process to determine the requirements for the design and implementation of a multiple Site Link topology for the forest, this design methodology strongly recommends the design of a simple Site Link topology. This approach hence implies the design and implementation of a single or minimal number of Site Link objects.

To support this recommendation, this design methodology states the following null hypothesis:

“The automatically created “DEFAULTIPSITELINK” for each Active Directory forest can meet all the inter-Site replication requirements for the forest, and hence each Site to be created within the forest should be associated only with this Site Link”

Following statement of this null hypothesis, it is necessary to execute an investigation to disprove this null hypothesis and, if successfully disproved, determine the actual number of Site Links required and their arrangement (with respect to the Sites) to produce the Site Link topology.



To support the above recommendation and null hypothesis, this design methodology proposes the following approach for execution of this process:

1. Understand the factors that will influence the opportunity to disprove the null hypothesis for this process, and hence support the design and implementation of two or more Site Link objects

2. Understand the factors that support the null hypothesis

3. Determine the requirements for the design and implementation of multiple Site Link objects

4. Where there is a requirement for the design of multiple Site Link objects, (and hence it was possible to disprove the null hypothesis for this process) execute the process “design of a Site Link topology”.

5. Where there is no requirements for the design of a multiple Site Link topology, (and hence the null hypothesis is sustained), then execute the process “design for the configuration of the Site Link objects”.


The process to determine the requirements for a multiple Site Link topology for the forest is composed of the following components:

Understanding the factors that influence the requirements for multiple Site Link objects

Understanding the factors that support the null hypothesis for this process

Determination of the requirement for multiple Site Link objects



Site Plan – Inter-Component Dependencies for Process to Determine Requirements for Multiple Site Link Objects

START

Determination of the requirements for multiple Site Link

objects

Understanding factors that support multiple

Site Link objects

Understanding factors that support the null

hypothesis© 2 0 0 4 M U S T A N S H I R B H A R M A L


The process to design a Site Link topology for a forest will have the following deliverables:

Identification of the factors, applicable to the organisation, which influence the requirements for the design and implementation of multiple Site Link objects

Identification of the factors, applicable to an organisation, that support the null hypothesis for this process

The determination of the requirements for multiple Site Link objects within this Site infrastructure



7.7. Process to Determine Requirements for Multiple Site Link Objects

Site Plan – Process to Determine Requirements for Multiple Site Link Objects

START ENDExecute

A1

Execute

B1 – B7

Is there a requirement for multiple Site Link

objects? NO

YES


topology”


configuration of Site Link objects”



Consider the following when determining the requirements and opportunity to disprove the null hypothesis for this process, and hence the design and implementation of multiple Site Link objects:

Factor B1: Understanding the approach towards determination of the requirements for multiple Site Link objects


Has identified the requirements for the design and implementation of a multiple Site infrastructure for a forest, and

Wishes to understand the approach towards determination of the requirements for the design and implementation of multiple Site Link objects


As discussed in the background information section of this process, a single Site Link object can support multiple Sites. In this scenario, the following parameters of a Site Link object will control all inter-Site replication between Sites supported by that Site Link object:

The replication schedule

The replication interval

The cost metric of the Site Link object, in relation to other Site Link objects within the Site infrastructure

This design methodology proposes that a single Site Link object, such as the automatically generated “DEFAULTIPSITELINK” object, is capable of supporting all inter-Site replication requirements for a Site infrastructure, without the requirement to design and implement multiple Site Link objects.

The objective of this process is to determine the opportunities and requirements to disprove the null hypothesis for this process, and thus the requirement to design and implement multiple Site Link objects.

Hence, the approach to execute this process is to identify the requirements for differing replication schedules, intervals, and costs for Site Link objects.

This design methodology proposes that the following factors are influential in determination of the requirements for the design and implementation of multiple Site Link objects:



The requirements to control the replication paths for naming contexts within the Site infrastructure and supporting network infrastructure

The requirements to control the efficient use of low available bandwidth network links required to support inter-Site replication

The requirements to control the use of WAN links via scheduling

The requirements to support the use of the asynchronous SMTP over IP inter-Site transport protocol

This design methodology proposes that the following factors are not influential in the determination of the requirements for the design and implementation of multiple Site Link objects

The requirements for the creation of Site Links for redundancy

The requirements for the creation of Site Links to mimic physical inter-location network links

Factor B2: Understanding the requirements to exert greater control over the path(s) for replication of the naming contexts within the Active Directory forest, on the requirements for multiple Site Link objects


Has a supporting network infrastructure that does not connect all the TCP/IP subnets for the Sites within an n*n fully connected star topology, and

Wishes to understand the influence of the requirements to control replication paths on the design and implementation of multiple Site Link objects within this Site infrastructure


Within an organisation with this type of network infrastructure, there may be a requirement to exert an influence over the paths for replication of the Active Directory naming contexts between the domain controllers. The requirements to control the replication paths must reflect the design of the Active Directory forest and domain structure and the supporting physical network infrastructure.

Within this scenario, it may be necessary for an organisation to design and implement multiple Site Links to meet the requirements to control Active Directory replication, as the “DEFAULTIPSITELINK” (as the only Site Link) will not meet this requirement.

It is important to note that the following factors will influence the design for the paths for inter-Site replication of the Active Directory naming contexts:

The design for the placement of domain controllers within Sites and the linking of the Sites together using Site Links will influence the design for the replication paths. For example, an organisation may wish to create a “hub-and-spoke” Site Link topology. The spokes for the topology represent the various branch offices, which will replicate with one or a few “hub” Sites that represent the headquarter location(s) for the organisation.

The “cost” values for a Site Link object will influence the design for the replication paths. Cost values are relative to those set on other Site Links within the forest Site topology. The cost values for Site Links will influence the KCC algorithm to factor these values into the calculations to create and



configure the connection objects that will link domain controllers within different Sites together. It is possible to use the design for the variations and assignments of cost values to emulate a WAN topology to favour, for example, the use of a high-speed WAN backbone for the majority of replication traffic.

The configuration of the Site Link replication schedules and intervals will influence the design for the replication paths. A replication path from one domain controller to another that has to cross multiple Site Links will depend upon the presence of a common window for replication across all relevant Site Links. Without this common window across multiple Site Links, replication cannot proceed. Hence, the careful configuration of the replication schedules and intervals can influence the paths for inter-Site replication.

Factor B3: Understanding the requirement to enforce the efficient use of a low-bandwidth WAN links between two or more physical locations, on the requirements for multiple Site Link objects.


Has one or more low-bandwidth network links that will support inter-Site Active Directory replication traffic and have low levels of available bandwidth during normal business hours, and

Wishes to understand the influence of the requirements to control the use of these WAN links on the design and implementation of multiple Site Link objects within this Site infrastructure


The use of a single Site Link object to control all inter-Site replication traffic will not support any requirements to control the use of specific network links, as there is a specific level of abstraction between Site Link objects and physical network links.

Identification of the above scenario within an organisation may support the requirements for the design and implementation of multiple Site Link objects. It is then possible to configure the Site Links with longer replication interval values and “cost” metrics to ensure efficient use of network links. Note however that this may introduce latency in the replication of the naming contexts between the Sites.

Factor B4: Understanding the requirement to control the use (via scheduling) of certain WAN links by Active Directory for replication, on the requirements for multiple Site Link objects.


Has one or more highly utilised inter-Site network links, for which Active Directory replication traffic should be carried at a lower priority to other business critical information, and

Wishes to understand the influence of the requirements to control network link usage, via scheduling, on the design and implementation of multiple Site Link objects within this Site infrastructure




Within a supporting network infrastructure, where one or more network links are heavily utilised during business hours, it may be necessary to ensure their use to transport Active Directory replication traffic only at specific times. The contribution of Active Directory replication traffic to these over utilised network links may introduce latency for other applications and service reliant upon the network link.

The use of multiple Site Links can support the design of custom replication schedules that reflect the low and high bandwidth availability patterns of inter-location network links.

Factor B5: Understanding the requirement to use the asynchronous SMTP over IP transport protocol for inter-Site Active Directory replication, on the requirements for multiple Site Link objects.


Has identified compliance with one or more of the following scenarios:

The presence of one or more inter-Site network link(s), which are unreliable and have very low bandwidth availability, making them unsuitable for the use of RPC over IP as the transport protocol, and / or

The presence of a firewall in place that will block network traffic through ports 137 and 139, hence disallowing RPC traffic, and

Wishes to understand the influence of the requirements for the use of the SMTP over IP transport protocol and the on the design and implementation of multiple Site Link objects within this Site infrastructure


Where it is possible for an organisation to identify restrictions on the use of RPC over IP as the inter-Site transport protocol, then the organisation may have to use the SMTP over IP protocol.

The “DEFAULTIPSITELINK” is an RPC over IP Site Link object, and hence cannot support the use of the SMTP over IP transport protocol.

It is important to understand the pre-requisites to the design and implementation of the SMTP over IP transport protocol, as a Site Link object:

It is necessary for the design and implementation of an Enterprise Certificate Authority, to issue domain controllers (that will replicate across the SMTP over IP Inter-Site Link) with X.509 certificates to encrypt transmitted data.

It is necessary for the Site Link to support only inter-domain replication and not intra-domain replication. Hence, there may be the requirement to create a separate domain for that Active Directory Site, unless it is possible to upgrade the network link to support the RPC over IP protocol, or configure the firewall to allow RPC traffic to pass through.

Factor B6: Understanding why the requirements to create Site Links for redundancy support the null hypothesis for this process.

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand why Site Links do not support requirements for redundancy.




It is not necessary to design and implement multiple Site Link objects to support redundancy. This is because all Site Link objects are transitive by nature, and the inter-Site replication topology created by KCC is a least-cost spanning tree model.

Hence, it is not necessary to create additional Site Links for fault tolerance, because as long as the KCC process is able to construct a replication path to connect all of the Sites within an Active Directory forest, then the replication topology is valid and functional.

Factor B7: Understanding why the requirements to create Site Links to mimic physical network links support the null hypothesis for this process.

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand why the presence of multiple network links, which will support inter-Site replication, do not, by default, require representation by discrete Site Link objects.


The Site Link topology is a logical infrastructure to support the routing of Active Directory replication traffic across the Sites. The design for the Site Link topology is not necessary required to reflect the network infrastructure, unless there are specific requirements, as discussed earlier.

The Site Link topology assumes the connection of the Sites within a Site Link, via physical network links, and that it is possible to route traffic between domain controllers within each Site.

For example, in the following illustration, Sites A, B, and C are within “SiteLink1” and two network links, “NetworkLink1” and “NetworkLink2”, connect the Sites together:

Site A Site B

Site C“SITELINK1”

“NETWORKLINK2”

“NETWORKLINK1”


Figure 24.1: Example of Site Link Object Supporting Multiple Sites

In this example, the Site Link object, “SITELINK1”, assumes that domain controllers within Site A can communicate with domain controllers within Sites B and C, and vice versa.

Hence, there is no requirement to create a specific Site Link object to support inter-Site replication between Sites A and B, and between Sites B and C simply to reflect the presence of the supporting network links, unless there are specific requirements, as outlined earlier.



Factor A1: Determination of the requirements for the design and implementation of multiple Site Link objects.


Has considered all of the factors that will influence the requirements and opportunities to disprove and support the null hypothesis for this process, and

Wishes to determine the requirements for the design and implementation of multiple Site Link objects


Following evaluation of all factors outlined above, it is necessary to determine the requirements for the design and implementation of multiple Site Link objects within the Site infrastructure.

This design methodology proposes execution of the following approach to determine the requirements to disprove the null hypothesis for this process:

Evaluate all factors that will support the opportunity to either disprove the null hypothesis for this process or support the null hypothesis, and identify all applicable factors within the organisation.

If it is possible to identify one or more requirements to support the design and implementation of multiple Site Link objects, then execute the process “design of a Site Link topology”.

If it is not possible to identify any applicable factors that support the null hypothesis, then the design for the Site Link topology for this forest is restricted to a single Site Link object, supporting all required Sites.


Identify all applicable factors that will support and / or disprove the null hypothesis

Determine the requirements for the design and implementation of multiple Site Link objects



8. Design of a Site Link Topology

This process requires execution by all organisations where the process, “determination of the requirements for multiple Site Link objects” has identified the requirements for the design of two or more Site Link objects for this Site infrastructure.


It is possible to connect multiple Sites and Site Link objects using many different configurations. The objective of this process is to assist an organisation in the design of a Site Link topology, which will hence establish which Sites require connection together via the Site Link objects, and in which configurations.

It is important to understand that the process to design a Site Link topology for a Site infrastructure is an iterative process, which allows the cumulative consideration of all factors that can influence and shape the final design of the Site Link topology.


Although the design of a Site Link topology for a forest can take many forms, the final design should reflect the business and technical objectives and requirements of the organisation.

The following diagrams illustrate two simple examples of the types of Site Link topology models supported by this design methodology, using a Site infrastructure with twelve Sites (Sites A to L):

An examples of a strict hub-and-spoke design for a Site Link topology:

Site A

Site B

Site E

Site F

Site I

Site J

Site CSite D

Site G

Site H

Site K

Site L

LEGEND:Site Link Object

Site B Site Object




Figure 25.1: Example of a Strict Hub-and-Spoke Site Link Topology

In the above example, each of the Sites B to L connects to a central hub Site (A) via individual Site Link objects.

This Site Link topology hence requires the design and implementation of eleven Site Link objects.

This Site Link topology hence requires all inter-Site replication to go through the hub Site A.

An example of an extended or hybrid hub-and-spoke design for a Site Link topology:

Site A

Site B

Site E Site F

Site ISite J

Site CSite D

Site G

Site HSite K

Site L

LEGEND:

Site B Site Object

Site LinkObjects


Figure 25.2: Example of an Extended / Hybrid Hub-and-Spoke Site Link Topology

In the above example, six Site Link objects support this Site Link topology

In the above example, Sites B, E, and F are contained within one Site Link object and hence inter-Site replication between these Sites does not interfere with inter-Site replication between the other Sites. However, inter-Site replication between, for example, Sites B and I, must pass through the hub site, Site A.


When executing this process to design a Site Link topology for this Site infrastructure, this design methodology strongly recommends the design of a simple Site Link topology. This implies the design of a minimal number of Site Link objects.

Note that this process relies and builds upon the results of the previous process to determine the requirement for multiple Site Link objects. Hence, where relevant, the information gathered during the execution of that process requires consideration to influence the design of the Site Link topology for the forest.



This design methodology hence proposes the following iterative approach for execution of this process:

1. Understand the factors that will influence the design for a Site Link topology

2. Identify all applicable factors within the organisation and Site infrastructure, and assign a priority value for each identified requirement, from 1 to 10, where 1 is the highest priority and 10 the lowest priority.

3. Starting with the highest priority factors, generate the first draft design for the Site Link topology

4. Evaluate all other priority requirements and re-draft the design for the Site Link topology where required

5. Generate the final design for the Site Link topology


The process to design a Site Link topology for this Site infrastructure is composed of the following components:

Understanding the factors that will influence the design of the Site Link topology

Generation of the design for the Site Link topology

8.5. Inter-Components Dependencies


Site Plan – Inter-Component Dependencies for Process to Design Site Link Topology

START Generation of design for Site Link topology

Understanding factors that influence design of

Site Link topology© 2 0 0 4 M U S T A N S H I R B H A R M A L


The process to design a Site Link topology for a forest will have the following deliverables:

An understanding of the factors influential in the design of a Site Link topology

Identification of the factors applicable to the organisation

Determination of the number of Site Link objects required

Determination of the transport protocol for each required Site Link object

Determination of the Sites each Site Link object will support

Generation of the design for a Site Link topology for this Site infrastructure

8.7. Process to Design the Site Link Topology

Site Plan – Process to Design a Site Link Topology

START ENDExecute

A1

Execute

B1 – B6

Execute

D1© 2 0 0 4 M U S T A N S H I R B H A R M A L




Consider the following information when executing this process to generate the design for the Site Link topology for this Site infrastructure:

Factor B1: Understanding the approach towards determination of the design for the Site Link topology

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach proposed by this design methodology towards the design of the Site Link topology for this Site infrastructure.


As discussed in the process approach section, the execution of this process to design a Site Link topology requires an iterative approach.

This process will provide all of the factors that require consideration, due to their potential to influence the design of a Site Link topology. Within most organisations that identify two or more applicable factors, it may be possible to generate two or more design combinations for a Site Link topology, to support all applicable factors.

Hence, this design methodology proposes the prioritisation of all applicable factors, and generation of drafts of a design for a Site Link topology. The higher the priority assigned to an applicable factor, the greater its influence on the design for the Site Link topology. Hence, all applicable factors assigned a priority of one or two (highest priorities), will define the predominant design for the Site Link topology. All lower priority factors may then only modify minor aspects of the design for the Site Link topology.

When executing this process, it is important to remember that the objective of this process is to determine just the design for the Site Link topology. The later process, “design for the configuration of the Site Link objects”, will assist an organisation in the identification of the required configurations for all required Site Link objects.

Although the onus is with the organisation to identify all factors influential in the design of a Site Link topology for this Site infrastructure, this design methodology proposes the following examples of influential factors:

The design of the current and proposed network infrastructure for the organisation

The presence of redundant network links between physical locations represented as Sites

The financial overheads associated with upgrades in network link bandwidths

The volume, frequency, and direction of inter-Site replication traffic

The requirements to reduce Active Directory replication latency

The administrative overheads associated with Site Link objects

The remainder of this process will discuss the influence of the above example factors on the design of the Site Link topology. Where an organisation may identify other factors not listed here, the onus is with the organisation to determine their requirements for these additional factors, and the nature and extent of influence on the design for the Site Link topology.



Factor B2: Understanding the influence of the current and proposed network infrastructure for the organisation on the design of a Site Link topology


Has multiple physical locations, represented as Sites, which are connected via a variety of network links (WAN, VPN, and so on), and

Wishes to understand the influence of the design of the current and proposed network infrastructure(s) on the design or the Site Link topology


Within most local and wide-area network infrastructures for organisations, it is not possible to identify dedicated network segments or links for Active Directory replication. Most network segments and links support access and use by multiple applications, processes, and services, and hence there is contention for network bandwidth.

In these scenarios, an organisation may wish to control the route(s) Active Directory replication traffic will take within and between locations, network segments, and network links.

When understanding the influence of the design for a network infrastructure on the design for a Site Link topology, consider the following:

An organisation has, for example, a network infrastructure with a WAN topology that employs a backbone or series of backbone links, which have high levels of available bandwidth and low latency. The organisation may hence wish to ensure that the majority of network traffic uses these links. The topology of a WAN infrastructure within an organisation that uses backbone links usually reflects the requirements for the current volume and direction of general network traffic to and from the physical locations connected to the backbone. This can hence be used to assist in the prediction of the volume and direction of Active Directory replication traffic that will be generated and received by the physical locations for the organisation (see a later factor for more details)

The use of Site Links to connect the Sites together can reflect the requirements to control the paths that replication traffic for the Active Directory will take through the network infrastructure for the organisation. Routing and control of replication traffic is possible via the design of the cost values, replication schedules and intervals for the Site Links (see process to design the configuration of the Site Links).

The Site Link topology does not necessarily have to mirror any WAN topologies for the organisation. It is possible, for example, to have two Sites that are currently linked together via a WAN link, but do not share a common naming context (other that the Schema and Configuration partitions) and hence may not generate or receive inter-Site replication traffic between them.

There may be the requirement to comply with the limitations on current WAN infrastructure within the organisation. For example, if a WAN infrastructure for an organisation contains a link to a Site that is not reliable, and has very low bandwidth availability, then the WAN link may not support RPC over IP (synchronous replication transport). In this scenario, the protocol that will be required to replicate the Active Directory between domain controllers within the two sites may have to be Simple Mail Transport Protocol (SMTP) over IP (an asynchronous replication transport



protocol). However, the pre-requisites for the use of SMTP over IP within a Site Link between two Active Directory Sites are that:

An Enterprise Certificate Authority is required to issue domain controllers that will replicate across the SMTP over IP Inter-Site Link with X.509 certificates to encrypt transmitted data.

The Site Link will support inter-domain replication and not intra-domain replication

An SMTP over IP Site Link may also be required where firewall port restrictions are present. For example, where all of the following criteria are present and valid within an organisation, then the Site Link(s) that connect the Sites via a RPC over IP port restricted firewall may have to use SMPT over IP as the transport protocol:

Two or more physical locations that are potential Active Directory Sites

Two or more of these locations are connected together via a WAN link

There is a firewall in place between a domain controller on a LAN within one Site and a domain controller on a LAN within another Site

The firewall is configured to prevent the flow of RPC over IP traffic on ports 137 and 139

It is important to identify Sites that can be classed as “terminus” Sites. These Sites will have only a single external network connection to and from that Site. The network connection could be a dial-up connection, an ADSL connection, a leased-line &/or a VPN. The classification of a Site as a “terminus” Site and the nature of the external network connection can influence:

Its position within a Site Link topology

The volume and direction of Active Directory replication traffic to and from that Site

The replication schedule for the Site Link that will contain this Site

Factor B3: Understanding the influence of the presence of redundant network links, between physical locations represented as Sites, on the design of a Site Link topology


Two or more physical locations that contain more than one redundant WAN links to and from other different physical locations, and

Wishes to understand the influence of the presence of redundant WAN links on the design of the Site Link topology


Within some organisations, it may be possible to identify one or more WAN links that, although available for use, are predominantly redundant. These WAN links may remain “redundant” to support disaster recovery plans and procedures, or to provide exclusive support for one or more applications or services.



Where it is possible to identify such WAN links, then this design methodology advises the creation of a dedicated Site Link object for these network links, but assignment of a higher cost value. This hence supports emergency re-routing of Active Directory replication traffic to the destination Sites, in the even of the failure of one or more primary network links.

In the example illustrated below, a Site Link could be established between Site C and Site D (and assigned a higher cost value) to allow replication between these Sites if there is a failure in any of the ATM links between Site A and Site C; Site A and Site E; or Site D and Site E:

Site A

Site B

Site C

Site D Site E

LEGEND:

Site B Site Object

155 Mbps ATM

64 Kbps ISDN


Figure 25.3: Example Use of Redundant Network Link in Site Link Topology

Factor B4: Understanding the financial overheads of bandwidth upgrades for existing upgradeable inter-Site network links

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of the financial overheads associated with bandwidth upgrades on the design of a Site Link topology.


Within most organisations, network links that connect remote physical locations together are upgradeable, with respect to the levels of bandwidth, contention ratios, SLA, and so on.

The usefulness and participation of these network links in the Active Directory replication topology for a forest may depend upon the feasibility and viability of any such upgrades on these links.

Although all such upgrades are typically associated with a financial overhead, this design methodology recommends the inclusion of these links within the Site Link topology for this Site infrastructure.

If these network links can potentially carry inter-Site replication traffic, then it is possible to estimate the volume and frequency of traffic they will transport from the analysis and calculations in previous processes. It is then possible to determine the financial overheads associated with any requirements to upgrade the bandwidth, to support predicted transport demands.

The organisation may also assign usage priorities to these network links (with respect to other WAN links) to transport inter-Site replication traffic, and retain



usability of these network links without a financial outlay to upgrade their bandwidth.

An organisation may have multiple bandwidth-upgradeable inter-Site network links, each with differing financial cost models for upgrades. In these scenarios, it is possible to calculate the priorities for the individual WAN links, via a comparison of the financial overheads per channel / PVC / other unit to scale bandwidth availability.

Factor B5: Understanding the volume, frequency, and direction of inter-Site replication traffic on the design of the Site Link topology

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of the volume, frequency, and direction(s) of inter-Site replication traffic on the design of the Site Link topology.


The design of a Site Link topology must reflect and support the expected volume, frequency, and direction of inter-Site Active Directory replication traffic.

Domain controllers within a forest generate and receive Active Directory replication traffic. Transmission of replication traffic between domain controllers is to ensure local copies of the Active Directory database are up-to-date and reach a state of convergence, following the creation of a change to the Active Directory.

Hence, the following parameters directly and indirectly influence the volume, frequency, and direction of inter-Site Active Directory replication traffic:

The Active Directory administrative model for the organisation

The sources of input into the Active Directory that make changes (creation, modification, and deletion) to the objects within the directory service

The number of objects to be held within the Active Directory and the frequency and nature changes to these objects

The distribution of the naming contexts within the forest across the Sites and physical locations within the organisation

When attempting to understand the influence of the Active Directory administration model for the organisation on the volume, frequency of transmission, and direction of Active Directory replication traffic, consider the following:

This design methodology proposes execution of the following approach to understand the influence of the Active Directory administration model on the design of the Site Link topology:

Understand the types of Active Directory administration models and the influence of these models on the volume, frequency of generation and transmission, and direction of Active Directory replication traffic

Execute an analysis to identify the Active Directory administration model within the organisation, and map this information to the Site infrastructure for the forest

Categorise the Sites with respect to the generation, transmission, and reception of Active Directory replication traffic



Factor the results into the design of the Site Link topology

The Active Directory administrative model for the organisation has a direct influence on the volume and direction of Active Directory replication traffic. This is because the Active Directory administration model will determine where changes are made (and hence the direction of replication traffic), how many changes are made (and hence the volume of replication traffic) and how often the changes are made (and hence the frequency of transmission of replication traffic.)

Within most organisations, the Active Directory administrative model will resemble one of the following:

A strictly (logically and physically) centralised model, where all administration of the Active Directory is performed by one team of administrators within one or a few primary physical locations within the organisation

A strictly (logically and physically) decentralised model, where administration of the Active Directory is performed by multiple autonomous administration teams at two or more physical locations within the organisation, or

A hybrid of these two models

Following identification of the type of administration model in use for the Active Directory, it is possible to map this information to the Site infrastructure for the forest. It is then possible to assign the Sites to one of the following (high-level) categories:

A Site that creates all the changes within the Active Directory and receives no changes from other remote Sites (this Site will house the forest-level FSMO role servers as well)

A Site that primarily creates all the changes within the Active Directory and receives some changes from other Sites

A Site that creates and receives 50% of the changes to the Active Directory

A Site that primarily receives all its changes to the Active Directory from remote Sites but does create some changes locally

A Site that receives all its changes to the Active Directory from remote Sites and creates no changes locally

Use this information to determine the direction of network traffic between the Sites, and factor this information in the design for the Site Link topology, which must reflect and support these analysis results.

When attempting to understand the influence of the sources of originating and replicated change on the volume, frequencies of generation and transmission, and direction of Active Directory replication traffic, consider the following:

The volume and frequency of replication traffic is a direct reflection of the following:

The number of objects within the Active Directory

The frequency and nature of the changes that are made to these objects, and



The frequency of object creation and deletion

The sources of input into the Active Directory that make changes (creation, modification, and deletion) to the objects within the directory service can influence the following:

The direction, as the source of the replication traffic represents the physical location where input was made

The volume and frequency of replication traffic

This design methodology recognises the following as typical sources of input into the Active Directory:

Human inputs, via execution of routine and non-routine administrations of the Active Directory, are the most prevalent source of input and hence change. For example, administrative tasks to create, modify, and delete user and computer account objects. The administrative model for the Active Directory will influence the location for the input, and hence source for replication of the change to the appropriate domain controllers within the forest.

Automated inputs, via directory-enabled applications, are the second most prevalent sources of input and hence change. Examples of automated sources of input and change into the Active Directory include the following:

Applications that use the Active Directory to store data and configuration data may have a frequent change profile, such as DNS zone data.

Applications that manipulate the data held within the Active Directory as part of a directory integration solution, such as a metadirectory product. A metadirectory solution can have a substantial impact on the volume and frequency of changes to the Active Directory as it may reflect changes to the Active Directory that were made in countless other data repositories integrated into the solution.

Self-service password reset solutions, which permit users to (typically) access a web-based portal, answer several security questions, and then reset their password should they have forgotten it. It is important to note that every password change will trigger the push of the new password (using non-urgent replication) to the domain controller holding the PDC master FSMO role. Hence, such solutions should ideally be based in the same Site as the PDC master for a domain to minimise inter-Site replication traffic.

Network or other directory-enabled devices, may use the Active Directory to store and read changeable configuration data, and hence introduce change.

The number of objects held within the Active Directory and the frequency and nature of the changes to these objects will have a direct influence on the volume and frequency of generation and transmission of Active Directory replication traffic.

The greater the number of objects there are within the Active Directory, the greater the frequency and volume of changes that will be generated. Note that the nature of the change is important, as it will reflect the size of the associated replication traffic to propagate that change to the other domain controllers within the domain and forest. For example, the creation of an object will generate a larger volume of data, which requires replication to



other domain controllers, than the modification of a simple string attribute such as the description for a user account.

In order to predict the volume and frequency of changes and hence Active Directory replication traffic, this design methodology proposes execution of a detailed analysis to identify all types of changes predicted. The following are simple examples of the types of questions that require answers. It is important to note that this list of questions is not exhaustive and is provided only for guidance and as a starting place for expansion of this line of investigation:

Determine the number and types (object class) of objects the Active Directory forest will support, and the average expected size for each type of object.

Determine the types of changes that may require execution on these objects, including their creation and deletion.

Determine which types of changes the organisation expects to perform most frequently, regularly, and least often.

When attempting to understand the influence of the distribution of the naming contexts within the forest (across the Sites and physical locations within the organisation) on the volume, frequencies of generation and transmission, and direction of Active Directory replication traffic, consider the following:

The distribution of the naming contexts within the forest across the Sites and physical locations within the organisation will determine the direction of replication traffic across the network infrastructure.

Active Directory partitions (virtually) inter-Site replication traffic using the naming contexts for the forest. Hence, the design for the Site Link topology must reflect the requirements of specific Sites to exchange replication traffic for specific naming contexts on a regular basis. For example, two Sites that host domain controllers belonging to the same domain may need to generate replication traffic between them on a regular basis. It is important not to isolate Sites by connecting them to other Sites that do not share all the same naming contexts.

The logical partitioning of the forest into trees and domains may reflect the physical partitioning of an organisation, especially across multiple countries and continents. The design of the Site Link topology is hence required to reflect this partitioning, to allow the containment and control of inter-Site replication traffic within and between geographic locations.

It is important to note that changes to the Schema and Configuration partitions will require replication to all domain controllers within the forest, and this may hence generate significant replication waves throughout the network infrastructure for the organisation. Most organisations do not expect to generate multiple or frequent changes to these two forest-wide partitions. However, where it is possible to identify this requirements, then it may be prudent to place the Site or Sites, which will predominantly generate changes to these partitions, as close to (with respect to a fewer number of hops across Sites) as many of the recipient Sites as possible.

Inter-Site replication for Global Catalog (GC) servers can take place only between GC servers within the same forest. Hence, replication paths between GC servers will require consideration for design. Note that a connection object created manually or automatically by the KCC process will replicate all naming contexts from the source domain controller. Hence, if the destination and source domain controllers are both GC servers, then



the connection object will replicate all naming contexts held by the source GC server to the destination GC server.

Factor B6: Understanding the influence of the requirement to reduce replication latency for the Active Directory on the design of the Site Link topology


Has one or more potential Sites that:

Will hold latency-sensitive copies of the Active Directory, used by users, directory-enabled applications and processes, and

These Sites will primarily receive the latency-sensitive data held within the Active Directory from other remote Sites, and

Wishes to understand the influence of requirements to reduce replication latency on the design for the Site Link topology


Within Sites where Active Directory replication latencies may generate unacceptable consequences, then the design for the Site Link topology must address and support such requirements to reduce or prevent latencies. For example, data held within the Active Directory is on the critical path for a time-sensitive process within an organisation, and any delays in the reception of updates to this data could disrupt this process, and possibly (directly or indirectly) business continuity.

In such scenarios, the direct connection of these Sites to the source Sites for the latency-sensitive data could assist in ensuring the direct reception of these critical replication updates and not via multiple intermediate Sites.

Factor A1: Determination of the design requirements for the Site Link topology


Has evaluated the factors presented by this design methodology as been influential in the design of a Site Link topology, and

Wishes to determine the design requirements for the Site Link topology for this Site infrastructure


The penultimate step in this process is to determine the design requirements for the Site Link topology for this Site infrastructure.

This design methodology proposes execution of the following approach to determine the design requirements for the Site Link topology:

Identify and analyse all factors influential in the design of a Site Link topology. Note that the factors listed by this design methodology may not be exclusive for most organisations. The onus is hence with the organisation to identify independently all applicable factors that will influence the design for the Site Link topology for this Site infrastructure.



Execute an analysis of all identified influential factors to isolate those factors applicable to the organisation.

Assign each applicable factor a priority value, from one to ten, where one is the highest priority value, and ten the lowest priority value. When assigning a priority value to each applicable factor, define the priorities for each factor against the other factors, and the consequences of lack of compliance with a factor on the normal operation of the Active Directory infrastructure.

Using the above information and approach, determine all the necessary requirements for the generation of a design for the Site Link topology for this Site infrastructure.

Factor D1: Generation of the design for the Site Link topology


Has evaluated the factors presented by this design methodology as been influential in the design of a Site Link topology,

Has completed all analyses to determine the design requirements for the Site Link topology, and

Wishes to generate the design for the Site Link topology for this Site infrastructure


This design methodology proposes execution of the following approach to generate the design for the Site Link topology for this Site infrastructure:

Address the highest priority valued factor(s), and generate a first draft design for the Site Link topology to support the identified requirements for this factor(s).

Address each subsequent priority value factor(s), and modify (where possible and / or appropriate) the draft design of the Site Link topology to accommodate and support these requirements.

Generate the final draft design for the Site Link topology and retest the capability of this design to support all applicable factors, where required, possible, and feasible.

Finalise the design for the Site Link topology.

This design methodology proposes that the design for the Site Link topology adopt the following format and content:

A design document detailing all of the requirements and considerations employed in the design for the Site Link topology, highlighting the following:

The applicable and non-applicable factors, stating why the factors were deemed applicable and non-applicable

The priorities assigned to the applicable factors, stating the justifications for any differentiations in priority assignment

Each drafts of the design for the Site Link topologies, demonstrating the influence of each applicable factor in the development of the design for the Site Link topology



The final (in diagrammatic format) design for the Site Link topology, which depicts the following:

The logical design for the Site Link topology, identifying the Sites within each Site Link, and the Sites connected by Site Links

The physical design for the Site Link topology, identify the relationships between the Site Links and the supporting network infrastructure(s) and components of the network infrastructure.



9. Design for the Configuration of the Site Link Objects

This process requires execution where an organisation has identified the requirements for one or more Site Link objects.

Note that some components of this process only require execution where an organisation has identified the requirements for two or more Site Link objects for this Site infrastructure. The criteria for application of the factors within this process will define these requirements.


The results of the previous process, “design of a Site Link topology”, provide an organisation with an indication of the Sites that require connection, and the desired replication paths for inter-Site Active Directory replication.

The objectives of this process are hence to assist an organisation in execution of the following:

Use the results of the design for the Site Link topology to understand the Site Links that require configuration

Determine the design requirements for the configuration of the required Site Link objects

Generate a design for the configuration of the required Site Link objects. The design is required to support all business and technical requirements for the inter-Site routing of Active Directory replication traffic.

9.2. Process Scope

The number of required Sites and Site Link objects, and the design of the supporting network infrastructure for the forest will define the scope of this process.


For each required Site Link object, it is possible to configure a number of variables. This design methodology supports the design for the configuration of the following variables for Windows Server 2003 Active Directory Site Link objects:

The name of a Site Link object

The description of a Site Link object

Design of a cost model for Site Link objects, and the assignment of a cost value to a Site Link object

Design for the replication schedule and intervals for Site Link objects

Design for reciprocal replication for a Site Link object

Design for inter-Site change notification for a Site Link object

Note that the design for the names of Site Link objects is outside of the scope of this process, and is instead a component of the Organisation-Wide Active Directory Plan process, “design for object naming models”.

The steps within this process, to address and design each of the above variables, will present a high-level overview of the variables, where necessary.




This design methodology proposes execution of the following approach to generate a design for the configuration of the Site Link objects for this Site infrastructure:

1. Determine the design requirements for the description of Site Link objects

2. Generate a design for a cost value model to support routing of Active Directory replication traffic within the Site infrastructure

3. Determine the design requirements for the replication schedules and intervals for each required Site Link object

4. Determine the design requirements for the configuration of reciprocal replication for specific Site Link objects

5. Determine the design requirements for the configuration of inter-Site change notification for specific Site Link objects

6. Generate a design for the configuration of each required Site Link object


The process to design the configuration of the Site Link objects is composed of the following six components:

Determination of the design requirements for the descriptions of Site Link objects

Generation of the design for a Site Link object cost value model

Determination of the design requirements for the replication schedules and intervals of Site Link objects

Determination of the design requirements for reciprocal replication for specific Site Link objects

Determination of the design requirements for inter-Site change notification for specific Site Link objects

Generation of a design for the configuration of required Site Link objects





Site Plan – Inter-Component Dependencies for Process to Design the Configuration of Site Link Objects

START

Generation of the design for the

configuration of Site Link objects

Determination of the design requirements for Site Link descriptions

Generation of a design for a Site Link cost

value model

Determination of the design requirements for

the replication schedules and intervals

for Site Link objects

Determination of the design requirements for reciprocal replication for

Site Link objects


inter-Site change notification for Site Link

objects© 2 0 0 4 M U S T A N S H I R B H A R M A L


The process to design the configuration of the Site Link objects will have the following deliverables:

The generation of a design for the description of each required Site Link object

The design of a cost value model and cost values for Site Link objects

The generation of a design for the replication schedules and intervals for Site Link objects

The generation of a design for reciprocal replication for a Site Link object, where required

The generation of a design for inter-Site change notification for a Site Link object, where required



9.8. Process to Design the Configuration of the Site Link Objects

Site Plan – Process to Design the Configuration of Site Link Objects

STARTExecute

A1

Execute

B1

ENDExecute

D1

Execute

B2 – B8

Execute

A2

Execute

A3

Execute

B19

Execute

A4


reciprocal replication?

Execute

A5YES

NOExecute

B20

Execute

A6© 2 0 0 4 M U S T A N S H I R B H A R M A L

Execute

B9 – B18


Consider the following when generating the design for the configuration of Site Link objects.

Presented within the following six sections are the considerations for this process:

1. Considerations for the determination of the design requirements for the Site Link objects

2. Considerations for the design of a cost value model for Site Link objects

3. Considerations for the determination of the design requirements for Site Link replication schedules and intervals

4. Considerations for the determination of the design requirements for reciprocal replication for Site Link objects

5. Considerations for the determination of the design requirements for inter-Site change notification for Site Link objects

6. Considerations for the design of the configuration of Site Link objects

9.9.1. Determination of the Design Requirements for Site Link Object Descriptions

Consider the following when determining the design requirements for the description of Site Link objects:

Factor B1: Understanding the requirements for the design of the description field for Site Link objects


Has identified the requirements for the design and implementation of two or more Site Link objects, and



Wishes to understand the requirements for the design of the description field for the required Site Link object(s)


Site Link objects are typically managed, within Active Directory, via the “Sites and Services” MMC snap-in. This GUI tool supports a Site administrator in the execution of all management tasks for all aspects and components of a Site infrastructure for an Active Directory forest.

The design for the description of Site Link objects is required to facilitate their administration and troubleshooting by Site infrastructure administrators.

When this tool focuses on the “Inter-Site Transports” folder and the IP or SMTP sub-folders (which house the Site Link objects), the GUI provides the following information about each Site Link object:

The name of the Site Link object

The type of object (Site Link)

The description of the Site Link object

The cost assigned to a Site Link object

The replication interval assigned to a Site Link object

It is not possible to add any more columns to this view, but it is possible to remove columns and change their display order.

Hence, without examination of the properties of a Site Link object, the default view does not illustrate the following metadata aspects of Site Link objects:

The Sites within the Site Link object

The replication schedule for the Site Link object

The function or role of the Site Link object within the Site infrastructure

The description field is hence a potential vehicle for illustrating this information.

The Organisation-Wide Active Directory Plan process, “design of object naming models”, proposes that the names of Site Link objects reflect the Sites connected by the Site Links, and hence the description field must not duplicate this information.

Factor A1: Determination of the design requirements for the description of Site Link objects



Wishes to determine the design requirements for the description field for the required Site Link object(s)




When determining the design requirements for the description of Site Link objects, consider the following:

The Site Link objects for a Site infrastructure are segregated within the “Sites and Services” MMC snap-in into supported transport protocols (IP or SMTP), and hence there is no requirement to describe the transport protocols within the description field.

Where an organisation has identified the requirements for the design of multiple Site Link objects, for each transport protocol, then it is necessary to support quick differentiation between the Site Link objects. As the primary distinction between multiple Site Link objects are the Sites supported by each Site Link, the name of each Site Link object will hence provide support for the initial differentiation. The secondary differentiator between the Site Links that may support all or some of the same Sites is the replication interval, cost, schedule, and function or role of the Site Links.

This design methodology proposes that the description of the Site Link objects reflect the replication schedule for the Site Link object, or the function / role of the Site Link objects within the Site infrastructure.

This design methodology proposes execution of the following approach to determine the design requirements for the description of Site Link objects

Determine the requirements for the use of the:

Function / role of the Site Link objects, or

The replication schedules of the Site Link objects, or

A combination of these two metadata aspects of Site Link objects, or

Other metadata aspects not discussed here

Where there is a requirement to use the function / role of a Site Link object as the descriptors, then:

Determine the function of all required Site Link objects, for each transport protocol

Determine the presence of any differentiators between the functions / roles of the Site Link objects

Where there is a requirement to use the replication schedules for Site Link objects as the descriptors, then:

Determine the replication schedules for all required Site Link objects, for each transport protocol

Determine the presence of any differentiators between the replications schedules of the Site Link objects. Note that where the replication schedule for all Site Link objects, for a transport protocol, are all exactly the same (such as “24x7”) then it is not feasible to use this metadata aspect as the Site Link descriptor. This is because there is no differentiation between the Site Link objects using this metadata aspect.

Where there is a requirement to use another metadata aspect of a Site Link object, not listed here, then adopt the same approach as for the function / role and the replication schedules for Site Link objects.



When determining design requirements for the description, to reflect the function or role of Site Link objects, consider the following:

The requirements for the design and implementation of a Site Link object will define its function and role within the Site infrastructure. For example, there may be a requirement to create a Site Link object to enforce or control the use of specific network links between physical locations, and so on. See the Site Plan process, “determination of the requirements for multiple Site Link objects”, for details.

When determining the design requirements for the description field, to reflect the function / role of the Site Link objects, this design methodology recommends that the description of the function / role is short in length.

When determining the design requirements for the description, to reflect the replication schedules of the Site Link objects, consider the following:

It is possible to express the replication schedule for a Site Link object as days of the week, and hours during each day when the Site Link permits or prohibits replication. This design methodology recommends that the description field only reflect the permitted replication schedules.

This design methodology provides the following examples for the depiction of the replication schedule for a Site Link object within the description field:

“Replication Schedule: M-F 18:00 to 06:00”

“Replication Schedule: M-W 19:45 to 02:00”; T-F 18:00 to 06:00”

“Replication Schedule: 24x7”


Determine the metadata aspect(s) of the Site Link objects that require reflection as the Site Link descriptor

Determine the presence of differentiators within the selected metadata aspect(s)

Determine the design requirements for the selected metadata aspects of the Site Link objects, for representation within the description field.

9.9.2. Design of a Cost Value Model for Site Link Objects

Consider the following information when generating a design for a cost value model for Site Link objects:

Factor B2: Understanding the requirements for the design of a cost value model for Site Link objects



Wishes to understand the requirements for the design of a cost value model for Site Link objects




The cost value for a Site Link object controls the paths for replication of the Active Directory naming contexts between the Sites. The domain controller holding the ISTG role within each Site will inspect the cost values of the Site Links (stored in the Configuration partition) and calculate the least-cost route between Sites for the creation of inter-Site connection objects using the spanning-tree algorithm.

Because the majority of organisations have a fluid and dynamic network topology that is constantly evolving to meet new and greater demands on network utilisation, the cost values that are to be designed for the Site Link objects should reflect this.

Hence, it is proposed that a cost value model is developed that provides a process and formula for the assignment of consistent relative cost values to Site Link objects within an evolving and dynamic environment.

Factor B3: Understanding cost values for Site Link objects



Wishes to understand cost values for Site Link objects, prior to the design of a cost value model


Before investigating the factors that will require consideration for the process to design a cost value model for Site Link objects, it is important to acknowledge and understand the following facts about the cost value for a Site Link object:

The cost value for a Site Link object in Windows Server 2003 exists as an integer value between 1 and 99,999

The default cost value for all new (IP and SMTP) Site Link objects is set to 100

The design for cost values are entirely relative to the cost values for all Site Link objects (for IP and SMTP transport protocols) within a Site infrastructure. Hence, the process to design cost values for Site Link objects is an iterative process, to ensure the correct dependencies and priorities between Site Links, to route Active Directory replication traffic, are preserved.

Factor B4: Understanding the proposed approach for the design of a cost value model for Site Link objects



Wishes to understand the proposed approach for the design of a cost value model for Site Link objects




The cost value of a Site Link has a direct influence on the routing of inter-Site Active Directory replication traffic. Hence, the design for the cost value model is required to reflect all business and technical requirements to control the routing of inter-Site Active Directory replication traffic.

When generating a design for a cost value model, this design methodology proposes execution of the following iterative approach:

Understand the factors that will influence the design for the routing of inter-Site Active Directory replication traffic.

Identify the factor that has the greatest priority and influence on the routing of inter-Site replication traffic within the organisation.

Determine the baseline cost value to reflect this highest priority factor.

Identify all other factors influential to the routing of inter-Site replication traffic, which are applicable to the organisation.

Prioritise each of these other factors from zero to 100 (where zero is the highest priority (the same as the baseline cost value factor) and 100 is the lowest priority.)

Use the formula provided by this design methodology to translate these priority values into cost values for Site Links. The cost value formulas will translate low priority ratings to a higher cost value, and vice versa.

The following section of this step, within this process, will provide considerations for the following:

The factors that can influence the routing of inter-Site Active Directory replication traffic

The selection of a factor to represent the baseline cost value

The formulas to calculate the baseline cost value and the final cost values for Site Link objects

Factor B5: Understanding the influence of bandwidth availability within network links on the design for the routing of inter-Site Active Directory replication traffic

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of bandwidth availability within network links on the routing of inter-Site Active Directory replication traffic during the windows for replication.


The levels of available bandwidth within network links and segments of a network infrastructure have a significant influence on the design for the routing of inter-Site Active Directory replication traffic.

Inter-Site Active Directory replication traffic is, by default, compressed, and it is possible to schedule the transport of this network traffic by the appropriate network links. However, although these features will minimise the impact of this network traffic on supporting network links and segments, it is still necessary to consider the relationships between the volume and frequency of Active Directory replication traffic and the levels of available bandwidth.



It is important to note that Site Links may support not only routine Active Directory replication traffic, but also full Active Directory database replication between Sites in emergencies. For example, a remote Site experiences a site-specific disaster and all servers and domain controllers experience irreparable software damage. The SLAs for recovery demand that each local domain controller return to normal function within a few hours, and this negates the time required to retrieve and use backup tapes stored offsite. This hence requires the use of an inter-Site network link to replicate an entire Active Directory database. Where the size of the Active Directory database for a domain is several hundred megabytes in size, then this may take some time to replicate if the supporting network link demonstrates low levels of available bandwidth.

The results of the Site Plan process, “analysis of current and proposed network infrastructure” will provide the details of the levels of net available bandwidth within all applicable network links for this Site infrastructure.

When understanding the influence of levels of available bandwidth within network links, on the design for the routing of inter-Site replication traffic, consider the following:

It is important to consider time zone differences between physical locations and the subsequent patterns of bandwidth availability in the respective network links. For example, an organisation has two offices, with one of these offices in a remote geographical location, in a time zone five or six hours behind the other. A network link between these offices may only show low levels of available bandwidth for a short period of time, which may represent the business hours overlap between the locations for the two offices. Hence, as business and non-business hours may vary between remote office locations, this may reflect the patterns of bandwidth availability in the WAN links that directly or accumulatively span different time zones.

This design methodology proposes execution of the following approach, to collect information on the influence of the levels of available bandwidth within network links on the design for the cost value model:

Analyse the results of the Site Plan process, “analysis of current and proposed network infrastructure” to identify all network links that comply with the following criteria:

Demonstrate historically low levels for available bandwidth, and

Will support inter-Site Active Directory replication traffic

For each identified network link, determine the following information:

The patterns of bandwidth availability within the network link, with respect to business and non-business hours and days

The current primary and secondary sources of non-Active Directory related network traffic that directly and indirectly influence the levels of available bandwidth within the network links

The direction of the network traffic across the network links

Repeat this analysis for all identified network links to generate a picture of current and proposed network traffic flow within the supporting network infrastructure.

Identify all potential “problem” network links, due to compliance with the following criteria:



The levels of available bandwidth within the network link is extremely low (only a few kilobytes per second)

It is not feasible to replace or upgrade the network link to a link with higher levels of available bandwidth

The patterns of available bandwidth leave only small windows to support inter-Site Active Directory replication to and from the appropriate Site

Identify all “preferred” network links, due to compliance with the following criteria:

The levels of available bandwidth within the network link are extremely high, as it is historically under utilised

The network link is upgradeable on demand, and at a feasible cost

The patterns of usage of a network link provide adequate windows to support inter-Site replication, without introducing network latency for other applications and processes reliant upon the network link.

Collate and document this information, to support the design of the cost value model for the Site Link objects.

Factor B6: Understanding the influence of the presence of redundant WAN Links between physical locations on the design for the cost value model for Site Link objects


Has one or more physical locations that contain more than one network links to and from other different physical locations, and:

Not all of these network links are active and are present for redundancy or are they are used for dedicated processes within the organisation, and

The non-primary network links to and from a physical location can be used for inter-Site replication traffic if the need arises, and

Wishes to understand the influence of the presence of these redundant network links on the design for the cost value model for Site Link objects


Where an organisation has identified the requirements for the design and implementation of one or more Site Link objects to support redundant / emergency network links, then it is necessary to assign these Site Links with a higher cost value.

Hence, all such requirements require assignment of a lower priority rating to influence the design for the cost value model for Site Link objects.

Factor B7: Understanding the influence of the direction and volume of inter-Site replication traffic on the design for the cost value model for Site Link objects

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of the direction and volume of inter-Site replication traffic on the design for the cost value model for Site Link objects




The Site Plan process, “determination of the requirements for multiple Site Link objects”, provides the considerations for this factor. The direction, frequency of generation and transmission, and volume of inter-Site replication traffic is a key consideration in the design for the cost value model for Site Link objects.

The Active Directory administration model for the forest will influence the source for the majority of Active Directory replication traffic, and the cost values for Site Link objects must hence consider this factor.

Factor B8: Understanding the influence of tolerance requirements for replication latency between the Sites on the design for the cost value model for Site Link objects


Is able to identify one or more Sites that will exhibit low levels of tolerance for replication latency, and

Wishes to understand the influence of tolerance requirements for replication latency between the Sites on the design for the cost value model for Site Link objects


Within some Sites for an organisation, it may be possible to identify one or more applications or processes intrinsically dependent upon up to date data within the Active Directory.

In these scenarios, any latency associated with the reception of Active Directory replication traffic may generate unacceptable consequences. The design for the cost value model for Site Link objects may support and reflect these requirements and low tolerance levels for replication latency, via the corresponding inter-Site routing of Active Directory replication traffic.

This design methodology proposes execution of the following approach to determine the influence of this requirement on the design for the cost value model for Site Link objects:

Identify all Sites with low tolerance levels for inter-Site Active Directory replication latency

For each identified Site, identify the corresponding “source” Site(s) for the changes to the Active Directory that require replication to this Site

Where it is possible to identify such Site relationships, determine the level of influence these relationships will have on the design for the routing of inter-Site Active Directory replication traffic.

Factor A2: Identification of the factor to represent and define the baseline cost value


Has considered all factors listed above, and other factors not listed, which will influence the design for the routing of inter-Site Active Directory replication traffic, and



Wishes to identify the primary factor that will represent and define the baseline cost value for all Site Link objects within this Site infrastructure


Because cost values for Site Link objects are strictly relative between Site Link objects within this Site infrastructure only, all cost values must reflect a common baseline value. The baseline cost value is a reflection of a single factor that an organisation deems to be the most influential in the design for the routing of inter-Site Active Directory replication traffic.

This design methodology proposes execution of the following approach to identify the single factor to represent and define the baseline cost value for this cost value model:

Define the criteria for the selection of this factor

Analyse all factors listed earlier, and not listed but specific to an organisation (as been influential in the design for the routing of inter-Site Active Directory replication traffic), and identify all factors applicable to an organisation

Evaluate all applicable factors against the defined criteria for selection of the baseline cost value factor, and identify the single most influential factor within the organisation.

When defining the criteria for the selection of the baseline cost value factor, consider the following:

Although the onus is with the organisation to define their criteria for the selection of this factor, this design methodology provides the following example criteria and considerations:

The selected factor must be a parameter common to all network links that will be represented and use by Site Link objects

The selected factor must represent a variable applicable to, and between network links that is scalable to accommodate changes within the organisation such as reorganisation, growth, mergers and acquisitions, and so on

The selected factor must be definable as an integer value, for input into cost value formulas to define the baseline value

Although the onus is with the organisation to select their factor, this design methodology proposes that the levels of available bandwidth within a network link represents and defines the baseline cost value for all Site Link objects.

Although the remaining considerations for this step within this process will use the levels of available bandwidth to represent and define the baseline cost value, the organisation is free to substitute their own selected factor.


Define the criteria for the selection of the baseline cost value factor

Evaluate all factors influential in the design for the routing of inter-Site Active Directory replication traffic, and identify those factors applicable to the organisation



Evaluate all applicable factors against the defined criteria, and identify a single baseline cost value factor

Factor B9: Understanding the formula to calculate the baseline cost value


Has identified a single factor to represent and define the baseline cost value, and

Wishes to understand the formula to calculate the baseline cost value for all Site Link objects within this Site infrastructure


This design methodology proposes the use of the following formula to calculate the baseline cost values for Site Link objects, based upon the use of the available bandwidth levels within network links.

Formula to calculate baseline cost values using available bandwidth:

Baseline Cost Value =1024

log (available bandwidth (Kb))

For example, an organisation has two remote locations, represented as discrete Active Directory Sites, and connected by a single network link. Analysis of a network link identifies that the levels of available bandwidth is 512Kbps. Using the above formula, it is possible to calculate the following value for the baseline cost value for a single Site Link object, supporting just these two Sites:

= 3781024

log (512)

Factor B10: Understanding the formula to calculate the final cost values


Has defined the factor to support and represent the baseline cost value, and

Wishes to understand the formula to calculate the final cost values for all Site Link objects within this Site infrastructure


This design methodology proposes the following formula to support the calculation of the final cost value for a Site Link object:

Final Cost Value = + 1 x Baseline Cost ValueAverage of Priority Values

50( ) )(For example, it is determined that considerations for the volume and direction of inter-Site replication traffic and the requirement for low latency for a Site Link between two Sites will have the priority values of 30 and 40 respectively. The network link that the Site Link between the two Sites represents has an available bandwidth statistic of 256Kbps.



Hence, the final cost value for this Site Link will be (using available bandwidth as the baseline cost value factor):

Final Cost Value = + 1 x = 723((( ) ))(30+40)/250

1024log (256)

In another example, organisation has identified a network link, billed on a pay-per-usage basis, which supports a Site Link between two Sites. The organisation has decided that the financial overheads associated with this network link will limit its availability for inclusion within the Active Directory replication topology for the forest. Hence, the organisation assigns a priority value of 90 to the Site Link that represents this network link. The network link also has a low level of available bandwidth of only 64Kbps, due to heavy utilisation by non-Active Directory related network traffic.

Hence, the cost value for the Site Link that represents this network link is (using available bandwidth as the baseline cost value factor):

Final Cost Value = + 1 x = 1588((( ) ))9050

1024log (64)

9.9.3. Determination of the Design Requirements for the Replication Schedules and Intervals for Site Link Objects

Consider the following when determining the design requirements for the replication schedules and intervals for Site Link objects:

Factor B11: Understanding the requirements for the design of replication schedules and intervals for Site Link objects



Wishes to understand the requirements for the design of replication schedules and intervals for Site Link objects


The replication schedule and interval for a Site Link object determines the availability of the Site Link to support inter-Site Active Directory replication traffic.

The replication schedule (as days and hours during the days) determines when a Site Link permits inter-Site replication between Sites within the Site Link. The replication interval determines how often a bridgehead server within a Site polls its replication partner in another Site, across a Site Link, for changes to the Active Directory that it can pull to its Site.

The design for the replication schedule and interval for the Site Link objects must provide, among other objectives, a balance between the requirements to reduce replication latency whilst minimising inter-Site replication traffic.

Factor B12: Understanding replication schedules and intervals for Site Link objects





Wishes to understand the concepts of replication schedules and intervals for Site Link objects


Prior to investigation of the factors that influence the design for the replication schedules and intervals for the Site Link objects, consider the following:

The default replication schedule for a new Site Link object sets the availability of the Site Link to 24 hours a days, 7 days a week.

The default replication interval for a new Site Link object is set to 180 minutes (3 hours.) The minimum replication interval that can be set for a Site Link object is 15 minutes, and the maximum is 10,080 minutes (1 week.) The value for the replication interval can only be set in multiples of 15 (minutes).

The schedule user interface (UI) uses the Universal Time Coordinate (UTC.) This is the international time standard and is the new term for what used to be known as Greenwich Mean Time (GMT.) Zero hours UTC is midnight in Greenwich, UK. Windows Server 2003 Active Directory uses the twenty-four hour clock to express the time.

The use of UTC allows the schedule UI to cater for time zone differences between physical locations around the Earth and display the time as local time. Hence, a schedule set on a computer in the UK for a Site Link for between 00:00 hours (midnight) and 01:00 hours would be displayed within the schedule UI on a computer in New York (-5 hours UTC) as 19:00 to 20:00.

Although the times that can be set on the schedule for a Site Link are in increments of one hour, each block in the actual connection schedule is fifteen minutes. This means that if, for example, a schedule is set for 18:00 to 00:00, transmission of the first replication queue will occur between 18:00 and 18:14:59. Hence, the minimum replication interval for a Site Link object is 15 minutes.

Each replication event is queued at (“time” + “n”) where “time” represents the replication interval for the Site Link (for example, every 120 minutes (2 hours)) and “n” is the variable of between 1 and 15 minutes for the start of the replication event. Hence, for example, if a schedule is set to 18:00 to 07:00, and the replication interval is set to 240 minutes, then replication events will be triggered to occur between the following times: 18:00 and 18:14:59; 22:00 and 22:14:59; 02:00 and 02:14:59; and 06:00 and 06:14:59.

Site Links are, by default, transitive and this hence allows replication traffic to cross multiple Site Links to reach a destination Site. However, there must be a common open window for replication across all of the Site Links that have to be crossed. If there is not, then replication will not reach the destination Site.

This is demonstrated in the following illustrated example, where the only time replication traffic from Site A can reach Site E is between 23:00 and 01:00, as this is the only common window for replication across Site Links 1, 2 & 3:



18:00 19:00 20:00 21:00 22:00 23:00 24:00 01:00 02:00 03:00 04:00 05:00 06:00

Site Link 118:00-06:00

20:00 21:00 22:00 23:00 24:00 01:00 02:00

23:00 24:00 01:00

Site Link 118:00 – 06:00

Site Link 220:00 – 02:00

Site Link 323:00 – 01:00

Site Link 323:00-01:00

Site D

Site EReplication Window

Site CSite Link 220:00-02:00

Site ASite B


Figure 26.1: Example of Common Replication Windows for Site Link Objects

Note, in the above example, the replication interval for Site Link 3, which connects Sites C, D, and E, will take precedence for replication from Site A destined for Site E between the hours of 23:00 and 01:00. Hence, where the replication interval for Site Link 3 is 30 minutes, then replication between Site A and Site E is only permitted between:

23:00:00 and 23:14:59

23:30:00 and 23:44:59

00:00:00 and 00:14:59

00:30:00 and 00:44:59

Note that this also assumes the absence of any delays in previous replications on this Site Link that will override this schedule. If the replication interval on Site Link 3 is set to 120 minutes, then replication would only take place once between Sites A and E, because replication would only occur at:

18:00 – 18:14:59 – no replication between Sites A and E



00:00 – 00:14:59 – replication permitted between Sites A and E



As can be seen from this simple example, the design of a replication schedule and interval for Site Link objects can influence the paths that replication can take between Sites.

Factor B13: Understanding the proposed approach for the design of replication schedules and intervals for Site Link objects



Wishes to understand the proposed approach for the design of replication schedules and intervals for Site Link objects


The replication schedules and intervals for Site Link objects have a direct influence on the routing of inter-Site Active Directory replication traffic. Hence, the design for the replication schedules and intervals must reflect all business and technical requirements to control the routing of inter-Site Active Directory replication traffic.

When generating a design for the replication schedules and intervals for Site Link objects, this design methodology proposes execution of the following approach:

Understand the factors that will influence the design for the replication schedules and intervals for Site Link objects

Identify all factors applicable to an organisation

Select a required Site Link and execute the following steps:

Identify the categories for the Sites within the Site Link, with respect to the source and / or target for Active Directory replication traffic (the Site Plan process, “determination of the requirements for multiple Site Link objects”, provides the results of the Site categories).

Identify the required inter-Site paths for Active Directory replication traffic that the Site Link can support (for example, in figure 26.1 above, “Site Link 1” supports Sites A and B, and hence can exclusively support inter-Site replication between Sites A and B)

Identify the required inter-Site paths for Active Directory replication traffic that must pass between two or more Site Link objects (for example, in figure 26.1 above, inter-Site replication between Sites A and E must travel across Site Links 1, 2, and 3)

Evaluate all applicable factors that may influence the replication schedule and interval for:

“Intra-Site-Link” replication (inter-Site replication between Sites within the same Site Link object, such as between Sites A and B in figure 26.1), and

“Inter-Site-Link” replication (inter-Site replication between Sites within different Site Link objects, such as between Sites A and E in figure 26.1) (Note that the prerequisite for “inter-Site-Link” replication is the presence of a common replication window across all Site Link objects



within the replication path, and a suitable replication interval in the appropriate Site Link objects).

Determine the optimum and / or permitted schedule and interval for the Site Link object, which supports all identified and applicable factors and all requirements for the execution of all “intra-Site-Link” and “inter-Site-Link” replication.

Repeat the above process for each required Site Link object.

Re-examine all required replication schedules and intervals and ensure a consistent design that supports all identified requirements for the execution of all “intra-Site-Link” and “inter-Site-Link” replication.

Factor B14: Understanding the influence of the volume, frequency, and direction of inter-Site replication traffic on the design for the replication schedules and intervals



Wishes to understanding the influence of the volume, frequency, and direction of inter-Site replication traffic on the design for the replication schedules and intervals


For each Site Link object within the proposed Site Link topology, the requirements to support the predicted volume, frequency, and direction of inter-Site replication traffic require reflection in the design of the corresponding replication schedule and interval.

For Site Link objects using the RPC over IP transport protocol, it should be noted that outbound inter-Site replication traffic is sent in parallel, whilst inbound inter-Site replication traffic is serialised.

Hence, for example, at a hub Site that may predominantly generate a large volume of network traffic, which requires replication to multiple remote Sites, it is necessary to generate multiple parallel connections to remote bridgehead servers in different Sites via a multithreaded process.

However, for a Site that may predominantly receive a large volume of replication traffic from multiple (directly or indirectly) connected remote Sites, then only one inbound connection can be created and processed at a time on the bridgehead server for that Site.

For RCP over IP outbound replication from a Site, the time required to complete replication depends upon:

The volume of traffic to be sent

The number of inbound connections the recipient bridgehead server in the remote Site is required to manage, in addition to the inbound from this Site. Due to serial processing of inbound connections, it is not possible for a source bridgehead server, in a remote Site, to transmit replication traffic until the destination bridgehead server is ready to receive, because it has to finish processing all previous inbound connections first.



All the other relevant factors and considerations stated for the process, “design for preferred bridgehead servers”, such as bridgehead server hardware resources and I/O capabilities and so on.

For RPC over IP inbound replication from a Site, the time required to complete replication depends upon:

The volume of traffic to be processed during each inbound connection within each replication cycle

The numbers of inbound connections, for that Site, that requires processing during each replication cycle. For example, if each connection to a remote bridgehead server takes 5 minutes to complete, and it is necessary to create 12 inbound connections, then each replication cycle will take 60 minutes. Note that for the Sites where the network connection requires creation for each replication cycle, for example, as a dial-up connection, then it is necessary to consider the time required to establish the connection in replication schedule and interval calculations.

All the other relevant factors and considerations stated for the process, “design for preferred bridgehead servers”, such as bridgehead server hardware resources and I/O capabilities and so on.

Note that SMTP over IP inbound inter-Site replication traffic is also processed serially, by order of arrival.

In order to schedule the use of a WAN link for inter-Site replication traffic during out-of-business-hours, it is important to perform a historical and statistical analysis of the WAN link to determine:

The average bandwidth availability and reliability of the WAN link during the proposed schedule for inter-Site replication

The requirements to support other concurrent and scheduled business processes / applications, for example, to synchronise databases between the physical locations or copy business data at the end of each working day and so on.

Factor B15: Understanding the influence of the requirement to ensure minimal replication latency and network traffic on the design for the replication schedules and intervals



Wishes to understanding the influence of the requirement to ensure minimal replication latency and network traffic on the design for the replication schedules and intervals


It is important to understand the role that the value of the replication interval can have on replication latency and volume of network traffic during each replication cycle.

A long replication interval will allow the copies of the naming contexts held within the two connected Sites to attain replication convergence. However, the downside of this is that the replication interval will support the generation and



transmission of a greater volume of network traffic, across for example a WAN link, during each replication cycle.

Hence, the design of the replication interval must attain a balance between reducing replication latency and minimising the volume of network traffic transmitted during each replication cycle. If the network link between the two Sites has ample available bandwidth during the required replication cycle, then the replication interval can be sufficiently large to ensure all replication is completed, and vice versa.

Factor B16: Understanding the influence of time zone differences between Sites within the Site Link topology for the forest on the design for the replication schedules and intervals



Wishes to understanding the influence of time zone differences between Sites within the Site Link topology for the forest on the design for the replication schedules and intervals


When determining the design requirements for replication schedules and intervals, it is important to consider time zone differences.

Hence, where a Site Link object will connect two Sites in different time zones, “out-of-business-hours” may have different “local” interpretation, and hence because of the time zone differences, business hours will vary.

For example, Site A is in London, UK and Site B is in Sydney, Australia, and there is a WAN link between these two Sites. Sydney is +10 hours UTC. Hence, (for a Site Link between Site A and B) where a schedule is set in London for “out-of-business-hours” as Monday 18:00 to 00:00, this would correspond to Tuesday 04:00 to 10:00 in Sydney, where business hours commence at 09:00. Hence, users, applications, and process in Sydney might be using the WAN link between London and Sydney between 9am and 10am (in Sydney.)

Active Directory replication between Site A and Site B may hence introduce contention for bandwidth within the WAN link between 23:00 and 00:00 London time.

Factor B17: Understanding the influence of the presence of shared domain naming contexts between Sites on the design for the replication schedules and intervals


Has multiple Sites that share common domain naming contexts, and


Wishes to understanding the influence of the presence of shared domain naming contexts between Sites on the design for the replication schedules and intervals




Where inter-Site-Link or intra-Site-Link replication is required to support intra-domain replication, then it is important to ensure that these Sites replicate as frequently as possible.

This is to permit all changes within a domain to be replicated to as many of the domain controllers for that domain within as short a period as possible. However, this may have implications where, for example, users may roam between Sites and changes to their user account (such as password, group memberships, mailbox configuration (where the forest supports Exchange 2000 or Exchange Server 2003) and so on. It is hence necessary, in these scenarios, to ensure the reflection of all intra-domain changes across all domain controllers in all the Sites that the users roam between.

To facilitate frequent inter-Site replication, it may be necessary to design a replication schedule that allows two or more windows for replication within every 24-hour period, such as replication once during the day and once during the night.

Factor B18: Understanding the influence of the requirement to ensure continued replication between Sites on the design for the replication schedules and intervals


Has identified the requirements for the design and implementation of two or more Site Link objects

Wishes to ensure continued inter-Site replication upon the failure of any intermediate Site(s), and

Wishes to understanding the influence of the requirement to ensure continued replication between Sites on the design for the replication schedules and intervals


The design of the replication schedule can support the requirement to ensure continued inter-Site replication, by ensuring that a common window for replication remains across all or a subset of the Site Links that link the Sites.

Inter-Site-Link replication relies upon the presence of a common window for replication, as illustrated in figure 26.1. This will ensure that in the event of failure of an intermediate Site, it is still possible to transmit Active Directory replication traffic across alternate routes to the destination Sites.

Factor A3: Determination of the design requirements for the replication schedules and intervals


Has considered all factors listed above, and other factors not listed, which will influence the design for the replication schedule and intervals for Site Link objects, and

Wishes to determine the design requirements for the replication schedules and intervals for all required Site Link objects




Following analysis of all factors listed above, and those the organisation deems internally influential in the design for the replication schedules and intervals, it is necessary to determine the design requirements.

When determining the design requirements for the replication schedules and intervals for each required Site Link object, execute the approach outlined in factor B12 above and the following:

Determine and document all factors influential to the design of the replication schedules and intervals, and applicable to the organisation

Determine and document all design requirements for the replication schedules and intervals, specifically to support inter-Site replication, as “inter-Site-Link” and “intra-Site-Link” replication

Pass this information to the final step within this process, to generate the design for the configuration of the Site Link objects.

9.9.4. Determination of the Design Requirements for Reciprocal Replication

Consider the following information when determining the design requirements for reciprocal replication for Site Link objects:

Factor B19: Understanding reciprocal replication for Site Link objects


Has identified the requirements for the design and implementation of one or more Site Link objects, and

Wishes to understand the concepts of reciprocal replication for Site Link objects


Reciprocal replication is an advanced configuration feature of inter-Site replication that only requires design and implementation to support specific requirements.

This process will assist an organisation in determining the requirement to enable this feature on selected Site Link objects within their forest.

Reciprocal replication is a feature of inter-Site replication designed to allow replication between domain controllers that need to replicate over non-permanent network connections.

The mode of replication between domain controllers differs from intra-Site and inter-Site. Intra-Site replication initiates on a change notification basis, and hence, once a change transaction is completed on a domain controller it will send a change notification to its replication partners within the Site. Once the partners receive this notification they will request the changes from the notifying domain controller. Following the completion of the replication of all changes to the replication partners, they in turn will send a change notification to the original domain controller. This hence allows two-way replication to occur within a Site.



However, inter-Site replication initiates only on a scheduled basis, and it only supports pull replication, where domain controllers request changes from replication partners in remote Sites. Note that upon completion of inter-Site replication, there is no reciprocal replication to allow the original sending Site to pull changes from the original requesting Site.

This can hence cause replication issues where there exists a non-permanent (such as a dial-up) network connection between the Sites. If the dial-up connection can only be initiated from a domain controller within one Site, then that Site will, in essence, remain incommunicado until it wishes to replicate, as per the replication schedule for its Site Link object. This hence means that other Sites that need to pull replication data from this Site will be unable to do so as per their replication schedule.

To solve this issue, it is possible to define a specific value on an attribute of a Site Link object to enable inter-Site reciprocal replication. With this option enabled (via the use of ADSI Edit), the following (example) scenario will occur:

Domain controller 1 in Site A establishes a dial-up connection to Site B to pull replication data from domain controller 2 in Site B

Once the network connection is established, domain controller 1 requests changes to the Active Directory and pulls them from domain controller 2.

Once replication is complete, domain controller 1 then sends domain controller 2 a change notification.

Domain controller 2 receives the change notification and then requests changes to the Active Directory from domain controller 1

Domain controller 1 sends the changes to domain controller 2

Once domain controller 1 sends all changes to domain controller 2, the connection terminates.

It is important to note the following facts about reciprocal replication:

It is only possible to enable reciprocal replication on Site Link objects that use the RPC over IP transport protocol. This feature is not support on Site Link objects configured to use the SMTP over IP transport protocol.

Enabling reciprocal replication for a Site Link object will affect all inter-Site replication processes for all Sites within that Site Link object. Remember, a Site Link object can contain more than two Sites.

Reciprocal replication is enabled on a Site Link object using ADSI Edit to modify the “options” attribute of the “cn=IP” object within the “cn=Inter-Site Transports” object container, using the following process:

Where the value of the “options” attribute shows <not set>, then enter a value of “2” in the value field, and click OK

Where the value field already contains a value, then it is necessary to calculate a new value via a Boolean BITWISE-OR calculation on the old value, using the formula “<old_value> BITWISE-OR 2”. For example, if the value in the Value(s) field is “1”, then calculate “0001 OR 0010 to equal 0011”. Type the integer value of the result in the Integer Attribute Editor field, which for this example will be a value of “3”.

Factor A4: Determination of the requirements for the design of reciprocal replication




Has identified the requirements for the design of one or more Site Link objects, and

Wishes to determine the requirements for the design and implementation of reciprocal replication


When determining the requirements for the design and implementation of reciprocal replication, this design methodology proposes the following approach:

Examine the results of the Site Plan process, “analysis of current and proposed network infrastructure”, and identify the presence of any non-permanent network links that support inter-Site replication.

Where it is not possible to identify the presence of such network links, then it is not necessary to design and implement reciprocal replication on any of the required Site Link objects.

Where it is possible to identify the presence of such network links, then execute the following:

Determine compliance of this network link with the following criteria:

The network link supports inter-Site replication for one or more Site Link objects

The Site Link objects that rely upon the network link use the RPC over IP transport protocol, and not the SMTP over IP transport protocol

The enabling of reciprocal replication on one or more of the affected Site Link objects will not generate any unacceptable consequences for inter-Site replication for the other Sites within the Site Links

Where it is possible to identify compliance with these criteria, then this design methodology supports the design and implementation of reciprocal replication for the relevant Site Link objects.

Note that where the enabling of reciprocal replication may generate unacceptable consequences for one or more other Sites within the affected Site Link object, then it is necessary to consider the removal of these affected Sites from the Site Link object, and placement into a new or another Site Link object.


Determine the requirements for the design and implementation of reciprocal replication on one or more Site Link objects

Identify the Site Link objects that require reciprocal replication

Determine and document all consequences of enabling this feature on all inter-Site-Link replication for the in-scope Site Link objects

Factor A5: Determination for the requirements to redesign the replication schedule and interval on the Site Link object enabled for reciprocal replication




Has identified the requirements to enable reciprocal replication for one or more Site Link objects within the forest, and

Wishes to determine the requirements to redesign the replication schedule and interval on the Site Link objects, enabled for reciprocal replication


The design for the replication schedule and interval for the Site Link object may require redesign, as it is now necessary to factor into the calculations the following:

The time required by domain controllers to establish the dial-up connection to a remote Site, and

The time now required for the Site to push all replication data out of the Site as well as receive replication data


Identify all Site Link objects where reciprocal replication is enabled

Determine the time required to establish network connectivity between the bridgehead domain controllers in each Site

Determine the average time that may be required to complete the push of all replication data out of the Sites

Determine the impact of modifications (as an extension) to the replication schedules and intervals on inter-Site replication

9.9.5. Determination of the Design Requirements for Inter-Site Change Notification

Consider the following information when determining the design requirement for inter-Site change notification for one or more Site Link objects within this Site infrastructure:

Factor B20: Understanding reciprocal replication for Site Link objects


Has identified the requirements for the design and implementation of one or more Site Link objects, and

Wishes to understand the concepts of reciprocal replication for Site Link objects


Inter-Site replication is normally initiated according to a replication schedule and interval configured within a Site Link object. However, the completion of a transaction, to implement a change (object creation, modification, or deletion) on a domain controller, initiates intra-Site replication. Once the change transaction is completed, the domain controller will notify its direct replication partners of the change following a configurable delay period, where the default



is 300 seconds (5 minutes) (in the “Windows 2000” forest functional level). This is change notification replication.

Hence, within a Site, there is little replication latency between the domain controllers. However, between Sites, the replication latency can increase substantially as it relies upon the replication schedule and intervals for Site Link objects. In a large multi-Site infrastructure, the greatest replication latency between Sites will be the accumulation of the replication latencies along the longest replication path between Sites within a forest.

To address the issues associated with potentially significant statistics for replication latency, it is possible to configure change notification for inter-Site replication by enabling this feature on a Site Link object using ADSI Edit.

It is important to note the following about inter-Site change notification:

Enabling inter-Site change notification on a Site Link object essentially switches off the replication schedule for that Site Link object and then adds the extra functionality. Disabling the replication schedule for a Site Link object alone does not achieve the same functionality.

Inter-Site change notification will include replication traffic for changes that fall within the scope of urgent replication, such as account lockout changes and so on.

It is only possible to enable inter-Site change notification on Site Link objects that use the RPC over IP transport protocol. It is not possible to enable this feature on Site Link objects configured to use the SMTP over IP transport protocol.

Enabling inter-Site change notification for a Site Link object will affect all inter-Site replication processes for all Sites within that Site Link object. Remember, a Site Link object can contain more than two Sites.

Inter-Site change notification should only be enabled on Site Link objects that relate to permanent network connections between Sites and not on Site Link objects for non-permanent (e.g. dial-up) connections. Enabling inter-Site change notification on Site Links for dial-up connections will cause frequent dial-up connection attempts that may become costly.

When enabling inter-Site change notification on a Site Link object, it is necessary to evaluate the impact of enabling this feature on the volume of inter-Site traffic generated and transported between the Sites.

The statistics for volume, frequency, and direction of inter-Site replication traffic will change for the Sites connected by Site Link objects with this feature enabled. Where the network connection between these Sites has low available bandwidth and high utilisation, then the decision as to whether this network link will be able to handle unscheduled and frequent inter-Site replication will have to be determined. If the network link can not handle the predicted frequency of inter-Site replication traffic, then the following options are available:

Disable inter-Site change notification

Upgrade the network link to be able to support this frequent replication traffic

Install a dedicated network link for inter-Site replication traffic



Inter-Site change notification is enabled on a Site Link object using ADSI Edit to modify the “options” attribute of the “cn=IP” object within the “cn=Inter-Site Transports” object container, using the following process:

Where the value of the “options” attribute shows <not set>, then enter a value of “1” in the value field, and click OK

Where the value field already contains a value, then it is necessary to calculate a new value via a Boolean BITWISE-OR calculation on the old value, using the formula “<old_value> BITWISE-OR 2”. For example, if the value in the Value(s) field is “1”, then calculate “0001 OR 0010 to equal 0011”. Type the integer value of the result in the Integer Attribute Editor field, which for this example will be a value of “3”.

Factor A6: Determination of the requirements for the design of inter-Site change notification


Has identified the requirements for the design of one or more Site Link objects

Has not identified the requirements for the design and implementation of a strict hub-and-spoke Site Link topology (see figure 25.1 in the Site Plan process, “design of a Site Link topology”), and

Wishes to determine the requirements for the design and implementation of inter-Site change notification for one or more specific Site Link objects


When determining the requirements for the design and implementation of inter-Site change notification, this design methodology proposes the following approach:

Understand the requirements for inter-Site change notification, and the influence of inter-Site change notification on the volume and frequency of generation and transmission of Active Directory replication traffic.

Examine the results of the Site Plan process, “design of the Site Link topology”, and identify the following:

The Sites where the majority of inter-Site traffic is generated, transmitted, and received

The Sites where inter-Site replication traffic must cross:

Multiple Site Link objects

Multiple network links

The Sites where replication latency due to a long replication path (many Site Link and network link hops) is unacceptable

Define the criteria for the design and implementation of inter-Site change notification

Evaluate all appropriate Site Link objects against the defined criteria and determine the requirements to enable inter-Site change notification for specific Site Link objects



When defining the criteria for the design and implementation of inter-Site change notification, consider the following:

Although the onus is with the organisation to define their criteria for the design and implementation of this feature, this design methodology provides the following example criteria:

It is possible to identify that a Site Link object supports inter-Site replication between Sites within the Site Link, which has a low tolerance of replication latency.

It is possible to identify that the inter-Site replication path exceeds the threshold value for the number of hops across Site Link objects and network links.

The threshold value for the maximum number of hops across Site Link objects and network links is four hops

Enabling inter-Site change notification for one or more Site Link objects will not generate any unacceptable consequences to normal inter-Site replication between Sites. Remember that the enabling of inter-Site change notification effectively disables the replication schedule and interval for a Site Link object, and hence degrades the level of control over inter-Site replication.

The Site Link objects supports the RCP over IP transport protocol, and not SMTP over IP

It is not possible to identify that the cause of inter-Site replication latencies are due to the presence of non-permanent network links within the replication path.


Execute an analysis of all inter-Site replication and identify any requirements for the implementation of inter-Site change notification.

Where it is not possible to identify any requirements to enable inter-Site change notification, then proceed to the final step in this process to generate the design for the configuration of the Site Link objects.

Where it is possible to identify requirements to enable inter-Site change notification, then execute the following:

Identify all Site Link objects that support inter-Site replication sensitive to replication latencies

Define the criteria for the design and implementation of inter-Site change notification

Evaluate all identified Site Link objects against the defined criteria, and identify those Site Link objects where inter-Site change notification is required.

9.9.6. Generation of the Design for the Configuration of Site Link Objects

Consider the following when generating the design for the configuration of Site Link objects:

Factor D1: Generation of the design for the configuration of Site Link objects




Has evaluated the factors presented by this design methodology as been influential in the design for the configuration of Site Link objects,

Has completed all analyses to determine the design requirements for the configuration of all required Site Link objects, and

Wishes to generate the design for the configuration of all required Site Link objects for this Site infrastructure


This design methodology proposes execution of the following approach to generate the design for the configuration of Site Link objects for this Site infrastructure:

Generate the required formula to support the assignment of a description to all required Site Link objects

Use the cost value model to assign a cost value to each required Site Link object

Assign each Site Link object the required replication schedules and intervals

Configure the appropriate Site Link objects for reciprocal replication, where required

Configure the appropriate Site Link objects for inter-Site change notification, where required

When assigning cost values to Site Link objects, using the cost value model, consider the following:

This design methodology proposes execution of the following approach to assign the cost values to all required Site Link objects:

Calculate the baseline cost value for all Site Link objects to produce a first draft of the design of the cost values for the Site Link objects

Then assign the relevant priorities to the other applicable factors, for each Site Link, and use the formula to calculate the final cost values for the Site Link objects.

Document the results of the calculation, and verify that the calculated cost values support all inter-Site routing requirements

This design methodology proposes that the design for the configuration of the Site Link objects adopt the following format and content:

A design document detailing all of the requirements and considerations employed in the design for the configuration of the Site Link objects, highlighting the following:

The business and technical requirements that influenced the design for the description of the Site Link objects

The business and technical requirements that influenced the design for the cost value model, and the selection of the factors influential and applicable to the design for the cost values of the Site Link objects.



The business and technical requirements that influenced the design for the replication schedules and intervals for the Site Link objects

The business and technical requirements that influenced, where required, the design for the implementation of reciprocal replication on one or more Site Link objects

The business and technical requirements that influenced, where required, the design for the implementation of inter-Site change notification on one or more Site Link objects

The final (in diagrammatic format) design for the configuration of the Site Link objects, which depicts the following:

The predicted flow of inter-Site Active Directory replication traffic, identifying the source(s) of Active Directory replication traffic, and corresponding destination Sites, and Site Links used to support the flows.

The predicted re-directed flow of inter-Site Active Directory replication traffic, when one or more supporting network links suffer service outages

The replication schedules, intervals, and common replication windows for “inter-Site-Link” replication



10. Design of Site Link Bridge Objects

This process requires execution by all organisations planning the design and implementation of a multiple Site Active Directory forest, with three or more Sites, connected by two or more Site Link objects.


The objective of this process is to assist an organisation in the execution of the following:

Determination of the requirements for Site Link Bridge objects

Identification of the Sites that require connection via Site Link Bridge objects, and

Design for configuration and implementation of Site Link Bridge objects within this Site infrastructure.

It is important to note that this process to design Site Link Bridge objects is an iterative process that will require evaluation and re-evaluation of several drafts of a design to ensure compliance with all identified requirements for their implementation within the Active Directory Site infrastructure.


The objectives of Site Link Bridge objects are to represent a set of Site Link objects along a disconnected replication path within a Site Link topology.

By default, all Site Link objects are transitive. Hence, for example, if Site A is connected to Site B with Site Link “AB”, and Site B is connected to Site C with Site Link “BC”, then a domain controller in Site A can replicate (if required) with a domain controller in Site C via Site B. This inter-Site replication path will use both Site Links “AB” and “BC”, assuming of course that a common window for replication exists across both Site Link objects.

However, the default transitivity of Site Link objects hence assumes an underlying fully routed network infrastructure that connects the Sites as appropriate, and hence the assumption that a domain controller in any Site can communicate over IP with a domain controller in any other Site within the forest.

In reality, this may not be the case, and where the default transitivity of Site Link objects is disabled, there is a requirement for the use of Site Link Bridge objects within an Active Directory Site infrastructure. The following diagram illustrates the above example, where a Site Link Bridge object, “AB-BC”, connects two Site Link objects.

Site B

Site Link“BC”

Site Link“AB”

Site Link Bridge“AB-BC”

Site CSite A


Figure 27.1: Example of Site Link Bridge Object



Prior to determination of the requirements for the design and implementation of Site Link Bridge objects, this design methodology provides the following facts about Site Link Bridge objects:

A Site Link Bridge object must contain a minimum of two Site Link objects. Hence, as each Site Link object must support a minimum of two Sites, a prerequisite to the design and implementation of Site Link Bridge objects is that the Site infrastructure must support a minimum of three Sites.

A Site Link Bridge object can connect Site Link objects using both RPC over IP and SMTP over IP transport protocols. However, although a Site Link Bridge object can contain multiple Site Link objects all Site Link objects within each Site Link Bridge object must all share a common transport protocol (RPC over IP or SMTP over IP) and not mixtures of both transport protocols.

It is possible to associate a single Site Link object with multiple Site Link Bridge objects, but only of the same transport protocol.

The default bridging of Site Link objects is set at the transport protocol level. Hence, if this feature is disabled, it will directly affect all Site Link objects that use that transport protocol. It is not possible to disable the default bridging of Site Link objects at the Site Link object level.

If the default bridging of all Site Link objects for a transport protocol is disabled, then Site Link Bridge objects must be created to allow Site Link transitivity where required.

It is not possible to configure a Site Link Bridge object with a replication schedule, interval, and cost value parameter. These parameters are exclusive to the Site Link objects contained within the Site Link Bridge objects. Hence, for example, a Site Link Bridge object will have a cost value equivalent to the sum of the cost values for a set of Site Links along a particular replication path created by the Site Link objects.

The following diagram illustrates this, where routing replication traffic from a domain controller in Site A to a domain controller in Site D (using Site Link Bridge “AB-BC-CD”) would cost (5+3+4) = 12.

Site B

Site Link“AB”

Cost=5

Site C

Site A

Site D

Site Link“CD”

Cost=4

Site Link“BC”

Cost=3

Site Link Bridge“AB-BC-CD”


Figure 27.2: Example of the Accumulation of Cost Values by a Site Link Bridge Object



Each Site Link in a Site Link Bridge object must have at least one Site in common with another Site Link within the Site Link Bridge object. Without this prerequisite, the Site Link Bridge object will be unable to calculate the sum value for the cost to replicate from one Site, within a member Site Link object, to another Site within another member Site Link object of the Site Link Bridge object.

The following diagram illustrates this, where the creation of a Site Link Bridge object for the Site Link objects “AB” and “CD” is not supported because there is no connectivity between Sites A and C or D and between Sites B and C or D, or vice versa:

Site C Site D

Site Link“CD”

Site BSite A

Site Link“AB”

Site Link Bridge“AB-CD”


Figure 27.3: Example of Unsupported Site Link Bridge Creation

However, the following diagram illustrates a supported example, where it is possible to identify connectivity between the two groups of Sites, and hence the corresponding Site Link Bridge object is valid and supported:

Site C Site D

Site Link“CD”

Site BSite A

Site Link“AB”

Site Link Bridge“AB-CD-BD”

Site Link“BD”


Figure 27.4: Example of Supported Site Link Bridge Creation

Site Link Bridge objects themselves are not transitive and instead operate independently of each other regardless of the transport protocol.

The following diagram illustrates and example of this, where the presence of the Site Link Bridges “AB-BC” and “CD-BC” does not necessarily imply that an IP packet can be sent from a domain controller in Site A to a domain controller in Site D. If there was fully routed IP network infrastructure connecting Sites A, B, C and



D, then a single Site Link Bridge object (called, for example, “AB-BC-CD”) would allow communication between a domain controller in Site A and a domain controller in Site D.

Site B

Site Link“BC”

Site Link“AB”


Site C

Site A

Site D

Site Link“CD”

Site Link Bridge“CD-BC”


Figure 27.5: Example of the Non-Transitive Nature of Site Link Bridge Objects

All Site Links within a Site Link Bridge object can route transitively between them but cannot route outside of the Bridge.

The following diagram illustrates this, where the presence of Site Link “DE” (that is not a member of the Site Link Bridge “AB-BC-CD”) does not imply that a domain controller in Sites A, B or C can communicate with a domain controller in Site E:

Site B

Site Link“AB”

Site C

Site A

Site D

Site Link“CD”

Site E

Site Link“DE”

Site Link“BC”

Site Link Bridge“AB-BC-CD”




Figure 27.6: Example of Inter-Site-Link-Bridge Transitivity


This design methodology recommends the design and implementation of Site Link Bridge objects only where required to support specific business and technical requirements.

This design methodology proposes execution of the following approach to design Site Link Bridge objects for this Site infrastructure:

1. Determine the requirements for the design and implementation of Site Link Bridge objects

2. Where an organisation is able to identify the requirement for the design and implementation of one or more Site Link Bridge objects, identify the Site Link objects that require bridging.


The process to design Site Link Bridge objects is composed of the following two components:

Determination of the requirements to design and implement Site Link Bridge objects

Generation of a design for Site Link Bridge objects



Site Plan – Inter-Component Dependencies for Process to Design Site Link Bridge Objects

STARTGeneration of the

design for Site Link Bridge objects

Determination of the requirements for the design of Site Link

Bridge objects© 2 0 0 4 M U S T A N S H I R B H A R M A L


The process to design Site Link Bridge objects will have the following deliverables:

Determination for the requirement for Site Link Bridge objects

Determination of the number of Site Link Bridge objects required and the Sites that require bridging by Site Link Bridge objects

Generation of a design for the configuration and implementation of Site Link Bridge objects



10.7. Process to Design Site Link Bridge Objects

Site Plan – Process to Design Site Link Bridge Objects

STARTExecute

A1

Execute

B1 – B5 END

Execute

D1

Is there a requirement to design Site Link

Bridges?

NO

YES

Are there 3 or more Sites connected by 2

or more Site Link objects?

NO

YES



Consider the following information designing Site Link Bridge objects for an Active Directory Site infrastructure:

Factor B1: Understanding the approach towards the determination of the requirements for the design of Site Link Bridge objects


Has identified the requirements for the design and implementation of two or more Site Link objects

Has identified the requirements for the design and implementation of three or more Sites, and

Wishes to understand the approach towards the determination of the requirements for the design of Site Link Bridge objects


The design and implementation of Site Link Bridge objects is required to bridge Site Link objects that route inter-Site replication traffic across non-routed network infrastructures.

However, this design methodology also supports the design and implementation of Site Link Bridge objects to support the following requirements:

The requirements to control the flow of inter-Site replication traffic via Site Link Bridge objects

The requirements to reduce inter-Site replication latency via Site Link Bridge objects

The requirements to reduce the hardware resource utilisation of domain controllers within a Site hosting the ISTG role, via Site Link Bridge objects

This design methodology hence proposes execution of the following approach to determine the requirements for the design of Site Link Bridge objects:

Understand the factors that will influence the requirements for the design and implementation of Site Link Bridge objects

Define the criteria for the design and implementation of Site Link Bridge objects



Identify all factors applicable to the organisation, and evaluate against the defined criteria, and hence determine the requirements for the design and implementation of Site Link Bridge objects

Factor B2: Understanding the influence of the presence of a non-routed IP network infrastructure, on the determination of the requirements for the design and implementation of Site Link bridge objects


Has a multiple Site (three or more Sites) infrastructure connected by a network infrastructure that is not fully Internet Protocol (IP) routed, and

Wishes to understand the influence of the presence of a non-routed IP network infrastructure on the determination of the requirements for the design and implementation of Site Link bridge objects


As stated earlier, within the background information section of this process, Site Link objects assume the underlying network infrastructure provides full support for IP routing between each logical Site and the domain controllers within each Site.

However, within some organisations, the entire network infrastructure may not be fully IP routed, and hence it may be possible to identify domain controllers:

Distributed among Sites not directly connected to each other via Site Link objects, and

Supported by a network infrastructure that is not fully IP routed

In these scenarios, it is necessary to bridge the Site Link objects that connect the Sites, and hence the domain controllers, via a Site Link Bridge object.

Factor B3: Understanding the influence of the requirement to reduce inter-Site replication latency, on the determination of the requirements for the design and implementation of Site Link bridge objects


Has identified two or more Sites that require regular inter-Site replication as they, for example, share common naming contexts, and

Wishes to understand the influence of the requirement to reduce inter-Site replication latency on the determination of the requirements for the design and implementation of Site Link bridge objects


Where two or more Active Directory Sites support domain controllers from the same domain, then inter-Site replication is essential to ensure all remote domain controllers have an up-to-date copy of the Active Directory database for their domain.

The presence of replication latencies between these domain controllers, for inter-Site Active Directory replication, can lead to database divergence, and may temporarily disrupt user and business continuity.



In this scenario, the design and implementation of Site Link Bridge objects can:

Reduce inter-Site replication latency

Increase redundancy

Decrease the volume of inter-Site replication traffic, and

Reduce workload and hence increase performance on intermediate Sites.

This is illustrated in the following example where a domain controller in Site A (DC1.AD.com) wishes to replicate with a domain controller in Site C (DC2.AD.com.)

A Site Link Bridge object can allow the KCC process to create a connection object between Sites that share a common naming context, but not a common Site Link object.

In the illustrated example below, without the presence of the Site Link Bridge object (“AB-BC”), when DC1 wishes to replicate with DC2, it must do so via Site B using a “store and forward” process where Site B will receive and store the replication data from Site A and then forward it to Site C (and vice versa).

However, this hence increases the replication latency between Sites A and C and increases the workload on Site B. However, this process does ensure the less frequent generation of network traffic, even though there is a modest increase in volume of traffic that requires transmission between the Sites.

The introduction of the Site Link Bridge “AB-BC” allows the KCC process on DC1 and DC2 in Sites A and C respectively to create (direct) connection objects between these domain controllers. This hence allows direct communication between these two domain controllers, thus bypassing Site B, reducing inter-Site replication latency, and increasing redundancy.

There is an increase in redundancy via negation of the reliance on the domain controller(s) in Site B to perform “store and forward” operations on inter-Site replication data for Sites A and C. Note that this scenario will also results in an associated reduction in the workload on Site B domain controllers.

The new connection object between DC1 and DC2 may also support the replication of changes to the Schema and Configuration partitions for the forest between Sites A and C.



Site Link“BC”

Site Link“AB”


Connection Object

Site C

DC2.root.com

Site A

DC1.root.com

Site B

DC1.ChildA.Root.com


Figure 27.7: Example of Use of Site Link Bridge Object to Reduce Inter-Site Replication Latency

Factor B4: Understanding the influence of the requirement to control the flow of inter-Site replication traffic, on the determination of the requirements for the design and implementation of Site Link bridge objects


Has identified the requirement to control the flow of replication traffic between domain controllers in different Sites, and

Wishes to understand the influence of this requirement on the design and implementation of Site Link bridge objects


It is possible to use Site Link Bridge objects to prevent the routing of inter-Site Active Directory replication traffic to Sites connected by Site Link objects not associated with the Site Link Bridge.

The background information section of this process discussed the non-transitive nature of Site Link Bridge objects.

Where it is possible for an organisation to identify the requirements to control the flow of replication traffic between domain controllers within different Sites, consider use of the non-transitivity feature of Site Link Bridge objects.

Factor B5: Understanding the influence of the requirement to control ISTG performance, on the determination of the requirements for the design and implementation of Site Link bridge objects




Has identified the requirements to reduce the CPU activity on bridgehead domain controllers within Sites associated with the KCC process developing the inter-Site replication topology, and

Wishes to understand the influence of this requirement on the design and implementation of Site Link bridge objects


Within a Site infrastructure supporting many Sites and Site Link objects, the automatic bridging of Site Link objects generates multiple paths for inter-Site replication. The KCC process on each bridgehead server within each Site is required to calculate all potential inter-Site replication paths, using the spanning tree algorithm.

The higher the number of Sites and Site Link objects, the greater the time and hardware resource (CPU and memory) utilisation by the KCC process. In large Site infrastructures, this can generate significant performance degradations to the bridgehead servers.

The use of Site Link Bridge objects may alleviates these scenarios, due to the non-transitive nature of Site Link Bridge objects, and hence the presence of fewer potential paths for inter-Site replication.

Factor A1: Definition of the criteria to qualify requirements to design and implement Site Link Bridge objects


Has evaluated and understood the factors influential in the determination of the requirements for the design of Site Link Bridge objects, and

Wishes to define the criteria to qualify any requirements to design and implement Site Link Bridge objects, and

Wishes to evaluate all applicable factors against the defined criteria to determine the requirements for the design and implementation of Site Link Bridge objects within this Site infrastructure


In order to qualify any requirements for the design and implementation of Site Link Bridge objects, this design methodology requires the definition of criteria.

When defining the criteria to qualify such requirements, although the onus is with the organisation to define their criteria, this design methodology provides the following example criteria:

It is possible to identify the presence of three or more Active Directory Sites within this Site infrastructure

It is possible to identify the following:

The presence of either a supporting network infrastructure for the Active Directory forest that is not fully IP routed, and / or

The following requirements:



The requirements to control the flow of inter-Site replication traffic via Site Link Bridge objects

The requirements to reduce inter-Site replication latency via Site Link Bridge objects

The requirements to reduce the hardware resource utilisation of domain controllers within a Site hosting the ISTG role, via Site Link Bridge objects

The design and implementation of one or more Site Link Bridge objects will not generate any unacceptable consequences, such as disruptions to inter-Site replication, and routing of inter-Site Active Directory replication traffic, and so on.

Using the above information, define and document the criteria to qualify the requirements for the design and implementation of one or more Site Link Bridge objects within this Site infrastructure.

When determining the requirements for the design and implementation of one or more Site Link Bridge objects, execute the following:

Evaluate all factors influential in the determination of the requirements for Site Link Bridge objects, and identify all factors applicable to the organisation.

Evaluate all applicable factors against the defined criteria, and hence qualify the requirements to design and implement Site Link Bridge objects

Determine the number of Site Link Bridge objects required, and the Site Link objects that require bridging.

Factor D1: Generation of the design for Site Link bridge objects


Has determined the requirements to design and implement Site Link Bridge objects, and

Wishes to generate the design for Site Link Bridge objects within this Site infrastructure


This design methodology proposes that the design for Site Link Bridge objects adopt the following format and content:

A detailed design document, identifying the following:

The details of the factors, influential in the determination of the requirements for Site Link Bridge objects, which are applicable to the organisation

The details of the Site Link objects that require bridging

Use the considerations provided within the Site Plan process, “design for the configuration of the Site Link objects”, to determine the required description entries for each required Site Link Bridge object

A diagram illustrating the following:



The Sites within each Site Link object

The Site Link Bridge objects that will bridge two or more Site Link objects

The flow of inter-Site replication traffic before and after implementation of the Site Link Bridge objects



11. Design for Custom Connection Objects

This process requires execution by all organisations planning the design and implementation of a multiple Site Active Directory forest.


The objectives of this process are to assist an organisation in the execution of the following:

Determination of the requirements to modify automatically generated connection objects

Determination of the requirements to create new custom connection objects


The KCC process on domain controllers within Site automatically creates connection objects. The algorithm employed by the KCC process will create a low latency replication topology that is resistant and automatically adaptable to permanent and temporary failures within the replication topology. If left alone, the KCC process requires no maintenance or modification.

However, it is possible for an administrator to create new custom connection objects or customise existing connection objects, created by the KCC process.

Prior to the execution of this process, to determine the requirements for the design of custom connection objects, it is important to acknowledge and understand the following facts about connection objects:

A connection object represents a unidirectional (pull) connection between two domain controllers to support the transmission of Active Directory replication changes between them. For bidirectional replication, two connection objects require creation, in opposite directions.

A connection object will replicate all naming contexts, held by the source domain controller, and receivable by the destination domain controller.

A connection object exists as a child of the replication destinations NTDS Settings object and identifies the following information:

The replication source domain controller

The Site that hosts the source domain controller

A replication schedule

A replication transport protocol

The naming contexts fully and partially replicated by the connection object

The replication schedule for KCC-generated inter-Site connection objects derive automatically from the relevant Site Link object.

A connection object supports both intra-Site and inter-Site replication, depending on the location of the source domain controller.

It is possible to disable the automatic generation of either or both intra-Site and inter-Site connection objects by the KCC process. This option is configurable only at the Site level via a modification of the “options” attribute for the NTDS Settings object.



This design methodology defines a “custom” connection object as one the KCC no longer owns or manages. It is possible to create a custom connection object via the manual modification of a KCC-generated connection object, or the creation of a new connection object.

The KCC process owns all connection objects it creates, and hence this process manages all subsequent tasks associated with these objects, such as their modification and deletion.

It is important not to underestimate the consequences of the manual modification of a KCC-generated connection object, to create a custom connection object. Manual modification of a KCC-generated connection object transfers ownership of that object away from the KCC process, and hence this object will require continual manual management. It is thus necessary to consider the administrative overheads associated with this action, and the alternatives (where applicable) to the modification of a KCC-generated connection object / creation of a new connection object.

Note that the change in ownership is a one-way and virtual transference away from the KCC-process, and not a component of the security descriptor for the object. All KCC-generated connection objects are, by default, owned by the Domain Admins group.

Note that the KCC process will use, wherever applicable, connection objects that it does not own in the determination of the replication paths between domain controllers in the forest.

Note that a manually created connection object configured for inter-Site replication does not inherit the replication schedule and interval from a relevant Site Link object. It instead uses the default schedule and interval, which hence requires manual configuration by an administrator.

The default replication schedule and interval for a manually created connection object is to allow replication to occur four times per hour, every hour, and every day.

It is only possible to disable the replication schedules for manually created connection objects, and not KCC-generated objects.

It is possible to execute the following modifications to a KCC-generated connection object:

It is possible to modify the name of a KCC-generated connection object, from the user-friendly (in GUI) name of “<automatically generated>”, to a custom name.

It is possible to modify the description of the connection object. By default, all KCC-generated connection objects have an unpopulated description field.

It is possible to modify the schedule for replication for the connection object.

It is possible to modify the transport protocol used by the connection object. When modifying the transport protocol, note the following:

If the connection object is to support intra-Site replication, then it is necessary to leave the transport protocol as “RPC”.

If the connection object is to support inter-Site replication, then it is possible to modify the transport protocol to either “IP” (RPC over IP) or “SMTP” (SMTP over IP.) Note that an accompanying Site Link object, with the corresponding transport protocol, must support all modifications to the transport protocol for a connection object to support inter-Site replication.



It is possible to modify the source domain controller for the connection object. Changing this parameter can change the function and purpose of the connection object if the new domain controller is not within the same Site as the current domain controller or configured as a GC server when the original domain controller was a GC server. This change may hence also change the naming contexts replicated to the domain controller that owns the modified connection object.

Note that as soon as any of the above modifications are made, and an attempt to apply these changes is made, the following dialog box will appear:

Figure 28.1: Dialog Box Presented upon Modification of Automatically Generated Connection Object

Once the connection object is marked as not automatically generated, then the following events take place:

The modification is applied

The ownership of the connection object changes so that KCC will now no longer manage this connection object

The name of the connection object (if not changed within the modification) changes to a non-user friendly GUID, such as “d31ba3e4-240c-4f32-928b-acbb506bf9c4”, instead of “<automatically generated>”.


When executing this process, this design methodology recommends organisations keep it simple, which implies the minimal creation of custom connection objects.

To support this recommendation, this design methodology states the following null hypothesis for this process:

“The automatic generation and management of intra- and inter-Site connection objects by the KCC process can adequately meet all the replication and service provision requirements for the forest and the organisation without the need to customise existing connection objects, or manually create new connection objects”.

Following the statement of this null hypothesis, it is then necessary to execute investigations to disprove this null hypothesis and hence determine whether custom connection objects are required for the forest.

Where it is possible to disprove this null hypothesis, it is then necessary to execute an analysis to determine where, within this Site infrastructure, custom connection objects will be required.

To support the above recommendations and null hypothesis, this design methodology proposes execution of the following approach for this process:

1. Determine the requirements for the generation of custom connection objects within this Site infrastructure

2. Where it is possible to identify the requirements for the generation of one or more custom connection objects, execute the following:



a. Determine the design requirements for the manual modification of KCC-generated connection objects

b. Determine the design requirements for the creation of new custom connection objects

c. Generate the design for custom connection objects


The process to design custom connection objects is composed of the following four components:

Determination of the requirements for the design of custom connection objects within this Site infrastructure

Determination of the design requirements for the modification of KCC-generated custom connection objects

Determination of the design requirements for the creation of new custom connection objects

Generation of the design for custom connection objects



Site Plan – Inter-Component Dependencies for Process to Design Custom Connection Objects

START

Determination of the requirements for the

design of custom connection objects

Generation of the design for custom connection objects


the modification of KCC-generated

connection objects


the creation of new custom connection

objects© 2 0 0 4 M U S T A N S H I R B H A R M A L


The process to design custom connection objects for a forest will have the following deliverables:

The determination of the requirement for the customisation of connection objects automatically created by the Knowledge Consistency Checker (KCC) process and the identification of the connection objects to be modified

The determination of the requirement for the creation of new connection objects and the domain controllers that will be connected together using the new connection objects

The design for the customisation of connection objects automatically created by the Knowledge Consistency Checker (KCC) process

The design for manually created connection objects



11.7. Process to Design Custom Connection Objects

Site Plan – Process to Design Custom Connection Objects

STARTExecute

A1

Execute

B1 END

Execute

D1

Is there a requirement for the manual

customisation of a KCC-generated

connection object?

NOYES

Execute

A2

Execute

D2

Is there a requirement for the manual

creation of a new connection

object?

NO

YES



Consider the following information when executing the process to design custom connection objects:

Factor B1: Understanding the approach towards the determination of the requirements for the design of custom connection objects

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the approach towards the determination of the requirements for the design of custom connection objects


As discussed in the background information section for this process, it is possible to create a custom connection object via execution of either of the following actions:

Manual modification of one or more attributes of a KCC-generated connection object

Creation of a new custom connection object

This design methodology hence proposes the following approach to determine the requirements for the creation of custom connection objects:

Determine the requirements to modify one or more aspects of one or more KCC-generated connection objects

Determine the requirements to create one or more new custom connection objects

Factor A1: Determination of the requirements to modify KCC-generated connection objects

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the modification of one or more KCC-generated connection objects.




This design methodology regards the execution of any manual modifications to KCC-generated connection objects as advanced fine-tuning of intra- and inter-Site replication, and hence only requires execution where it is possible to identify justifiable business or technical requirements.

The consequences of the removal of a KCC-generated connection object from the scope of management of the KCC process require consideration prior to execution of the decision to implement a modification.

When determining the requirements to modify a KCC-generated connection object, consider the following:

Of all the parameters of a KCC-generated connection object that supports modification, this design methodology considers modification of the replication schedule as the only justifiable modification.

The design methodology provides the following examples of requirements for the manual modification of the replication schedule for a KCC-generated connection object:

An organisation may wish to modify the replication schedule, for an inter-Site connection object, to create a common inter-Site replication window. For example, an organisation can identify two domain controllers separated by multiple Site Link objects that, combined, present either a very short duration for a replication window or none at all. Note that it is important to assess the impact on the intermediate network connections of replication traffic generated and transmitted during this new replication window, prior to the implementation of this modification.

An organisation may wish to modify the replication schedule for a KCC-generated connection object, to reduce the size of the replication periods for the connection object. For example, an organisation may wish to reduce the duration of a replication window because:

There is a requirement to limit the impact on bandwidth availability of the current schedule for inter-Site network traffic, or

The duration of the replication periods for the connection object exceeds the volume and /or frequency of generation of inter-Site replication traffic that is actually transmitted between the domain controllers

As stated in the background information section of this process, in addition to the replication schedule for a connection object, it is also possible to modify the following attributes of a connection object:

The transport protocol

The source domain controller for the connection object

The name and / or description of the connection object

However, although the execution of any modifications to these attributes will generate a custom connection object, this design methodology considers any requirements for the modification of these attributes as unjustifiable. This is explained below:

Modification of the transport protocol for a KCC-generated connection object is unjustified because of the following facts:

A connection object will only use one of the following three transport protocols:



IP

RPC over IP

SMTP over IP

Note that “IP” and “RPC over IP” are the same protocol, but “IP” denotes an intra-Site replication protocol and “RPC over IP” denotes an inter-Site replication transport protocol.

The potential modifications to the transport protocol for a connection object are as follows:

Change to alternate inter-Site transport protocol:

1. Change from SMPT over IP to RPC over IP

2. Change from RPC over IP to SMPT over IP

Change from inter-Site to intra-Site transport protocol:

1. Change from RPC over IP to IP

2. Change from SMPT over IP to IP

Change from intra-Site to inter-Site transport protocol:

1. Change from IP to RPC over IP

2. Change from IP to SMPT over IP

The change to an alternate inter-Site transport protocols is better achieved (where not already present) via the creation of a new / use of an existing Site Link object of that transport protocol rather than modification of a connection object.

The change from an inter-Site to an intra-Site transport protocol implies either of the following:

The moving of the source domain controller from a remote Site to the local Site for the domain controller that owns the connection object to be modified, or

The change of the status of the domain controller that owns this connection object from been a bridgehead server to a normal domain controller and replication now with a different local domain controller.

Regardless of these changes, KCC will detect them and automatically adjust the connection objects to comply with the changes.

The change from an intra-Site to an inter-Site transport protocol is the same as above, but in the opposite direction. Again, KCC will detect the changes that will influence the operation of current connection objects it has created and apply the modifications as appropriate.

As there are alternatives to the possible reasons for the modification of the transport protocol for a connection object, it is not justifiable to implement such changes.

Modification of the source domain controller for the KCC-generated connection object is unjustified because of the following fact:



This change is similar to the changes from inter-Site to intra-Site (and vice versa) transport protocols, as described in the previous point. However, KCC will detect changes where appropriate and modify connection objects to comply with the changes. Hence, it is not justifiable to implement a change to the source domain controller for a connection object.

Modification to the name and / or description of the connection object is unjustified because of the following fact:

Although these fields are customisable, the consequences of the changes (the connection object will fall out of the scope of management of the KCC process) outweigh the potential benefits from these changes and hence these changes are not justifiable.


Determine the requirements to modify the replication schedules for one o or more KCC-generated connection objects to support the following requirements:

The requirements to create a common replication window for “inter-Site-Link” Active Directory replication

The requirements to modify the duration of any replication windows for inter-Site replication, to limit the impact of inter-Site replication

Where it is possible to identify such requirements, then execute the following:

Identify the KCC-generated connection objects that require modification

Document the details of the KCC-generated connection objects that require modification

Factor A2: Determination of the requirements to manually create new connection objects

Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements to create new custom connection objects.


The KCC process is capable of creating a fault tolerant, efficient, and adaptable replication topology using connection objects. Hence, this design methodology supports only one requirement for the creation of a new custom connection object, which is to reduce intra-Site replication latency.

However, Windows Server 2003 Active Directory has a different default replication schedule for intra-Site replication to Windows 2000 Active Directory. In Windows 2000 Active Directory, intra-Site replication initiates at 300 seconds (5 minutes) with an offset of 30 seconds, expressed as 300/30. Hence, the first committed change a Windows 2000 domain controller receives, after completion of an intra-Site replication will cause the domain controller to wait for five minutes before initiating another intra-Site replication with its replication partners, with a 30 second offset between partners. In Windows Server 2003 Active Directory, intra-Site replication initiates by default at 15 seconds, with an offset of 3 seconds, expressed as 15/3.



Note that all Windows 2000 domain controllers, and Windows Server 2003 domain controllers upgraded from Windows 2000 domain controllers, within a Windows Server 2003 Active Directory forest, will continue to use the default 300/30 intra-Site replication frequency setting. Only newly installed Windows Server 2003 domain controllers will use the 15/3 intra-Site replication frequency setting. All upgraded Windows Server 2003 domain controllers will only switch to the 15/3 intra-Site replication frequency setting when the forest functional level is raised to “Windows Server 2003”.

Hence, this design methodology only supports the creation of custom connection objects to reduce intra-Site replication latency where it is possible to identify compliance with the following criteria:

The forest is currently operating at a functional level below “Windows Server 2003”

It is possible to identify Sites supporting two or more Windows 2000 domain controllers, or Windows Server 2003 domain controllers upgraded from Windows 2000 domain controllers

Within these identified Sites, the identified Windows 2000 / upgraded Windows Server 2003 domain controllers share the same naming contexts and are three hops apart

Consider the following where it is possible to identify compliance with the above criteria:

When the KCC process generates connection objects within a Site, it creates, by default, a bidirectional ring that ensures that all domain controllers within a Site are no more than three replication hops apart. Hence, the maximum latency between domain controllers is three hops apart, which (in this scenario) is 3 x 5 minutes.

The manual creation of new connection objects for inter-Site replication to counter failures in remote domain controllers is not justifiable as a permanent solution since there is a viable alternative, which is to allow the KCC process to adapt to this change. In addition, raising the forest functional level to “Windows Server 2003” will virtually eliminate intra-Site replication latency.

Although the KCC process may be slower than the reactive approach from an administrator, unless it is possible to identify any urgent requirements for the implementation of a new connection object for this scenario, this design methodology recommends permitting the KCC process to handle the change. The long-term benefits of this option will outweigh the short-term benefits of a manually created connection object.

Using the above information, execute an analysis to determine the requirements to create a new custom connection object, as a short-term solution to reduce intra-Site replication latency.

Factor D1: Generation of the design for the manual customisation of one or more KCC-generated connection objects


Has identified the requirements for the manual customisation of one or more KCC-generated connection objects, and

Wishes to generate the design for the required customisations to the KCC-generated connection object(s)




As stated earlier, this design methodology only supports modification of the replication schedule and interval for a KCC-generated connection object.

When generating the design for the customisation to the replication schedule and interval for the KCC-generated connection object, remember that all connection objects derive their replication schedules and interval from the appropriate Site Link objects.

Hence, this design methodology recommends consultation of the factors and their considerations presented within the Site Plan process, “design for the configuration of Site Link objects”, for details of the design of the required replication schedules and intervals.

This design methodology proposes that the design for the customisation of a KCC-generated connection object adopt the following format and content:

A detailed description of the KCC-generated connection object(s) that require manual customisation, and all attributes of these objects

A detailed description of the business and technical requirements for the manual customisation of the KCC-generated connection objects

The details of the required customisations, such as the replication schedule and intervals, for each KCC-generated connection object.

Factor D2: Generation of the design for new, manually created, connection objects


Has identified the requirements for the manual creation of one or more new connection objects within the Active Directory Site infrastructure, and

Wishes to generate the design for the new connection object(s)


Where an organisation has identified the requirements for the creation of one or more custom connection objects, then this design methodology proposes that the design for the new connection objects adopt the following format and content:

For each new connection object that requires creation, it is necessary to design the following information:

The domain controller that will receive replication traffic across the new connection object

The name of the source domain controller for each connection object

The required transport protocol for the connection object(s). This information is determined via:

The location of the source domain controller (within the same Site as the destination domain controller or within a remote Site) and

The presence and transport protocol of the Site Link object that will be the first Site Link from the local Site in the inter-Site replication



path to the destination Site, should the source domain controller be located within a remote Site

The name of the connection object (mandatory information to be provided upon creation of the connection object) (see the Organisation-Wide Active Directory Plan process, “design of object naming models” for details of the custom connection object names).

The description of the connection object (optional information to facilitate identification and troubleshooting)

The required replication schedule and interval (default is four times per hour, every hour, and every day)

The design for the new connection objects should reflect the following information:

The details of the business and technical requirements that support the creation of each required custom connection object

A diagram illustrating the function / role of the new custom connection object(s) within the Site infrastructure, and within intra-Site and inter-Site replication pathways.



12. Design of Replication Topologies for ADPs

As discussed in the Forest Plan, application directory partitions (ADPs) are unique partitions within Windows Server 2003 Active Directory, as they support the design of unique replication topologies.

This process requires execution by all organisations that have identified the requirements for the design and deployment of one or more custom ADPs.

12.1. Process Objective

The objective of this process is to assist an organisation in the design of the replication topology for each required custom ADP, within the Windows Server 2003 Active Directory forest for this Site infrastructure.


Within a Windows Server 2003 Active Directory forest, Active Directory only provides support for the ability to control the path replication takes between domain controllers, for the default directory partitions (such as the Schema, Configuration, and Domain(s)), and the replication intervals and schedules for the replication. However, Active Directory does not provide control over which domain controllers may host replicas of a naming context. For example, all domain controllers within a forest are required to host replicas of the Configuration and Schema naming contexts, and all domain controllers within a domain, that domain’s naming context. Note that for the default DNS ADPs, Active Directory does support limited control over the target domain controllers for these naming contexts.

When designing the replication topology for application directory partitions, the opposite is true, where Active Directory permits control over the selection of the domain controllers that will host replicas of this partition, but the KCC process is required to automatically generate and manage the replication topology for all application directory partitions.

The requirements for the replication of an application directory partition to one or more other domain controllers within a forest are primarily to ensure accessibility (to the ADP from applications / services that will use the data stored within the ADP), availability, or fault-tolerance of the data held within the ADP.

These are hence the primary drivers for the design of the replication topologies for application directory partitions.

The following facts, relevant to the design of replication topologies for application directory partitions, require consideration prior to the design for the replication topologies for custom ADPs:

Only Windows Server 2003 domain controllers can host replicas of custom ADPs

It is possible to replicate objects stored in a custom ADP to Windows Server 2003 domain controllers configured as Global Catalog servers, but they will not appear within the Global Catalog, and correspondingly, will not appear in the results of any queries to LDAP port 3268 on a GC server.

The boundary for a custom ADP replication topology is the forest. It is not possible to replicate a custom ADP to a Windows Server 2003 domain controller within another forest to the original source domain controller.

A custom ADP can hold any type of object except security principal objects (such as security groups, user and computer accounts and so on).



By default, only members of the Enterprise Administrators group of the forest root domain can create and delete application directory partitions. This function can, however, be delegated to user accounts that are not members of this group.

See the Forest Plan process “Design of Custom ADPs” for more details.


The design of a replication topology for a custom ADP is essentially restricted to the following two steps:

1. Selection of potential host Windows Server 2003 domain controller, and

2. Addition of that host to the replica set for the custom ADP

There are no requirements to design Sites, Site Link objects, custom connection objects, and so on, for an ADP replication topology. Custom ADP replication uses the supporting Site infrastructure for the forest to replicate data changes between host Windows Server 2003 domain controllers.

However, the process to select the host domain controllers requires consideration of several influential factors. Hence, this design methodology proposes the following approach for execution of this process:

1. Identify the custom ADPs that require replication to one or more additional Windows Server 2003 domain controllers within the forest

2. Understand the factors that will influence the selection of a host domain controller for each required custom ADP, and identify potential host domain controllers

3. Define the criteria for the selection of a host domain controller, and evaluate all potential host domain controllers against the defined criteria

4. Execute the process to add the identified domain controllers to the replica set of the appropriate custom ADPs


The process to design replication topologies for application directory partitions is composed of the following four components:

Identification of the custom ADPs that require a replication topology

Understanding the factors that will influence selection of a host domain controller, and selection of potential host domain controllers

Definition of criteria for selection of host domain controllers, and evaluation of potential hosts against defined criteria

Generation of the design for the ADP replication topology


The process to design replication topologies for application directory partitions will have the following deliverables:

The identification of the custom ADPs that require the design of a custom ADP replication topology

The identification of the Windows Server 2003 domain controllers to host replicas of one or more custom ADPs within the forest

The definition of criteria to qualify the selection of one or more host Windows Server 2003 domain controllers for each in-scope custom ADP



The generation of a design of a replication topology for each in-scope custom ADP



Site Plan – Inter-Component Dependencies for Process to Design Replication Topologies for ADPs

START

Identification of the custom ADPs that require replication

topologies© 2 0 0 4 M U S T A N S H I R B H A R M A L

Understanding factors influential in selection of host domain controllers

Definition of the criteria to qualify selection of

host domain controllers

Generation of the design for custom ADP replication topologies

12.7. Process to Design Replication Topologies for ADPs

Site Plan – Process to Design Replication Topologies for ADPs

START ENDExecute

D1

Execute

A1

Execute

B1 – B7

Is there a requirement

for the design of a replication

topology for a custom ADP?

YES

NO

Execute

A2



Consider the following information when designing the replication topologies for custom ADPs:

Factor A1: Identification of the custom ADPs that require the design and implementation of a replication topology


Has identified the requirement for the design and deployment of one or more custom ADPs within the Active Directory forest, and

Wishes to identify the custom ADPs that require the design of a replication topology


It is important to note that not all custom ADPs, which require design and implementation within a Windows Server 2003 Active Directory forest, also require replication to two or more Windows Server 2003 domain controllers within the forest.

However, some custom ADPs may require the design and implementation of a replication topology. When determining the requirements for the design of a replication topology for a custom ADP, consider the following:

This design methodology proposes execution of the following approach to determine the requirements for the design of a replication topology for a custom ADP:

Select one of the required custom ADPs, and determine the following information:



The nature of the data the custom ADP is to store and the requirements to ensure the availability of the custom ADP and its data

The types of client the custom ADP will support, based upon the nature of the data, and their logical and physical distribution within the organisation / external to the organisation

Define criteria to qualify the requirements for the design of a replication topology for the custom ADP

Evaluate the custom ADP against the defined criteria and determine the requirements for the design of a replication topology

Repeat this process for each required custom ADP

When determining the influence of the nature of the data a custom ADP is required to store, on the requirements to design a replication topology, consider the following:

Custom ADPs can store dynamic data (within dynamic objects), and other application / service configuration and production data. Where the data stored within a custom ADP is critical to the normal operation of one or more business processes, it is important to ensure the distribution of the custom ADP to two or more Windows Server 2003 domain controllers. This strategy will prevent any single-point-of-failure (SPOF) contingencies, such as the failure of a single host domain controller, from disrupting business continuity.

Note that the nature of the data held within a custom ADP may also prevent its compliance with criteria to support replication to two or more domain controllers. For example:

Where the data held within a custom ADP is extremely dynamic, and hence volatile, the replication of this data to two or more domain controllers may be pointless, as the data may be invalid before its reception by the target domain controller.

Where the data held within a custom ADP is extremely large (number of objects / data size per object), then this may influence its compliance with criteria to support replication to two or more domain controllers. A custom ADP holding many hundreds of thousands of objects, and a database footprint of many hundred of megabytes or even gigabytes, may experience significant levels of directory divergence, even for intra-Site replication. The I/O overheads on the host domain controllers, to support the replication of (for example) changes to 10-15% of the custom ADP data, also may be significant to disrupt the performance of their routine functions or roles.

Where the data held within a custom ADP is extremely sensitive in nature, and requires careful access control, this may influence compliance with criteria to support replication to two or more domain controllers. For example, where a potential host domain controller is not physically or network secured, this creates exposure to the risk of data compromise.

When determining the influence of the nature of the clients of a custom ADP, on the requirements to design a replication topology, consider the following:

The clients of a custom ADP may be users, applications, services, or automated processes.



The following metadata aspects for clients of a custom ADP will influence the requirements for the design of a replication topology for the ADP:

The logical and physical location and distribution of the clients within the organisation

The presence of clients of a custom ADP residing outside the boundaries of the forest

The presence of clients of a custom ADP residing outside the boundaries of the organisation

Where a large number of clients for an ADP may have to cross one or more WAN links to reach a domain controller hosting the ADP, then this may generate a significant impact on the levels of available bandwidth within the appropriate links. The replication of a custom ADP to a Windows Server 2003 domain controller in close network proximity to these clients may alleviate this unacceptable impact on the supporting network links.

Where one or more firewall implementations exist between clients of a custom ADP and a host Windows Server 2003 domain controller of the custom ADP, then this may restrict their ability to access the data. For example, if the firewall blocks TCP port 389, then the clients may be unable to query the ADP using this port.

When defining the criteria to qualify the requirements for the design of a replication topology for the custom ADP, consider the following:

Although the onus is with the organisation to define their criteria to qualify the requirements to replicate a custom ADP, this design methodology provides the following examples of criteria:

The custom ADP supports valuable data associated with one or more key business processes, and the failure to replicate the custom ADP may increase the probability of a contingency event that disrupts business continuity.

The replication of a custom ADP to one or more domain controllers will not compromise the security of the data

The replication of a custom ADP to one or more domain controllers will not degrade the performance of the host domain controllers due to the size or the frequency of change of the data within the ADP

The replication of a custom ADP is required to support remote clients of the ADP and alleviate any impact of client access to data in the ADP on the supporting network infrastructure.


Determine the requirements for the replication of one or more custom ADPs

Define the criteria to qualify these requirements, and evaluate the requirements against defined criteria

Identify and document the requirements for the design of a replication topology for each in-scope custom ADP

Factor B1: Understanding the factors influential in the selection of a Windows Server 2003 domain controller to host a replica of a custom ADP




Has identified the requirement for the design and deployment of one or more custom ADPs within the Active Directory forest that requires replication to one or more Windows Server 2003 domain controllers within the forest, and

Wishes to understand the factors influential in the selection of the Windows Server 2003 domain controllers to host replicas of the custom ADPs


When selecting the host Windows Server 2003 domain controllers for each required custom ADP, this design methodology proposes consideration of the following factors influential in the selection process:

The network access requirements for the clients, applications, and services that require access to the data managed within a custom ADP

The requirements for client authentication and authorisation to access the data stored within a custom ADP

The protocol access requirements of the client, application, or service

The characteristics of the supporting network infrastructure, such as available bandwidth, latency and so on, and the volatility and sensitivity to latency of the data stored within a custom ADP. These parameters will influence the selection of replication partners with respect to their geographical distribution within the organisation.

For the domain controller selected to host a replica of a custom ADP, the number of peer domain controllers for its domain and the volume and frequency of changes that will be generated within that domain / Site.

The hardware specifications of the domain controller selected to host a replica of the ADP.

It is important to note that the following factors should not influence the selection of a Windows Server 2003 domain controller to host a replica of a custom ADP:

Objects stored within a custom ADP do not, by default, replicate to the Global Catalog even if a GC server hosts a replica of a custom ADP.

A custom ADP uses the Active Directory Schema for the forest to generate child objects, and it does not generate or maintain a discrete Schema. Hence, it is possible to replicate a custom ADP to any Windows Server 2003 domain controller within the same forest as the source domain controller.

Factor B2: Understanding the influence of the requirements for fault-tolerance and accessibility to the data held within a custom ADP, on the selection of a host Windows Server 2003 domain controller


Has identified the requirement for the design and deployment of one or more custom ADPs, with a replication topology, within the Active Directory forest, and



Wishes to understand the influence of the requirements for fault-tolerance and accessibility to the data held within a custom ADP, on the selection of a host Windows Server 2003 domain controller


It is important to consider requirements for fault-tolerance and accessibility to data held within a custom ADP, during the process to select host domain controllers. Where a custom ADP will host mission-critical data, any instances of domain controller failure may disrupt business continuity, directly or indirectly, due to lack of support for access to this data.

Hence, in order to maintain accessibility to such sensitive data held within a custom ADP, it is imperative to ensure replication of the ADP to at least one other Windows Server 2003 domain controller.

To minimise downtime, the location of the domain controller that will host the replica should be in close network proximity to the location of the servers that host the applications / services that will access and use the data within the ADP.

It may also be necessary to configure the applications or services to query the replicas on the other domain controllers in the event of failure.

It is possible to achieve load balancing and availability from this perspective via the configuration of appropriate DNS SRV records for the LDAP protocol, should this protocol be the standard access protocol for the application or service.

Factor B3: Understanding the influence of client authentication and authorisation requirements to access ADP objects, on the selection of a host Windows Server 2003 domain controller


Has identified the requirements for the design and deployment of one or more custom ADPs, with a replication topology, within the Active Directory forest, and

Wishes to understand the influence of the client authentication and authorisation requirements, on the selection of a host Windows Server 2003 domain controller


Within some organisations, it may be possible to identify that the Active Directory forest, which supports a custom ADP, does not represent all or some of the clients of an ADP as security principals. Instead, another Active Directory forest, external domain, or Kerberos Realm external to this Active Directory forest may support these clients.

Although the replication of a custom ADP is restricted to domain controllers within the same forest, clients of an ADP can still access the data within the ADP across external trust relationships and realm trusts.

In this scenario, it is necessary to consider the following information when selecting host domain controllers to distribute a custom ADP to multiple Windows Server 2003 domains within the forest:



All objects within a custom ADP have an access control list. The “default security descriptor reference domain” for an ADP will provide the default domain name for access control entries. However, it is possible to add security principals from other domains to the ACLs on objects within the ADP.

Where an external domain or Kerberos V5 realm represents clients of a custom ADP, it is necessary to replicate the custom ADP to a domain controller representing a Windows Server 2003 domain within the forest that trusts the external domain / Kerberos V5 realm.

A custom Windows Server 2003 Active Directory ADP does not support security principals, and hence cannot provide a domain-independent authentication infrastructure.

Factor B4: Understanding the influence of inter-Site replication of application directory partitions, on the selection of a host Windows Server 2003 domain controller



Wishes to understand the influence of the inter-Site replication of application directory partitions, on the selection of a host Windows Server 2003 domain controller


Where an organisation has identified the requirement to replicate a copy of the ADP to more than one other domain controllers in a different Active Directory Site to the original domain controller host of the ADP, then consider the following information:

Data held within ADPs may, in the majority of cases, be volatile / semi-volatile in nature when compared to “traditional” (non-application created and managed) data held within the other naming contexts of an Active Directory forest. As a result, the frequency of changes to the data may be quite high, which correspondingly will produce a higher volume of replication traffic.

Because of the typically volatile nature of the data held within ADPs, replicating these partitions between Sites may not be feasible due to potential replication latencies associated with inter-Site replication. By the time the data reached the destination Site from a source domain controller for a custom ADP, the data may be out-of-date. Hence, for data that is so volatile that it cannot withstand replication latencies, only application servers within the same LAN can realistically use the data.

In these situations, it may be prudent to design duplicate ADPs for application servers within each Site, restricting replication to local domain controllers only.

Where inter-Site replication may be feasible, since the data is tolerant to reasonable levels of replication latency, it is necessary to determine the volume of network traffic generated by replication of changes to the data within the custom ADPs. Information about the application that will be managing the ADP, and the frequency and nature of changes to the data



stored in the ADP, it is possible to estimate the volume of traffic that the ADP will generate to replicate the changes between Sites.

This design methodology recommends use of the estimations for the volume and frequency of inter-Site replication traffic to determine the suitability of the inter-Site network links in transmitting this replication traffic, based upon available bandwidth statistics.

The KCC process will automatically generate the appropriate connection objects (where they do not exist). The connection objects will create a replication path between domain controllers selected to host replicas of an application directory partition. A connection object can replicate any common naming contexts that exist between the source and destination domain controllers, and this includes ADP naming contexts.

For inter-Site replication, the same replication schedules used for inter-Site replication of domain naming contexts apply to custom ADP replication.

Factor B5: Understanding the influence of intra-Site replication of application directory partitions, on the selection of a host Windows Server 2003 domain controller



Wishes to understand the influence of the intra-Site replication of application directory partitions, on the selection of a host Windows Server 2003 domain controller


Where an organisation has identified the requirement to replicate a copy of the ADP to more than one other domain controllers in the same Active Directory Site as the original domain controller host of the ADP, then consider the following information:

Within a custom ADP, it is possible to configure the notification delay variables using the ntdsutil command line utility. These variables can control the frequency for replication of changes to data within an ADP, to other domain controllers within the same Site.

Within a Windows Server 2003 Active Directory forest, operating at a functional level lower than “Windows Server 2003”, the default intra-Site replication interval of 300/30 is still in effect for legacy Windows 2000 domain controllers, and Windows Server 2003 domain controllers upgraded from Windows 2000 domain controllers. However, where newly installed Windows Server 2003 domain controllers host custom ADPs, then replication of data changes to the ADP use the new intra-Site replication frequency of 15/3. See the Site Plan process “design for the configuration of Site Link objects” for details on intra-Site replication frequencies, and the notations “300/30” and “15/3”.

This design methodology proposes compliance with the following criteria for configuration of the notification delay variables for a custom ADP, to fine-tune intra-Site replication:



The custom ADP is replicated to an Windows Server 2003 domain controller, upgraded from a Windows 2000 domain controller

The data held within a custom ADP is dynamic, volatile, and sensitive to replication latencies of even a few minutes (the maximum intra-Site replication interval, using the default 300/30 replication frequency)

The selection of host Windows Server 2003 domain controllers for a custom ADP, within the same Site as a source domain controller, must hence consider the following:

The selection of a newly installed Windows Server 2003 domain controller, which uses the new intra-Site replication frequency of 15/3, where the data within the custom ADP is dynamic, volatile, and sensitive to replication latencies of even a few minutes.

The selection of a Windows Server 2003 domain controller no more than two replication hops apart from the source domain controller.

Factor B6: Understanding the influence of the number of peer domain controllers for a domain and the volume and frequency of changes that will be generated within that domain / Site, on the selection of a host Windows Server 2003 domain controller



Wishes to understand the influence of the number of peer domain controllers for a domain and the volume and frequency of changes that will be generated within that domain / Site, on the selection of a host Windows Server 2003 domain controller


The selection of one or more host Windows Server 2003 domain controllers for a custom ADP must consider the number of peer domain controllers for the selected host, and the volume and frequency of Active Directory changes that require replication within that domain and / or Site.

Where a potential host Windows Server 2003 domain controller is one of many peer domain controllers that represent an Active Directory domain, then the number of changes potentially generated and replicated between the domain controllers may be significant. Within this scenario, the domain controllers may experience high-levels of resource utilisation and consequently experience replication latencies during completion of I/O operations.

The addition of a custom ADP to a domain controller within this environment may increase the workload on the domain controller even more, producing adverse conditions for both the security principals within the domain and for the applications / services that will use and manage the data stored within the ADP.

Hence, the selection of a host domain controller for a custom ADP is required to consider these factors. This is important to ensure no compromises are made to the requirements for the ADP, with respect to data volatility, sensitivity to replication latency, responsiveness of the ADP to application queries and so on, and the requirements for the domain for the host domain controller.



The combination of the above considerations should hence determine the requirement to either select an existing domain controller to host a custom ADP replica, or create a new dedicated domain controller within the same or remote Site, to host and manage a custom ADP for the forest.

Factor B7: Understanding the influence of the hardware specifications of the Windows Server 2003 domain controllers, on their selection to host a custom ADP



Wishes to understand the influence of the hardware specifications of the Windows Server 2003 domain controllers, on their selection to host a custom ADP


Most organisations, when executing exercises to determine hardware specification for Windows Server 2003 domain controllers, base calculations upon the following (example) parameters:

The primary role(s) of the domain controller, such as a FSMO role host, a GC server, a bridgehead server, and so on

The volume and frequency of changes the Active Directory domain may experience, as this has a direct influence on the I/O operations for the domain controllers, and so on

Within most organisations, limitations on financial budgets, as well as the expected operational requirements for the domain controllers, will influence the minimum hardware specifications for a Windows Server 2003 domain controller.

The minimum hardware specifications, for a Windows Server 2003 domain controller, typically support operation of the domain controller at a maximum of 50% server hardware utilisation. However, the addition of an extra overhead to these domain controllers, such as one or more custom ADPs, may increase this server hardware utilisation.

The consequences of this increase in I/O operation for a Windows Server 2003 domain controller may degrade its responsiveness to its non-ADP related functions and roles, as the domain controller may be using more CPU cycles and RAM than designed.

Hence, when assessing potential Windows Server 2003 domain controllers to host a custom ADP, it is important to consider the following:

The primary functions or roles of the domain controller within the domain, Site, forest, and the design for the hardware specifications of the potential host Windows Server 2003 domain controller to support its primary functions or roles.

The expected volume and frequency of changes to the data within the custom ADP, and the influence of the requirements to support these I/O operations on the hardware resource utilisation profile for the potential host Windows Server 2003 domain controller.



Factor A2: Definition of the criteria for the selection of one or more host Windows Server 2003 domain controllers for each in-scope custom ADP



Wishes to define the criteria to qualify the selection of one or more host Windows Server 2003 domain controllers for each in-scope custom ADP


Once the organisation has considered all factors influential in the selection of a host Windows Server 2003 domain controller, it is necessary to execute the following steps:

Identify one or more potential host Windows Server 2003 domain controllers for each in-scope custom ADP

Define the criteria to qualify the selection of the host domain controllers

Evaluate the potential host domain controllers against the defined criteria

When defining the criteria to qualify the selection of potential host Windows Server 2003 domain controllers, consider the following:

The criteria must reflect the business and technical objectives that justified the requirements to replicate a custom ADP to one or more host domain controllers.

Although the onus is with the organisation to define their criteria, this design methodology provides the following example criteria:

The inclusion of a potential host Windows Server 2003 domain controller within the replica set for a custom ADP will not:

Degrade the performance of any routine operations for the domain controller

Generate any unacceptable replication delays due to the:

Logical and physical location of the potential host domain controller within the organisation, and the performance metrics for the supporting network infrastructure

The current workload of the potential host domain controller, and so on

Compromise the security of the data within the Active Directory due to the lack of physical or network security for the potential host domain controller

The potential host domain controllers will support the 15/3 intra-Site replication interval


Select an in-scope custom ADP and select all potential host Windows Server 2003 domain controllers for the ADP



Define and document the criteria for the qualification of all potential host Windows Server 2003 domain controllers for a custom ADP

Evaluate all identified host Windows Server 2003 domain controllers against the defined criteria and identify the domain controller to host each in-scope custom ADP

Factor D1: Generation of the design of the replication topology for each in-scope custom ADP



Has identified the host Windows Server 2003 domain controllers for each in-scope custom ADP, and

Wishes to generate the design for the replication topology for each in-scope custom ADP


This design methodology proposes that the design for the replication topology for each in-scope custom ADP adopt the following format and content:

The details of the custom ADPs that require design and implementation within the Windows Server 2003 Active Directory forest

The details of the criteria to qualify the design of a replication topology for a custom ADP

The identity of each custom ADP that requires a design for a replication topology

The potential Windows Server 2003 domain controllers to host replicas of each in-scope custom ADP

The criteria to qualify the selection of host Windows Server 2003 domain controllers for each in-scope ADP

The identity of the host Windows Server 2003 domain controllers to host replicas of a custom ADP

The design of a process to add each identified host domain controller to the replica set for the appropriate custom ADPs

A diagram illustrating the logical and physical placement of the identified host domain controllers for each in-scope custom ADP, and the replication topology for each custom ADP


Documents

Site Plan (Book 4 of 5)