Export (0) Print
Expand All

Advanced Replication Management

Active Directory replication occurs automatically and reliably with no administrative intervention, other than that required to configure sites and site links. Some replication events, however, warrant additional understanding for those administrators who need to fine-tune replication beyond the default behavior. For more information about advanced replication management and troubleshooting, see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book.

Reciprocal Replication

Replication between sites exhibits request-pull behavior (the receiver, or destination, requests changes from the sender, or source, according to a schedule). Replication within a site, on the other hand, exhibits notify-pull behavior (the receiver is notified of changes by the sender, and the receiver then requests changes from the sender). For replication to occur in two directions, both sides of a connection must be able to initiate replication with the other side.

In cases where replication between sites can be initiated by only one side of a site link, such as when a dial-up connection must go through an Internet service provider (ISP) a flag can be set on the connection object (on the basis of site link attribute information) to implement two-way replication between the source and destination domain controllers of the connection as follows: The domain controller on the dial-up side of the link opens a connection and initiates replication (requests changes). After it receives the changes from the domain controller it contacted, it responds by sending a change notification. The change notification prompts the second domain controller to request changes from the first domain controller. The effect is two-way replication over the initial connection that was opened by the dial-up side of the site link.

The most common scenario in which reciprocal replication is enabled is replication between the main office and a branch office of a company. In this scenario, the branch office must dial up an ISP before a tunneled IP connection (also called a virtual private network or VPN link) can be established. In this example, the following occurs:

  1. The branch office dials up the ISP.

  2. The branch office establishes a tunneled IP connection to the main office.

  3. The branch office initiates replication by requesting changes from the main office.

  4. After replication, the branch office immediately sends a change notification to the main office.

  5. The main office requests replication changes from the branch office.

  6. The branch office replicates its changes to the main office.

In this scenario, reciprocal replication is required because the main office cannot instruct the ISP to first dial up the branch office and, therefore, cannot initiate a connection. Only the branch office can initiate communication to the main office. With reciprocal replication enabled, after the VPN link has been established, replication from the branch office can be initiated by the branch office.

Enabling reciprocal replication between two sites involves modifying the options attribute value on the site link object. With this attribute set on the site link, the KCC creates the connections across the link with the appropriate setting that is in effect. Use ADSI Edit to enable reciprocal replication.

To enable reciprocal replication between two sites

  1. In ADSI Edit, expand the Configuration container.

  2. Navigate to the Inter-SiteTransports container, and select CN=IP . (You cannot enable reciprocal replication for SMTP links.)

  3. Right-click the site link object for the sites for which you want to enable reciprocal replication, and then click Properties .

  4. In the Select a property to view box, select options .

  5. In the Edit Attribute box, if the Value(s) box shows <not set> , type 2 in the Edit Attribute box.
    If the Value(s) box already contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value  BITWISE-OR 2. For example, if the value in the Value(s) box is 1, calculate 0001 OR 0010 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3.

  6. Click OK .

Change Notification

Change notification is a mechanism by which a domain controller notifies a replication partner that it has changes. Replication within a site occurs as a response to changes; as changes occur on one domain controller, it notifies its replication partner, which prompts the partner to request the changes. When a domain controller performs an update to an attribute, it sends notification to its replication partner within a specified time following the change.

Change Notification Within a Site

For changes that occur within a site, there is a "holdback timer" that determines the interval between the time a change is made and the time that the source server notifies its replication partners. This interval serves to stagger network traffic caused by replication. When a domain controller makes a change (originating or replicated) to a directory partition, it starts the timer; when the timer expires, the domain controller notifies all of its replication partners (for that directory partition and within the site) that it has changes. If a partner is not engaged in requesting changes from another partner, it sends its change request to the notifying server.

The default value for the holdback timer is 300 seconds, or 5 minutes. To change the default registry setting, you can set a new value in the Replicator notify pause after modify (secs) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

note-icon Note

Very small values for this timer generate redundant notifications, which can decrease performance.

A domain controller does not notify all of its replication partners at one time. By delaying between notifications, the domain controller spreads out the load of responding to replication requests from its partners. The default delay between notifications is 30 seconds. To change the default delay, set a new value in the Replicator notify pause between DSAs (secs) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

caution-icon Caution

Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. There are programs available in Control Panel or Microsoft Management Console (MMC) for performing most administrative tasks. These programs provide safeguards that prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Registry editors bypass the standard safeguards that are provided by these administrative tools. Modifying the registry is recommended only when no administrative tool is available. Before you make changes to the registry, it is recommended that you back up any valuable data on the computer. For instructions about how to edit registry entries, see Help for the registry editor that you are using. For more information about the registry, see the Microsoft Windows   2000 Resource Kit Technical Reference to the Windows 2000 Registry (Regentry.chm).

