Troubleshooting Active Directory Replication Problems

On This Page

Overview
General Guidelines for Troubleshooting Replication Problems
Troubleshooting No Inbound Neighbors Repadmin.exe Error
Troubleshooting Access Denied Replication Errors
Troubleshooting GUID Discrepancies
Troubleshooting RPC Server Problems
Troubleshooting NTDS Event ID 1311
Troubleshooting SceCli Event ID 1202

Overview

Active Directory replication problems can have several different sources. For example, DNS problems or incorrect site configuration can cause Active Directory replication to fail. Table 2.7 shows common events that might indicate a problem with Active Directory replication, together with root cause and solution information.

Table 2.7 Events that Indicate Active Directory Replication Problems

Event

Root Cause

Solution

Net Logon Event ID 5805

A machine account failed to authenticate, which is usually caused by either multiple instances of the same computer name, or the computer name has not replicated to every domain controller.

If you do not find multiple instances of the computer name, verify that replication is functioning for the domain that contains the computer account.

NTDS Event ID 1083

A duplicate object is present in the Active Directory of the replication partner of the local domain controller, so updating it is impossible.

See "Troubleshooting Directory Data Problems" in this guide.

NTDS Event ID 1265

Replication failed for the reason stated in the message text.

Use Repadmin.exe to further identify the problem, and use Table x.x to determine the appropriate action to take for the message generated by Repadmin.exe.

If the event message indicates a DNS lookup failure or the RPC server is unavailable, see "Troubleshooting Active Directory-Related DNS Problems" in this guide.

If the event message indicates that the target account name is incorrect, troubleshoot GUID discrepancies.

If the event message indicates a time difference between the client and server, synchronize replication from the PDC emulator.

NTDS Event ID 1311

This error occurs when the replication configuration information in Active Directory Sites and Services does not accurately reflect the physical topology of the network.

Troubleshoot NTDS event ID 1311.

NTDS Event ID 1388

This error is usually generated by a lingering object which resulted from disconnecting a domain controller for too long.

If the domain controller does not also function as a global catalog server, see "Remove Lingering Objects from an Outdated Writable Domain Controller."

If the domain controller also functions as a global catalog server, see "Remove Lingering Objects from a Global Catalog Server."

NTDS Event ID 1645

This error occurs over an existing replication link when the GUID of the NTDS Settings object of a replication partner does not match the GUID defined in the Service Principal Name (SPN) attributes of the computer object of this replication partner.

Troubleshoot GUID discrepancies.

SceCli event ID 1202

A user account in one or more Group Policy objects (GPOs) cannot be resolved to a security identifier (SID). This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights Assignment or Restricted Groups branch of a GPO.

Troubleshoot SceCli event ID 1202.

General Guidelines for Troubleshooting Replication Problems

To identify Active Directory replication problems, use the repadmin /showreps command. Table 2.8 shows the error message generated by this command, together with root cause and solution information.

Table 2.8 Repadmin /Showreps Error Messages

Repadmin Error

Root Cause

Solution

No inbound neighbors.

If no items appear in the "Inbound Neighbors" section of the output generated by the repadmin /showreps command, the domain controller was not able to establish replication links with another domain controller.

See "Troubleshoot No Inbound Neighbors Repadmin.exe Error."

Access is denied.

A replication link exists between two domain controllers, but replication cannot be properly performed.

See "Troubleshoot Access Denied Replication Errors."

Last attempt at <date - time> failed with the "Target account name is incorrect."

This problem can be related to connectivity, DNS, or authentication issues.

If it is a DNS error, the local domain controller could not resolve the GUIDbased DNS name of its replication partner.

See "Troubleshooting Active Directory-Related DNS Problems."

Also see "Troubleshoot Access Denied Replication Errors."

No more end point.

This can be caused because no more end-points are available to establish the TCP session with the replication partner.

This error can also result when the replication partner can be contacted, but its RPC interface is not registered. This usually indicates that the domain controller's DNS name is registered but with the wrong IP address.

Use Netstat to check the currently established sessions. Free up TCP sessions, if necessary.

Correct the IP address and see Troubleshooting "Active Directoryrelated DNS Problems."

