Lesson 3: Defining a Replication Strategy | MCSE Designing a Microsoft Windows 2000 Directory Services Infrastructure Readiness Review; Exam 70-219 (Pro-Certification)

The third step in creating a site topology plan is to define a replication strategy. To define a replication strategy, you must assess the physical connectivity of the organization's network, plan a site link configuration for each network connection, plan whether to disable site link transitivity (if necessary), and plan preferred bridgehead servers (if necessary). This lesson discusses how to define a replication strategy.

After this lesson, you will be able to

Explain how information is replicated within sites and between sites
Explain the purpose of site links, site link bridges, and bridgehead servers
Explain site link transitivity
Identify the factors in an organization's environment that impact its replication strategy
Analyze an organization's environment to define its replication strategy

Estimated lesson time: 40 minutes

Understanding Replication

Replication is the process of copying data from a data store or file system to multiple computers to synchronize the data. In Windows 2000, each domain controller maintains a replica of all Active Directory objects contained in the domain to which it belongs. Replication ensures that changes made to a replica on one domain controller are synchronized to replicas on all other domain controllers within the domain. If domains are linked in a forest, some of the data is synchronized to replicas on other domain controllers in other domains.

Replication Triggers

The following actions trigger replication between domain controllers:

Creating an object
Modifying an object
Moving an object
Deleting an object

Information Replicated

Three types of objects are stored in Active Directory. Each type of object is stored in a tree, called a naming context (NC). The three naming contexts are

Schema NC. Contains objects that can be created in the directory and the attributes those objects can have. Objects in the schema NC must be replicated to all domain controllers in all domains in the forest.
Configuration NC. Contains objects that represent the logical structure of the deployment, including the domain structure and replication topology. Objects in the configuration NC must be replicated to all domain controllers in all domains in the forest.
Domain NC. Contains all of the objects in a domain. Objects in the domain NC can be replicated only to domain controllers within the domain. For the purpose of finding information throughout the domain tree or forest, selected attributes for all objects in all domains are stored in the global catalog.

How Information Is Replicated

Recall that Active Directory replicates information in two ways: intrasite (within a site) and intersite (between sites). Table 6.2 compares the intrasite and intersite replication.

Table 6.2 Intrasite and Intersite Replication Comparison

	Intrasite replication	Intersite replication
Compression	To save CPU time, replication data is not compressed.	To save WAN bandwidth, replication data greater than 50 KB is compressed.
Replication model	To reduce replication latency, replication partners notify each other when changes need to be replicated and then pull the information for processing.	To save WAN bandwidth, replication partners do not notify each other when changes need to be replicated.
Replication frequency	Replication partners poll each other periodically.	Replication partners poll each other at specified intervals, only during scheduled periods. If updates are necessary, operations are scheduled to pull the information for processing.
Transport protocols	Remote procedure call (RPC)	IP or SMTP

For intrasite replication, the Windows 2000 Knowledge Consistency Checker (KCC) on each domain controller helps to automatically generate and optimize a replication topology among domain controllers in the same domain. To accomplish this, the KCC automatically creates connection objects between domain controllers. A connection object is an Active Directory object that represents a communication channel used to replicate information from one domain controller to another. Under normal conditions, Active Directory automatically creates and deletes connection objects. However, you can manually create connection objects to force replication if you are certain the connection is required and you want the connection to persist until you manually remove it.

For intersite replication to occur, you must customize how Active Directory replicates information by setting up site links. Site links are logical, transitive connections between two or more sites that mirror the network links and allow replication to occur. Once you have created site links, the KCC will then automatically generate the replication topology by creating the appropriate connection objects. It's important to note the difference between site links and connection objects. Site links are used by the KCC to determine replication paths between two sites and must be created manually. Connection objects actually connect domain controllers and are created by the KCC, though you can also manually create them if necessary.

Configuring Site Links

To ensure efficient replication and fault tolerance, you must configure the following information for site links:

Intersite transport. The method of transport used for replication, either
- Directory Service Remote Procedure Call (DS-RPC), designated in Windows 2000 as IP,
  or
- Inter-Site Messaging-Simple Mail Transport Protocol (ISM-SMTP), designated in Windows 2000 as SMTP
Site link cost. A value assigned to the site link that indicates the cost of the connection in relation to the speed of the link. Higher costs are used for slow links, and lower costs are used for fast links.
Replication frequency. A value assigned to the site link that indicates the number of minutes Active Directory should wait before using a connection to check for replication updates.
Replication availability. A schedule assigned to the site link that indicates when the link is available for replication.

Site Link Transitivity

By default, all site links are transitive, which simply means that if sites A and B are linked and sites B and C are linked, then site A and site C are transitively linked. Site link transitivity is enabled or disabled by selecting the Bridge All Site Links check box in the Properties dialog box for either the IP or the SMTP intersite transport. By default, site link transitivity is enabled for each transport.

