Controlling Replication Parameters
The default replication intervals set by the NTDS Site Settings object support most operations. This topic covers ways to adjust the default replication intervals if you want to tune your system. It also shows how to force replication if you want to hurry the process along.
Setting Replication Intervals
Within a site, domain controllers send out replication announcements within five minutes after receiving an update. This does not apply to replication between sites. Replication between sites is controlled solely by fixed polling schedules.
Changing Notification Parameters
When a domain controller updates its copy of a naming context, it notifies its replication partners so they can pull a copy of the update. The default notification interval is five minutes. The domain controller sends a notification to one partner then waits 30 seconds before sending a notification to the next partner.
The Registry values that control these notification intervals are stored in two values under HKLM | System || CurrentControlSet | NTDS | Parameters:
If you want a shorter notification interval, you can reduce the Replicator Notify Pause After Modify interval, but keep an eye on utilization levels.
In addition to update notifications, domain controllers replicate with their partners at fixed intervals. The purpose for this fixed schedule is to check for broken connections. The fixed replication interval is set by an attribute in the Connection object.
Changing Inter-Site Polling Frequency and Schedule
The default inter-site polling frequency is a 15-minute window every three hours. The interval is set by an attribute of the Site Link. You can change this interval using the AD Sites and Service console. See Figure 7.18 for an example. The minimum interval is 15 minutes.
Figure 7.18. Site Link object properties showing replication interval.
The default inter-site polling schedule is set to permit replication at any time. You can change the schedule to permit replication only during specific time periods. For example, you may want to delay replication until after working hours.
The interval is set by another attribute of the Site Link. If you click Change Schedule, a Schedule window opens to show the replication schedule. It's possible to set up schedules that put a particular site in a replication "shadow." This occurs when the schedules for intervening connections have no overlap. If you have scheduling problems, you can override all schedules using the Ignore Schedules option in the Properties window of the IP or SMTP transport object.
If you want a particular update to replicate sooner than the default interval, you can force replication. One way to do this is by using the AD Sites and Services console as described in Procedure 7.10.
Procedure 7.10 Forcing Replication with the AD Sites and Services Console
Expand the tree to the server to which you want to replicate. Remember that connections represent inbound data flows.
Find the NTDS Settings object and its associated Connection objects under the server icon.
Right-click the connection from the replication partner and select REPLICATE NOW from the flyout menu. You get a message indicating that the replication commenced. If the link is broken, you get a message saying that the RPC connection is unavailable. If the connection is an inter-site connection, the replication request will be queued.
You can check the Event log to verify that replication is complete. Alternatively, you can check the properties of a target object to verify that they changed. Replication does not occur immediately, so wait a few minutes before checking.
If you prefer command-line tools, you can force replication using REPADMIN with this syntax:
repadmin /syncall <DSA> <NC>
<DSA> is the fully qualified domain name of the server to which you want to replicate. <NC> is the distinguished name of the naming context you want to replicate. For example:
repadmin /syncall dc-01.company.com dc=company,dc=com
Intra-site replication takes place over secure RPC connections. A failed RPC connection can result in Event log errors such as There are no more endpoints available from the RPC Endpoint Mapper.
This is generally caused by network hardware failure, either a bad switch port or bad router table or a failed network adapter. It could also be caused by another RPC application that decided to interfere with the RPC Endpoint Mapper and the TCP ports it uses. The Microsoft RPC Runtime service selects TCP ports above 1024 at random to make its connections. If another process steps on one of those ports, you will get replication errors.
Another possible cause of an RPC failure is a failure of the RPC Locator service. This service uses TCP port 135 to reach out to an RPC server. Sometimes a rogue application uses TCP port 135 and steps on the Locator service. More often, though, losing this port is the result of a zealous firewall administrator.
If you think you are getting a failure of the RPC Locator service, try using the Rpcping utilities from the Resource Kit. These were originally designed for Exchange, but they are just as useful for Active Directory.
There are two components to RPC tracing using Rpcping. At the server, you start the RPC Listener by running RpingS32. From the client, generate RPC traffic by running Rpings and specifying the fully qualified DNS name of the server. If you get a response, you know the RPC Locator service is working at the client end and the RPC Runtime is properly configured at the server.
If Rpcping fails, check your network connections and configurations. Try restarting the server. You may have a problem with the network adapter driver, so always make sure you have the most current driver.