LDAP Error 49.

The domain controller computer account might not be synchronized withthe Key Distribution Center (KDC).

See "Troubleshoot Access Denied Replication Errors."

Cannot open LDAP connection to local host.

The administration tool could not contact Active Directory.

See "Troubleshooting Active Directory-Related DNS Problems."

AD replication has been preempted.

An inbound replication in progress was interrupted by a higher priority replication request, such as a request generated manually by using the repadmin /sync command.

Wait for replication to complete.

Replication posted, waiting.

The domain controller posted a replication request and is waiting for an answer. Replication is in progress from this source.

Wait for replication to complete.

Last attempt @never was successful.

  • The KCC successfully created the replication link between the local domain controller and its replication partner, but because of the schedule or possible bridgehead overload, replication has not occurred.

  • A large backlog of inbound replication must be performed on this domain controller.

For more information about replication concepts, see "Active Directory Replication" in the Distributed Systems Guide of the Windows 2000 Server Resource Kit.

Troubleshooting No Inbound Neighbors Repadmin.exe Error

When no items appear in the "inbound neighbors" section of the repadmin /showreps command output, one of the following conditions exists:

  • No connection object exists to indicate which domain controller(s) this domain controller should replicate from. These connection objects are typically created by the KCC. However, in some environments, administrators have turned off the part of the KCC that creates connection objects for inbound replication from domain controllers in other sites, relying on manual connections instead.

  • One or more connection objects exist, but the domain controller is unable to contact the source domain controller to create the replication links. In this case, the KCC logs events each time it runs (by default, every 15 minutes) detailing the error that occurred when it attempted to add the replication links.

Ensure that a connection object has been properly created between the domain controller and its replication partner. If not, then create the connection object.

Procedures for Troubleshooting No Inbound Neighbors

  1. Verify connection object.

  2. If no connection object exists, create a connection object.

  3. After you create the connection objects, see "Linking Sites for Replication" for procedures to create a site link. Replication should occur automatically at the scheduled time.

Troubleshooting Access Denied Replication Errors

This error indicates that the local domain controller failed to authenticate against its replication partner when creating the replication link or when trying to replicate over an existing link. This typically happens when the domain controller has been disconnected from the rest of the network for a long time and its computer account password is not synchronized with the computer account password that is stored in the Active Directory of its replication partner.

Procedures for Troubleshooting Access Denied Replication Errors

  1. Confirm naming context permissions on direct replication partners by using the dcdiag /test:ntsec command. Verify replication is functioning. If replication is not functioning properly, continue with the next step.

  2. Confirm that the Enterprise Domain Controllers group contains the "access this computer from network" right. If you have to add this right, ensure the domain has applied group policy before proceeding. Verify replication is functioning. If replication is not functioning properly, continue with the next step.

  3. Stop the KDC on the local domain controller.

  4. Purge the ticket cache on the local domain controller.

  5. Verify that the domain controller is in the Domain Controllers OU, the default domain controllers GPO is linked to the OU, and the "access this computer from network" policy is effective in this domain.

  6. Reset the computer account password on the PDC emulator.

  7. Synchronize the domain naming context of the replication partner with the PDC emulator.

  8. If the repadmin /showreps command shows no replication partner, see "Link Sites for Replication" in this guide for procedures to create a replication link.

  9. Synchronize replication from a source domain controller.

  10. Start the KDC on the local domain controller.

  11. If you get a new "access denied" error message, you must create a temporary connection link between the domain controller and its replication partner for the naming contexts.

Troubleshooting GUID Discrepancies

When a domain controller creates a replication link with its replication partner, it looks in its Active Directory for the GUID of the NTDS Settings object of its replication partner. It then checks whether the GUID matches the replication SPN present in the ServicePrincipalName of the computer object of its replication partner. If they don't match, the replication link cannot be established, and it logs an event in the Directory Services event log.

This can happen when a domain controller has been manually removed from the Active Directory and then Active Directory is reinstalled on the domain controller. After Active Directory is reinstalled, the domain controller gets a new GUID for its NTDS Settings object and creates a new replication SPN accordingly.

Procedures for Troubleshooting GUID Discrepancies

  1. Identify the GUID of the replication partner. If several entries are returned, this is the source of the error. One of entries results from the initial installation of Active Directory on the replication partner. If Active Directory was removed from the domain controller without running the Active Directory Installation Wizard, and then Active Directory was reinstalled on the domain controller, a new NTDS Settings object was created (with a new GUID) and was replicated to this domain controller. In that case, determine which NTDS Settings object has the correct GUID and delete the incorrect NTDS Settings object.

  2. Verify that a DNS record for the bad NTDS Settings object has not been created on the root DNS server. Verify DNS records for

    <

replication_partner_guid>._msdcs.<forest_root_domain_name>. Verify that only one DNS record for <replication_partner>.<regional_domain_name> is present with the right GUID. If several records are present, delete the incorrect records.

  1. If the previous step revealed only one NTDS Settings object with the correct GUID, verify the SPN for the replication partner on the local domain controller. If the name does not exist or contains a GUID which does not match its replication partner, it must be created in the Active Directory of the local domain controller. If the name exists with a different GUID, it must be modified to match the correct GUID.

    To do this, run ADSI Edit or LDP on the local domain controller. Locate the SPN in the multivalued attribute ServicePrincipalName of the computer object of the replication partner (CN=<computer_name>,OU=Domain Controllers,DC=dom1,DC=company,DC=com) and change the replication SPN to the correct value.

  2. Verify that replication is functioning.

Troubleshooting RPC Server Problems

When you perform any of the following server-based tasks, you might receive an error that says the RPC server is unavailable:

  • Replication

  • Winlogon

  • Enable trusted relationships

  • Connect to domain controllers

  • Connect to trusted domains

  • User authentication

The "RPC server unavailable" error can occur for the following reasons:

  • DNS problems

  • Time synchronization problem

  • RPC service is not running

  • Network connectivity problem

Procedures for Troubleshooting RPC Server Problems

  1. See "Troubleshooting Active Directory-Related DNS Problems to identify and resolve DNS issues."

  2. See "Troubleshooting Windows Time Service Problems" to identify and resolve time synchronization issues.

  3. If the RPC service is not running, start the RPC service. If the RPC service is running, stop and start the RPC service.

  4. Verify network connectivity and resolve any issues.

Troubleshooting NTDS Event ID 1311

NTDS Event ID 1311 occurs when the replication configuration information in Active Directory Sites and Services does not accurately reflect the physical topology of the network. The Knowledge Consistency Checker (KCC) constructs and maintains the replication topology for Active Directory. To do this, the KCC examines the sum of all naming contexts that reside in the forest as well as administrator-defined constraints for site, site link, and link cost.

An Event ID 1311 results from problems with replicating an Active Directory domain, schema, configuration, or global catalog naming contexts between domain controllers or sites. This can occur for the following reasons:

  • Site link bridging is enabled on a network that does not support physical network connectivity between two domain controllers in different sites that are connected by a KCC link.

  • One or more sites are not contained in site links.

  • Site links contain all sites, but the site links are not interconnected. This condition is known as disjointed site links.

  • One or more domain controllers are offline.

  • Bridgehead domain controllers are online, but errors occur when they try to replicate a required naming context between Active Directory sites.

  • Administrator-defined preferred bridgeheads are online, but they do not host the required naming contexts.

  • Preferred bridgeheads are defined correctly by the administrator, but they are currently offline.

  • The bridgehead server is overloaded either because the server is undersized, too many branch sites are trying to replicate changes from the same hub domain controller, or the schedules on site links or connection objects are too frequent.

  • The KCC has built an alternate path around an intersite connection failure, but it continues to retry the failing connection every 15 minutes.

Procedures for Troubleshooting NTDS Event ID 1311

  1. Determine if event ID 1311 is being logged on all domain controllers in the forest that hold the intersite topology generator (ISTG) role or just on site-specific domain controllers.

    1. First, locate ISTG role holders by using Ldp.exe to search for the following attributes:

Base DN: CN=Sites,CN=Configuration,DC=ForestRootDomainName,DC=Com Filter: (cn=NTDS Site Settings) Scope: Subtree Attributes: interSiteTopologyGenerator

2.  Determine the scope of the event by checking the Directory Service event logs of all ISTG role holders in the forest, or check at least a significant number of ISTG role holders.

If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.
  1. See "Troubleshooting Active Directory Replication Problems" in this guide to resolve Active Directory replication failures in the forest. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

  2. Determine if site link bridging is enabled and the network is fully routed. Site link bridging is enabled in Active Directory if the following conditions are true:

    • The Bridge all site links check box is selected for the IP transport and the Simple Mail Transfer Protocol (SMTP) transport in Active Directory Sites and Services.

    • The Options attribute for the IP transport and the SMTP transport is NULL or set to 0 (zero) for the following DN paths: CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<forest_root_domain> and CN=SMTP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<forest_root_domain>.

    To determine if a fully routed network connection exists between two sites, contact your network administrator or Active Directory architect. If site link bridging is enabled in a nonrouted environment, either make the network fully routed, or disable site link bridging and then create the necessary sites links and site link bridges. For more information about creating site links, see "Link Sites for Replication" in this guide. Wait for a period of time that is twice as long as the longest replication interval in the forest. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

    Note: Site link bridging is enabled by default. As a best practice, leave site link bridging enabled for fully routed networks.

  3. Use the repadmin /showism command to verify that all sites are defined in site links. For each site, the output of the command will show a string of three numbers separated by colons. The numbers represent <cost>:<replication interval>:<options>. Strings with a value of "-1:0:0" indicate a possible missing site link. If this is the case, see "Link Sites for Replication" in this guide for procedures to create a replication link. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

  4. Detect and remove preferred bridgeheads. Manually selecting bridgehead servers can cause event ID 1311; it is recommended that administrators do not manually select bridgehead servers. To search for preferred bridgehead servers, view the list of preferred bridgehead servers. If there are any preferred bridgehead servers, remove them from Active Directory Sites and Services, and wait for a period of time that is twice as long as the longest replication interval in the forest. If event ID 1311 continues to be logged on ISTG role holders, continue with the next step.

  5. Delete connections if the KCC is in "Connection Keeping" mode, and wait for a period of time that is twice as long as the longest replication interval in the forest.

Troubleshooting SceCli Event ID 1202

The presence of SceCli event ID 1202 in the application event log indicates that there might be problems with Active Directory replication, especially if the error text for this message contains a Win32 error code of either Error 1332 (0x534) or Error 1332 (0x6fc). The procedure for troubleshooting this event with either hexadecimal code is the same.

Procedure for Troubleshooting SceCli Event ID 1202

  1. Enable logging for winlogon.log by changing the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\GPExtensions\<GUID name of CSE>. This creates the winlogon.log file in the %systemroot%\security\logs folder.

    Caution: The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back up system state first. For information about backing up system state, see "Active Directory Backup and Restore" in this guide.

  2. Search the winlogon.log file for errors. At a command prompt, type the following and press ENTER:

FIND /I "error" %SYSTEMROOT%\security\logs\winlogon.log

This shows the account that is causing the problem. Determine why the account is causing the problem (for example, mistyped account, deleted account, or wrong policy was applied). If you determine that you need to remove this account from the policy, continue to the next step to determine which policy and setting to change.
  1. To find which setting contains the unresolved account, type the following command at a command prompt and press ENTER:

Find /I "<account>" %systemroot%\security\templates\policies\gpt*.*

This shows the cached template from the GPO that contains the setting that is causing the problem. View the template and search for a line that begins with "GPOPath=" and the GUID of the policy you need to change.
  1. Map the GUID of the problem GPO to its friendly name. Use the Gpresults.exe tool from the Windows 2000 Server Resource Kit to obtain extensive output from the computer that generated the events. Search the results for the GUID you identified from the previous step.

    If you cannot find the GUID in the output from the Gpresults.exe tool, use Search.vbs. Type the following command at a command prompt and press ENTER:

Search.vbs LDAP://CN=Policies,CN=System,DC=<domain>,DC=<domain> /C:(ojbectClass=groupPolicyContainer) /P:name,displayName

  1. Repair or modify the GPO, as necessary.