If you disable site link transitivity for a transport, all site links for that transport are affected and none of them are transitive. You must manually create site link bridges to provide transitive replication. The following are some reasons why you may want to disable site link transitivity:

To have total control over replication traffic patterns
To avoid a particular replication path, such as a path that involves a firewall
If your IP network is not fully routed

CAUTION
Carefully consider the needs of your organization before disabling site link transitivity.

Site Link Bridges

A site link bridge connects two or more site links in a transport where transitivity has been disabled in order to create a transitive and logical link between two sites that do not have an explicit site link. For example, in Figure 6.7, site link Ber-Lu connects the Bern and Lucerne sites. Site link Lu-Zur connects the Lucerne and Zurich sites. Site link bridge Ber-Lu-Zur connects site links Ber-Lu and Lu-Zur.

click to view at full size

Figure 6.7 A site link bridge

Because site links are transitive by default, it is seldom necessary to create site link bridges. In other words, if site link transitivity is enabled, then manually creating a site link bridge will be redundant and will have no effect. However, if site link transitivity is disabled, you will need to manually create a site link bridge if a transitive link is required to handle your organization's replication strategy.

Bridgehead Servers

After you have configured site links, the KCC will then automatically designate a domain controller in each site, for each intersite transport, as the bridgehead server. A bridgehead server is a single domain controller in a site, the contact point, used for replication between sites. The KCC automatically creates connection objects between bridgehead servers. When a bridgehead server receives replication updates from another site, it replicates the data to the other domain controllers within its site.

A bridgehead server is designated automatically by the KCC. You can also specify a preferred bridgehead server if you have a computer with appropriate bandwidth to transmit and receive information. If you specify a preferred bridgehead server rather than use the one designated by the KCC, you can select the optimum conditions for the connection between sites. To designate a preferred bridgehead server, select the desired intersite transport or transports on the Server tab in the Properties dialog box for the domain controller you want to make a bridgehead server. You can specify multiple preferred bridgehead servers, but only one will be active at any time in a single site.

CAUTION
By specifying preferred bridgehead servers, you limit the ability of the KCC to provide failover should the bridgehead servers you designated as preferred go offline. If an active preferred bridgehead server fails, Active Directory will select another preferred bridgehead server from the set you designated. If no other preferred bridgehead servers are specified or no other preferred bridgehead servers are available, replication will not occur to that site.

How Intersite Replication Works

The following steps, illustrated in Figure 6.8, show how intersite replication works:

At the interval determined by the selected replication frequency, the bridgehead server in the Zurich site polls the bridgehead server in the Lucerne site for any updated data.
If the bridgehead server in the Lucerne site finds that it has updated Active Directory data, it compresses the data (if larger than 50 KB) and sends it to the bridgehead server in the Zurich site.
When the bridgehead server in the Zurich site has received all of the data, it then replicates the data to the other domain controllers in the site, without compressing the information.

click to view at full size

Figure 6.8 The intersite replication process

Note that polling and pull replication, rather than notification and push replication, are used between bridgehead servers during intersite replication. Pull replication is the most efficient for intersite replication because the destination domain controller knows which replication data to request. In contrast, notification and push replication are more efficient for intrasite replication, when domain controllers are well connected and not restrained by site link schedules.

Design Step: Defining a Replication Strategy

An organization's replication strategy determines when and how information is replicated. To define a replication strategy, you must complete the following tasks:

Assess the physical connectivity of the organization's network.
Plan a site link configuration for each network connection.
Plan site link transitivity disabling (optional).
Plan preferred bridgehead servers (optional).

Assessing Physical Connectivity

To define a replication strategy, you must first consult the site diagram containing domain controller locations that your design team compiled earlier to view the network links, sites, and domain controllers defined for your network and determine what site links are needed. You should also consider whether there is any need to disable site link transitivity and to create site link bridges. Then consider whether specifying preferred bridgehead servers is required. In addition to assessing these needs, it is imperative that you assess any changes that may be planned for the sites or domain controller locations to address growth, flexibility, and the ideal design specifications of the organization.

Planning a Site Link Configuration

For each site link, you will need to specify the following information: site link name, method of replication transport, site link cost, replication frequency, and replication availability.

For the site link name, you should set up a site link naming convention. This naming convention should easily convey the sites connected by the link. For example, if your sites are named Chicago and Redmond, you might name the site link Chi-Red or Red-Chi.

To select the method of replication transport for a site link, either Directory Service Remote Procedure Call (DS-RPC, designated in Windows 2000 as IP) or Simple Mail Transport Protocol (designated in Windows 2000 as SMTP), you'll need to know how the sites are connected. A site link that uses IP replication transport is designed for faster connections and uses remote procedure calls (RPCs) for direct synchronous replication using TCP/IP. A site link that uses SMTP replication transport is designed for slower and less reliable connections and uses e-mail messages to handle replication updates. Because SMTP replication transport is asynchronous, sending and receiving updates automatically according to the e-mail system, it ignores replication schedules.