Change Notification Between Sites

By default, changes are replicated between sites according to a schedule and not according to when changes occur. For this reason, the greatest replication latency across the forest is the sum of the greatest replication latencies along the single longest replication path of any directory partition.

For special circumstances, you can configure change notifications on connections between sites. By modifying the site link object, you can enable change notification between sites for all connections that occur over that link. Use ADSI Edit to enable change notification between sites.

To enable change notification between sites

  1. In ADSI Edit, expand the Configuration container.

  2. Navigate to the Inter-Site Transports container, and select CN=IP . (You cannot enable change notification for SMTP links.)

  3. Right-click the site link object for the sites for which you want to enable change notification, and then click Properties .

  4. In the Select a property to view box, select options .

  5. In the Edit Attribute box, if the Value(s) box shows <not set> , type 1 in the Edit Attribute box. If the Value(s) box contains a value, you must derive the new value by using a Boolean BITWISE-OR calculation on the old value, as follows: old_value  BITWISE-OR 1. For example, if the value in the Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer value of the result in the Edit Attribute box; for this example, the value is 3.

  6. Click OK .

Enabling change notifications across site links propagates all change notifications. With change notification between sites set, changes propagate to the remote site with the same frequency that they are propagated within the source site, including changes that warrant urgent replication.

note-icon Note

Do not enable change notification on demand-dial IP site links or on SMTP site links.

Urgent Replication

Urgent replication is implemented by immediately notifying replication partners over RPC/IP that changes have occurred on a source domain controller. Urgent replication uses regular change notification between destination and source domain controller pairs that otherwise use change notification, but notification is sent immediately in response to urgent events instead of waiting the default period of five minutes. Therefore, if you have change notification enabled on a site link, urgent replication is possible between sites for events that trigger it.

Events That Trigger Urgent Replication

Urgent Active Directory replication is always triggered by certain events on all domain controllers within the same site. When you have enabled change notification between sites, these triggering events also replicate immediately between sites.

Immediate replication between Windows 2000–based domain controllers in the same site is prompted by the following:

  • Assigning an account lockout, which prohibits a user from logging on after a certain number of failed attempts.

  • Changing a Local Security Authority (LSA) secret, which is a secure form in which private data is stored by the LSA.

  • Change in the relative identifier (known as a "RID") master role owner, which is the single domain controller in a domain that assigns relative identifiers to all domain controllers in that domain.

Urgent Replication of Account Lockout Changes

Account lockout is a security feature that sets a limit on the number of failed authentication attempts that are allowed before the account is "locked out" from a further attempt to log on, in addition to a time limit for how long the lockout is in effect.

In Windows 2000, account lockout is urgently replicated to the primary domain controller (PDC) emulator role owner and is then urgently replicated to the following:

  • Domain controllers in the same domain that are located in the same site as the PDC emulator.

  • Domain controllers in the same domain that are located in the same site as the domain controller that handled the account lockout.

  • Domain controllers in the same domain that are located in sites that have been configured to allow change notification between sites (and, therefore, urgent replication) with the site that contains the PDC emulator or with the site where the account lockout was handled. These sites include any site that is included in the same site link as the site that contains the PDC emulator or in the same site link as the site that contains the domain controller that handled the account lockout.

In addition, when authentication fails at a domain controller other than the PDC emulator, the authentication is retried at the PDC emulator. For this reason, the PDC emulator locks the account before the domain controller that handled the failed-password attempt if the bad-password-attempt threshold is reached. For more information about how the PDC emulator role owner manages password changes and account lockouts, see "Managing Flexible Single-Master Operations" in this book.

Managing Urgent Replication

The following guidelines can be useful when deciding whether to enable change notification between sites relative to achieving urgent replication.

  • If you want urgent replication everywhere, put all domain controllers for the specific domain in a single site (this option might not be realistic).

  • If you want urgent replication everywhere but still want the benefits of site affinity, use multiple sites and enable change notification on all site links.

  • By default, a user lockout prompts urgent replication at the site that contains the domain controller that handled the authentication and the site that contains the PDC emulator role owner.

Forced Replication Between Two Servers

You can use a connection object to force replication from the inbound server. In Active Directory Sites and Services, right-click a connection object, and then click Replicate Now . For information about how to force replication between two servers by using a connection object, see Windows 2000 Server Help. For more information about forcing replication by using other tools, see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book.

Replication of Password Changes

