Inside Windows Server 1002003 [Electronic resources] نسخه متنی

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:

• Replicator notify pause after modify (secs) - 300 secs




• Replicator notify pause between DSAs (secs) - 30 secs

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.

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.

Forcing Replication

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

1. Expand the tree to the server to which you want to replicate. Remember that connections represent inbound data flows.

2. Find the NTDS Settings object and its associated Connection objects under the server icon.

3. Right-click the connection from the replication partner and select R

   EPLICATE N

   OW 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

Diagnosing RPC Problems

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