IMPORTANT
If you choose to use SMTP transport, you must complete the process of installing and configuring a certificate authority. You must have an Enterprise certificate authority (CA) available and SMTP must be installed on all domain controllers that will use the site link. The CA signs SMTP messages that are exchanged between domain controllers, ensuring the authenticity of directory updates.

The site link cost can be a number between 1 and 32,767. The default cost is 100. Lower values indicate better connectivity and higher usage priority. The values you assign for the site link cost depend on the intersite link speeds and the replication transports used in your organization. For example, if you have three different types of connections (T1, 256 Kbps, and 64 Kbps), you will need three site link cost values. In addition, if you use both replication transports with each type of connection, you will need six site link cost values. The values you assign should reflect the relative bandwidth of the connections. For example, you may want to use 1—25 for fast, low-cost links; 26—50 for medium-cost links; and 51 and higher for high-cost links. Because Active Directory always chooses the connection on a per-cost basis, the cheapest connection will be used if it is available. You can assign identical costs to site links; the KCC treats these sites equally.

To set the replication frequency, indicate the number of minutes the replication partners on the site link should wait during scheduled periods before polling each other for changes.

To set the replication availability, you must consider when you want to allow replication along the site links. Consider allowing low-cost links to be available for longer periods of time, while allowing high-cost links to be available only at very specific times. For replication to occur across all links, you must schedule a common time period for the links to be available.

Planning Site Link Transitivity Disabling (optional)

By default, site link transitivity in Windows 2000 is enabled. You should disable site link transitivity only if it is absolutely necessary to have total control over replication traffic patterns. Disabling site link transitivity often creates work for the administrator and may cause replication between sites to fail. If you disable site link transitivity, you must create site link bridges between site links if you want to make them transitive.

Planning Preferred Bridgehead Servers (optional)

By specifying a preferred bridgehead server rather than using the one designated by the KCC, you can select the optimum conditions for the connection between sites.

To define a replication strategy

Identify sites connected with very fast (2Mbps or higher), low-cost connections.
Identify sites connected with medium-speed, medium-cost connections.
Identify sites connected with low-speed, unreliable, or high-cost connections.
Designate each connection as a site link on the site diagram by placing the name of the site link on the connection between two sites.
Create a site link table that includes the site link name, method of replication transport, site link cost, replication frequency, and replication availability for each site link.
(optional) On the site link table, list the transport(s) for which you need to disable site link transitivity.
(optional) For each transport listed, create a site link bridge table that indicates the name of each site link bridge required and the name of the site links contained in the site link bridge.
(optional) On the site link table, create a preferred bridgehead server table that lists the names of the domain controllers that you want to make preferred bridgehead servers for each site.

Design Step Example: Defining a Replication Strategy

Review Figure 6.5, which shows the site diagram, including domain controllers, for Margo Tea Company. Figure 6.9 shows a site diagram with site links added for Margo Tea Company. Site link names are indicated by the first three letters of each connected site name.

click to view at full size

Figure 6.9 Site links for Margo Tea Company

Table 6.3 shows the site link configurations planned for Margo Tea Company.

Table 6.3 Site Link Configurations for Margo Tea Company

Site link	Transport	Cost	Frequency	Availability
Cin-Pit	IP	25	15 min	always
Pit-Lou	IP	25	15 min	always
Cin-Lou	IP	25	15 min	always
Pit-Cha	IP	50	1 hr	2300 to 0500 daily
Cin-Tol	IP	50	1 hr	2300 to 0500 daily
Cin-Col	IP	50	15 min	always
Lou-Lex	IP	50	1 hr	2300 to 0500 daily

Margo Tea Company has no plans to disable site link transitivity. The company has also decided to let the KCC select the bridgehead servers and has not designated any preferred bridgehead servers.

Lesson Summary

In this lesson you learned how to define a replication strategy by assessing the physical connectivity of the organization's network, planning a site link configuration for each network connection, planning site link transitivity disabling (which is optional), and planning preferred bridgehead servers (which is also optional). You learned how to plan a site link configuration by selecting the site link name, method of replication transport, site link cost, replication frequency, and replication availability. You learned that site link transitivity in Windows 2000 is enabled by default and that you should disable site link transitivity only if it is absolutely necessary to have total control over replication traffic patterns. If you disable site link transitivity, you must create site link bridges between site links you want to make transitive. You also learned that a bridgehead server is designated automatically by the KCC and that you can specify a preferred bridgehead server if you have a computer with enough bandwidth to transmit and receive information. If you specify a preferred bridgehead server rather than use the one designated by the KCC, you can select the optimum conditions for the connection between sites. Finally, you learned to indicate your replication strategy by placing site links on the site diagram and by creating a site link table, site link bridge table (optional), and a preferred bridgehead server table (optional).