Password changes are replicated differently than normal (non-urgent) replication and urgent replication. Changes to security account passwords present a replication latency problem wherein a user's password is changed on domain controller A and the user subsequently attempts to log on, being authenticated by domain controller B. If the password has not replicated from A to B, the attempt to log on fails. Active Directory replication remedies this situation by forwarding password changes immediately to a single domain controller in the domain, the PDC emulator.

In Windows 2000 domains, a single domain controller per domain holds the role of PDC emulator, which simulates the behavior of a Microsoft Windows NT version 3. x –based or Windows NT 4.0–based primary domain controller. In Windows NT 4.0, the only domain controller that can accept updates is the primary domain controller. If authentication fails at a backup domain controller, the authentication request is passed immediately to the primary domain controller, which is guaranteed to have the current password.

In Windows 2000, when a user password is changed at a specific domain controller, that domain controller attempts to update the respective replica at the domain controller that holds the PDC emulator role. Update of the PDC emulator occurs immediately, without respect to schedules between sites on site links. The updated password is propagated to other domain controllers by normal replication within a site. When the user logs on to a domain and is authenticated by a domain controller that does not have the updated password, the domain controller refers to the PDC emulator to check the credentials of the user name and password rather than denying authentication based on a nonvalid password. Therefore, the user can log on successfully even when the authenticating domain controller has not yet received the updated password.

If the update at the PDC emulator fails for any reason, the password change is replicated non-urgently by normal replication.

For clients that are running Windows NT 4.0 or clients that are running Microsoft® Windows® 95 or Microsoft® Windows® 98 without the Directory Services Client Update Pack, the client attempts to contact the PDC emulator. If the client is directory-aware, the client contacts any domain controller and the contacted domain controller then attempts to contact the PDC emulator.

note-icon Note

A domain controller can be set to not contact the PDC emulator if the PDC emulator role owner is not in the current site. If the AvoidPdcOnWan entry in HKEY_LOCAL_MACHINE\CurrentControlSet\Services\Netlogon\Parameters\ is set to 1, the password change reaches the PDC emulator non-urgently through normal replication.

Creation of Extra Connection Objects

The KCC is designed to produce a topology that provides low replication latency, that adapts to failures, and that does not need modification. Adding connections is not recommended because extra connections gradually reduce the ability of the KCC to automatically choose the best configurations. In addition, you create a situation where you must continually evaluate whether the manual connections are doing the best possible job of replicating changes.

Adding extra connections does not necessarily reduce replication latency. Within a site, latency issues are usually related to factors other than the KCC's choices for topology. Factors that affect latency include the following:

  • Interruption of the service of key domain controllers, such as the PDC emulator, Global Catalog servers, or bridgehead servers.

  • Domain controllers that are too busy replicate in a timely manner (too few domain controllers).

  • Network connectivity issues.

  • DNS server problems.

  • Inordinate amounts of directory updates.

For problems such as these, creating a manual connection does not improve replication latency. Adjusting the scheduling and costs that are assigned to the site link is the best way to influence intersite topology.

The KCC automatically creates connections to keep your directory connected, even if extended failures and outages occur. Create connections manually only if the connections that are automatically configured by the KCC do not connect specific domain controllers that you want to connect. For example, if you want to create a connection on a short-term basis in order to force replication from one particular server, you can use Active Directory Sites and Services to create a connection object if one does not already exist for that server.

note-icon Note

The cost of the extra connections, as compared to the cost associated with the default configuration, is extra CPU cycles, disk reads, and network messages expended on replication.

You might need extra connections between domain controllers that are within a site or between sites in the following situations:

  • When you want to reduce the number of hops between domain controllers within a site. By default, an update takes at most three hops from where it originates to another domain controller in the site. To reduce the number of hops to two hops or to one hop, add extra connections.

  • When failures occur between domain controllers in different sites. If failures occur, you might want to add connections that bypass the failed server or servers. (The KCC creates new connections in such cases, but this adaptive process adds some replication latency.)

If you create a connection that is similar to one that the KCC would have created (that is, the KCC would have connected the same two domain controllers in the same direction), the KCC does not create another connection between those servers, nor does it delete or modify the connection that you have created. (For information about how to create a connection object, see Windows 2000 Server Help.)

In large networks, use the following general guidelines to manage connections for optimum KCC performance:

  • Reduce the number of sites when possible.

  • Increase the memory in your domain controllers.

  • Turn off the Bridge all sites option, if possible.

  • As a last resort, turn off automatic generation of intersite topology and create connections manually.

For more information about managing replication by using extra connections and about KCC scaling recommendations, see the Microsoft Knowledge Base link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources . Search the Knowledge Base by using the keyword "Q244368."

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft