Troubleshooting Active Directory Replication Problems

Troubleshooting Active Directory Replication Problems
Updated: January 06, 2003 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 Net Logon Event ID 5805 NTDS Event ID 1083 NTDS Event ID 1265 Root Cause 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. Solution If you do not find multiple instances of the computer name, verify that replication is functioning for the domain that contains the computer account.
A duplicate object is present in the Active Directory See "Troubleshooting Directory Data of the replication partner of the local domain Problems" in this guide. controller, so updating it is impossible. 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 Troubleshoot NTDS event ID 1311. information in Active Directory Sites and Services does not accurately reflect the physical topology of the network. This error is usually generated by a lingering object If the domain controller does not also which resulted from disconnecting a domain function as a global catalog server, see controller for too long. "Remove Lingering Objects from an Outdated Writable Domain Controller."
NTDS Event ID 1388
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 Troubleshoot GUID discrepancies. 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. A user account in one or more Group Policy objects Troubleshoot SceCli event ID 1202. (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.
SceCli event ID 1202
Top of page
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 No inbound neighbors. Root Cause Solution
If no items appear in the "Inbound See "Troubleshoot No Inbound Neighbors Neighbors" section of the output Repadmin.exe Error." generated by the repadmin /showreps command, the domain controller was not able to establish replication links with another domain controller. A replication link exists between two domain controllers, but replication cannot be properly performed. 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. 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. The domain controller computer account might not be synchronized See "Troubleshoot Access Denied Replication Errors."
Access is denied.
Last attempt at <date - time> failed with the "Target account name is incorrect."
See "Troubleshooting Active DirectoryRelated DNS Problems." Also see "Troubleshoot Access Denied Replication Errors."
No more end point.
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.
See "Troubleshoot Access Denied Replication Errors."
withthe Key Distribution Center (KDC). Cannot open LDAP connection to local host. AD replication has been preempted. The administration tool could not contact Active Directory. See "Troubleshooting Active DirectoryRelated DNS Problems."
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. 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.
Replication posted, waiting.
Last attempt @never was successful.
The KCC successfully
Synchronize replication from a
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.
source domain controller.Use the repadmin /queue <domain controller> command to check how many inbound synchronizations are in the queue.
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. Top of page
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. 2.
3.
Verify connection object.
If no connection object exists, create a connection object.
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.
Top of page
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. 4.
5.
Stop the KDC on the local domain controller.
Purge the ticket cache on the local domain controller.
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.
7.
Reset the computer account password on the PDC emulator.
Synchronize the domain naming context of the replication partner with the PDC emulator. If the repadmin /showreps command shows no replication partner, see "Link Sites for Replication" in this guide for procedures to create a replication link.
8. 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. Top of page
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.
3.
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.
4.
Verify that replication is functioning.
Top of page
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. 2. See "Troubleshooting Active Directory-Related DNS Problems to identify and resolve DNS issues." See "Troubleshooting Windows Time Service Problems" to identify and resolve time synchronization issues.
3. 4.
If the RPC service is not running, start the RPC service. If the RPC service is running, stop and start the RPC service. Verify network connectivity and resolve any issues.
Top of page
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.
a.
First, locate ISTG role holders by using Ldp.exe to search for the following attributes:
b. Base DN: CN=Sites,CN=Configuration,DC=ForestRootDomainName,DC=Com c. Filter: (cn=NTDS Site Settings) d. Scope: Subtree e. Attributes: interSiteTopologyGenerator
f. 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.
2.
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.
3.
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.
2.
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.
3.
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.
4.
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.
Top of page
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:
3. 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. 4. To find which setting contains the unresolved account, type the following command at a command prompt and press ENTER:
5. 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.
6.
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

7. Repair or modify the GPO, as necessary.

Updated: March 2, 2005 Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 Active Directory replication problems can have several different sources. For example, Domain Name System (DNS) problems, networking issues, or security problems can all cause Active Directory replication to fail. Inbound or outbound replication failure causes Active Directory objects that represent the replication topology, replication schedule, domain controllers, users, computers, passwords, security groups, group memberships, and Group Policy to be inconsistent between domain controllers. Directory inconsistency causes either operational failures or inconsistent results, depending on the domain controller that is contacted for the operation at hand. Active Directory depends on network connectivity, name resolution, authentication and authorization, the directory database, the replication topology, and the replication engine. When the root cause of a replication problem is not immediately obvious, determining the cause among the many possible causes requires systematic elimination of probable causes.
Event and Tool Solution Recommendations

Ideally, the red (Error) and yellow (Warning) events in the Directory Service event log suggest the specific constraint that is causing replication failure on the source or destination domain controller. If the event message suggests steps for a solution, try the steps listed in the event. The Repadmin tool and other diagnostic tools also provide information that can help you resolve replication failures.
Ruling Out the Obvious

Sometimes replication errors occur because of intentional disruptions. For example, when you troubleshoot Active Directory replication problems, rule out intentional disconnections and hardware failures or upgrades first. Intentional Disconnections If replication errors are reported by a domain controller that is attempting replication with a domain controller that has been built in a staging site and is currently offline awaiting its deployment in the final production site (remote), you can account for those errors. To avoid separating a domain controller from the replication topology for extended periods, which causes continuous errors until the domain controller is reconnected, consider adding such computers initially as member servers and using the install-frommedia method to install Active Directory. You can back up an up-to-date domain controller to removable media (CD/DVD or other media) and ship the media to the destination site. Then, you can use the media to promote the domain controllers at the site, without requiring replication. For more information about installing from media, see Installing a Domain Controller in an Existing Domain Using Restored Backup Media. Hardware Failures or Upgrades If replication problems occur as a result of hardware failure (for example, failure of the motherboard, disk subsystem, or hard drive), notify the server owner so that the hardware problem can be resolved. Periodic hardware upgrades can also cause domain controllers to be out of service. Ensure that your server owners have a good system of communicating such outages in advance.
Correct Response to Any Outdated Server Running Windows 2000 Server

If a domain controller running Windows 2000 Server has failed for longer than the number of days in the tombstone lifetime, the solution is always the same: 1. 2. Move the server from the corporate network to a private network. Either forcefully remove Active Directory or reinstall the operating system.
3.
Remove the server metadata from Active Directory so that the server object cannot be revived.
Note By default, NTDS Settings objects that are deleted are revived automatically for a period of 14 days. Therefore, if you do not remove server metadata (use Ntdsutil to perform metadata cleanup), the server metadata is reinstated in the directory, which prompts replication attempts to occur. In this case, errors will be logged persistently as a result of the inability to replicate with the missing domain controller.
Root Causes
If you rule out intentional disconnections, hardware failures, and outdated Windows 2000 domain controllers, the remainder of replication problems almost always have one of the following root causes:
Network connectivity: The network connection might be unavailable or network settings are not configured properly.
Name resolution: DNS misconfigurations are a common cause for replication failures. Authentication and authorization: Authentication and authorization problems cause "Access denied" errors when a domain controller tries to connect to its replication partner.
Directory database (store): The directory database might not be able to process transactions fast enough to keep up with replication timeouts.
Replication engine: If intersite replication schedules are too short, replication queues might be too large to process in the time that is required by the outbound replication schedule. In this case, replication of some changes can be stalled indefinitely potentially, long enough to exceed the tombstone lifetime.
Replication topology: Domain controllers must have intersite links in Active Directory that map to real wide area network (WAN) or virtual private network (VPN) connections. If you create objects in Active Directory for the replication topology that are not supported by the actual site topology of your network, replication that requires the misconfigured topology fails.
General Approach to Fixing Problems

Use the following general approach to fixing replication problems: 1. 2. Monitor replication health daily, or use Repadmin.exe to retrieve replication status daily. Attempt to resolve any reported failure in a timely manner by using the methods described in event messages and this guide. If software might be causing the problem, uninstall the software before you continue with other solutions.
3.
If the problem that is causing replication to fail cannot be resolved by any known methods, remove Active Directory from the server and then reinstall Active Directory. For more information about reinstalling Active Directory, see Decommissioning a Domain Controller.
4.
If Active Directory cannot be removed normally while connected to the network, use one of the following methods to resolve the problem:
Force Active Directory removal in Directory Services Restore Mode, clean up server metadata, and then reinstall Active Directory.
Reinstall the operating system, and rebuild the domain controller.
For more information about forcing Active Directory removal, see Forcing the Removal of a Domain Controller.
Monitoring Replication Health

Monitoring for replication failures is critical to being able to solve replication problems quickly and effectively. Use one of the following methods to monitor replication health:
Note For detailed information on how to use Repadmin, see Monitoring and Troubleshooting Active Directory Replication Using Repadmin (http://go.microsoft.com/fwlink/?LinkId=122830).
Use a monitoring application that you set to capture and report specific errors and events on a daily basis.
Use the Repadmin tool to retrieve replication status daily.
Using a Monitoring Application to Monitor Replication Health For all domain controllers in a forest, monitor replication health on a daily basis by using Microsoft Operations Manager (MOM) or an equivalent monitoring application. For information about using MOM to monitor Active Directory, see Active Directory Management Pack Technical Reference for MOM 2005 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=41369). Using Repadmin to Retrieve Replication Status Replication status is an important way for you to evaluate the status of the directory service. If replication is working without errors, you know the domain controllers that are online. You also know that the following systems and services are working:
DNS infrastructure Kerberos Windows Time service (W32time) Remote procedure call (RPC)
Network connectivity
Use Repadmin (Windows Support Tools) to monitor replication status daily by running a command that assesses the replication status of all domain controllers in your forest. The procedure generates a .csv file that you can open in Excel and filter for replication failures. Use the following procedure to retrieve the replication status of all domain controllers in the forest. Requirements
Administrative credentials: To complete this procedure, you must be a member of the Domain Admins group in the forest root domain or the Enterprise Admins group in the forest.
Tools:
Repadmin.exe (Windows Support Tools) Excel (Microsoft Office) To retrieve replication status 1. Open a command prompt, type the following command, and then press ENTER: repadmin /showrepl * /csv >showrepl.csv In Excel, on the File menu, click Open.
2. 3. 4. 5.
In Files of type, click Text Files (*.prn;*.txt;*.csv).
In Look in, navigate to showrepl.csv, and then click Open.
In the Excel spreadsheet, right-click the column heading for showrepl_COLUMNS (column A) and then click Hide. Repeat for the column labeled Transport Type. Select the row just under the column headings, and then, on the Windows menu, click Freeze Pane. Click the upper-left corner of the spreadsheet to highlight the entire spreadsheet. On the Data menu, point to Filter, and then click AutoFilter. In the heading of the Last Success column, click the down arrow, and then click Sort Ascending. In the heading of the Source DC column, click the down arrow, and then click Custom. In the Custom AutoFilter dialog box, complete the custom filter as follows:
6.
7.
8.
9.
a. b.
Under Source DC, click does not contain.
In the corresponding text box, type del to filter deleted domain controllers from the spreadsheet.
10. In the heading of the Last Failure column, click the down arrow, and then click Custom. In the
Custom AutoFilter dialog box, complete the custom filter as follows: Under Last Failure, click does not equal.
a. b.
In the corresponding text box, type 0 to filter for only domain controllers that are experiencing failures.
For every domain controller in the forest, the spreadsheet shows the source replication partner, the time that replication last occurred, and the time that the last replication failure occurred for each naming context (directory partition). By using Autofilter in Excel, you can view the replication health for working domain controllers only, failing domain controllers only, or domain controllers that are the least or most current, and you can see the replication partners that are replicating successfully.
Attempting to Resolve Problems

Replication problems are reported in event messages and in various error messages that occur when an application or service attempts an operation. Ideally, these messages are collected by your monitoring application or when you retrieve replication status. Most replication problems are identified in the event messages that are logged in the Directory Service event log. Replication problems might also be identified in the form of error messages in the output of the repadmin /showrepl command. repadmin /showrepl Error Messages That Indicate Replication Problems To identify Active Directory replication problems, use the repadmin /showrepl command as described in the previous section. The following table shows error messages that are generated by this command, along with the root causes of the errors and links to topics that provide solutions for the errors. repadmin /showrepl Error Messages Repadmin error The time since last replication with this server has exceeded the tombstone lifetime. Root cause A domain controller has failed inbound replication with the named source domain controller long enough for a deletion to have been tombstoned, replicated, and garbagecollected from Active Directory. If no items appear in the Inbound Neighbors section of the output that is generated by repadmin /showrepl, the domain controller was not able to establish replication links with another domain controller. Solution Event ID 2042: It has been too long since this machine replicated
No inbound neighbors.
Fixing Replication Connectivity Problems (Event ID 1925)
Access is denied.
A replication link exists between two domain Fixing Replication Security controllers, but replication cannot be performed Problems properly due to an authentication failure.
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 this is a DNS error, the local domain controller could not resolve the globally unique identifier (GUID)based DNS name of its replication partner.
Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Fixing Replication Security Problems Fixing Replication Connectivity Problems (Event ID 1925)
LDAP Error 49.
The domain controller computer account might Fixing Replication Security not be synchronized with the Key Distribution Problems Center (KDC). The administration tool could not contact Active Directory. Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Wait for replication to complete. This informational message indicates normal operation. Wait for replication to complete. This informational message indicates normal operation.
Cannot open LDAP connection to local host
Active Directory replication has been preempted.
The progress of inbound replication was interrupted by a higher priority replication request, such as a request generated manually with the repadmin /sync command. The domain controller posted a replication request and is waiting for an answer. Replication is in progress from this source.
Event Messages That Indicate Active Directory Replication Problems The following table lists common events that might indicate problems with Active Directory replication, along with root causes of the problems and links to topics that provide solutions for the problems. Events That Indicate Active Directory Replication Problems Event ID and source 1311 NTDS KCC
Root cause
Solution
The replication configuration Fixing Replication Topology Problems (Event ID 1311) information in Active Directory does not accurately reflect the physical topology of the network. Strict replication consistency is Fixing Replication Lingering Object Problems (Event IDs not in effect, and a lingering 1388, 1988, 2042) object has been replicated to the domain controller. The attempt to establish a replication link for a writable directory partition failed. This event can have different causes, depending on the error. Fixing Replication Connectivity Problems (Event ID 1925) Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)
1388 NTDS Replication
1925 NTDS KCC
The local domain controller has Fixing Replication Lingering Object Problems (Event IDs attempted to replicate an 1388, 1988, 2042) object from a source domain controller that is not present on the local domain controller because it may have been deleted and already garbagecollected. Replication will not
proceed for this directory partition with this partner until the situation is resolved. 2042 NTDS Replication Replication has not occurred with this partner for a tombstone lifetime, and replication cannot proceed. Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Active Directory could not Fixing Replication DNS Lookup Problems (Event IDs 1925, resolve the DNS host name of 2087, 2088) the source domain controller to an Internet Protocol (IP) address, and replication failed. Active Directory could not resolve the DNS host name of the source domain controller to an IP address, but replication succeeded. Update sequence number (USN) rollback has occurred and replication has been stopped. This error indicates an improper Active Directory restore, possibly of a virtual machine file (.vhd). Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)
For an explanation of this problem and recommendations for solutions, see Running Domain Controllers in Virtual Server 2005 on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=38330).
5805 Net Logon
A machine account failed to Fixing Replication Security Problems authenticate, which is usually caused by either multiple instances of the same computer name or the computer name not replicating to every domain controller.
For more information about replication concepts, see Active Directory Replication Technologies in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=41950).
This article describes how to use the DNSLint utility to troubleshoot Active Directory replication issues.
The Active Directory is a distributed database. It is used to store information about objects on a network and to permit users to access this information. Active Directory replication is used to synchronize partition replicas among domain controllers in an Active Directory forest. This replication process permits users to access information from wherever they are on the network. When this replication process does not work as designed, users may experience an interruption in the services that rely on information from the Active Directory: domain logon and access to network resources, such as files and printers.
Active Directory replication relies on the Domain Name System (DNS) to resolve names to IP addresses as needed. An Active Directory domain controller typically registers a variety of DNS records with its configured DNS server when its netlogon service starts. DNSLint is a Microsoft Windows utility that runs on Windows 2000-and-later operating systems. Among other uses, it can help you troubleshoot Active Directory replication issues. Specifically, it can help you determine two things:
Whether all DNS servers that are supposed to be authoritative for the root of an Active Directory forest actually have the necessary DNS records to successfully synchronize partition replicas among domain controllers in an Active Directory forest. DNSLint identifies which DNS records are missing from each authoritative DNS server.
Whether a particular Active Directory domain controller can resolve all of the necessary DNS records to successfully synchronizing partition replicas among domain controllers in an Active Directory forest. DNSLint identifies which DNS records cannot be resolved by the domain controller being tested.
Back to the top
Troubleshooting
If an Active Directory domain controller wants to replicate with another domain controller, it uses DNS to find other domain controllers. This process works as follows:
1.
The domain controller initiating the replication (DC1) queries the Active Directory in searching for its configured replication partners. These replication partners are typically defined by the Knowledge Consistency Checker (KCC), but can also be defined manually.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
244368 How to optimize Active Directory replication in a large network
DC1 knows only the name of the domain controller that it wants to replicate with (DC2). It finds a GUID in the Active Directory that matches the target domain controller's name (DC2). Note that each domain controller in the forest should have its own unique GUID.
2.
Now that DC1 knows DC2's GUID, it must find DC2's IP address so that it can connect to it across the network. To do this, DC1 uses DNS. DC1 sends a recursive DNS query to its locally configured DNS server for a CNAME record. The format of this record always matches the following
guid._msdcs.root of Active Directory forest
Where guid is the GUID that DC1 found in the Active Directory, and root of Active Directory forest is the root of the Active Directory forest. For example
91f9b084-4876-4b59-be17-59e74c340221._msdcs.reskit.com
where 91f9b084-4876-4b59-be17-59e74c340221 is a GUID and reskit.com is the root of the Active Directory forest.
DC1's locally configured DNS server should respond to the query for the CNAME with an alias. The alias is another name for the GUID. For example, the GUID 91f9b084-48764b59-be17-59e74c340221 is resolved to dc-02.reskit.com.
3.
Now that DC1 knows the alias for the GUID, it must resolve the alias to an IP address so that it can connect to DC2 across the network. DC1 sends a recursive DNS query to its locally configured DNS server for a Host (A) record that matches the name of the alias. The DNS server should respond with the IP address that has been mapped to the alias -- for example, 169.254.66.7
4.
Now that DC1 knows DC2's IP address, it can connect to DC2 over the network and replicate Active Directory data.
If this process is unsuccessful, Active Directory replication between the domain controllers is also unsuccessful, and data may become inconsistent on the domain controllers. DNSLint can help to determine whether the DNS records used in this process are in place and can be resolved.
1.
To determine whether DNS is causing an Active Directory replication problem among domain controllers in an Active Directory forest, run the following command
dnslint /ad 169.254.32.1 /s 169.254.10.22
where the /ad parameter is used to specify an Active Directory domain controller that can be used to find the GUIDs for all the domain controllers in the Active Directory forest. By default, all domain controllers in a forest should have this information. The /s option is required when you use the /ad function. The /s option is used to tell DNSLint the IP address of a DNS server that is authoritative for the _msdcs.forest root zone.
When you run this command, DNSLint first contacts the Active Directory domain controller specified after the /ad switch (169.254.32.1). This command causes DNSLint to query the Active Directory on this domain controller for all the GUIDs in the Active Directory forest. Specifically, it queries the following location in the Active Directory
CN=NTDS Settings, CN=Sites,CN=Configuration,DC=reskit,DC=com
where DC=reskit,DC=com is the root of the Active Directory forest.
This type of Lightweight Directory Access Protocol (LDAP) query requires authentication to the Active Directory. Typically, DNSLint runs under the security context of the user who ran the command. This user's credentials are used to authenticate to the Active Directory during the LDAP bind operation. If the credentials are valid and the user has access to this information in the Active Directory, the bind succeeds and the Active Directory is searched for the GUIDs. If the bind is unsuccessful, the search is not performed and the whole operation is unsuccessful. DNSLint returns an error to the user in these cases.
If a list of GUIDs is returned from the specified domain controller, DNSLint sends a DNS query to the DNS server, specified by using the /s option. In the example provided earlier in this step, DNS queries would be sent to 169.254.10.22. If this DNS server is not authoritative for the _msdcs.root of Active Directory forest, the operation may end without finding any DNS records for the GUIDs found earlier. The /s option must specify the IP
address of a DNS server that is authoritative for the _msdcs.root of Active Directory forest subdomain.
In some environments, such as those in which a DNS server that does not accept dynamic updates hosts the root zone, the _msdcs zone has been delegated to a DNS server that is not authoritative for the root of the Active Directory forest. DNSLint checks for this delegation before proceeding with next DNS queries. This step helps to avoid sending DNS queries to DNS servers that should not be tested.
DNSLint tries to discover other DNS servers that are authoritative for the root of Active Directory forest as it processes the DNS queries. After DNSLint has found DNS servers that are authoritative for the root of Active Directory forest, it queries the DNS server (or servers) for the CNAME records that it finds in the Active Directory. As it resolves each CNAME record to an alias, DNSLint also tries to resolve the glue (A) record for each alias. As mentioned earlier in this article, these DNS records are required for Active Directory replication.
DNSLint then creates a report in HTML format (and optionally a text report). The report includes all of the GUIDs found in the Active Directory, the DNS servers found to be authoritative for the root of Active Directory forest, and the results of all the CNAME and glue (A) record queries to those servers. It reports which CNAME records and which glue (A) records were missing on each DNS server. This report can be used to correct any DNS issues that may be causing Active Directory replication problems, such as missing or incorrect DNS records.
2.
To determine whether a particular Active Directory domain controller can resolve all of the DNS records needed to successfully synchronize partition replicas among domain controllers in an Active Directory forest, run the following command on the domain controller being tested:
dnslint /ad /s localhost
Because no IP address is specified after the /ad option, 127.0.0.1 is be used. This means that the domain controller will query itself for the list of GUID records. You can specify an alternative domain controller LDAP server if you want. If you specify localhost after the /s option, this tells DNSLint to use the DNS server (or servers) configured on the domain
controller that is being tested to resolve the CNAME and glue (A) records used for Active Directory replication. This specification sends recursive DNS queries to the domain controller's locally configured DNS server (or servers) to determine whether the domain controller can resolve the necessary records. This does not mean that all of the local domain controller's DNS servers are checked for these records. The domain controller's DNS server list is managed according to its default behavior. This means that the second DNS server in the list is used only if the first one does not respond. This test only determines whether a domain controller can resolve the DNS records used for Active Directory replication. No specific DNS server is tested.
The report that DNSLint generates can then be used to correct any DNS issues that may cause Active Directory replication problems, such as missing or incorrect DNS records.
The following file is available for download from the Microsoft Download Center:
Download the dnslint.v204.exe package now.
For more information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base: 119591 How to obtain Microsoft support files from online services Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.
For more information about the DNSLint utility, click the following article number to view the article in the Microsoft Knowledge Base: 321045 Description of the DNSLint utility
with ReplMon Replication Monitor is a Windows Support Tools component that can be initiated by simply entering ReplMon from Start-Run or the command window. Initially it's empty, so you have to add monitored servers. From the Edit menu on the tool bar, select "Add monitored server," then add the domain controllers you want to view. Figure 1 shows several DCs added and expanded. Figure 1
Under each server you'll see a list of naming contexts (configuration, schema, domain, forestdnszones, etc.) hosted on that DC, along with the name of the replication partner. Clicking on any of these partitions will display the replication details in the right pane. This is the information you'd get from the repadmin/showrepl command, except that you get a lot more information from other servers quickly. To get the most out of ReplMon, you should enable additional logging. Go to View Options to get the dialog shown in Figure 2. These options are pretty self explanatory, but I recommend enabling at least "Show Transitive Replication Partners and Extended Data." Then click the Status Logging tab (Figure 3) and check "Group Policy Objects" and "Display Changed Attributes when Replication Occurs." This will provide additional information in the left pane for monitored servers about GPO replication success or failure, and identifies the object that was replicated and the update sequence number (USN).
Figure 2
Figure 3
In terms of troubleshooting with ReplMon, here are my favorite selections: Go to Action-Domain-Search domain controllers for replication errors. On the ensuing screen, select the Run Search button to find all replication errors on all DCs in the domain (Figure 4). You can then save this to a text file. And it's a great way to collect all replication errors in the domain in one spot rather than having to examine many event logs.
Figure 4
Under a DC in the left pane, select one of the partitions and the associated replication partner. You can force replication between the two by selecting Action Replication Partner Synchronize with this replication partner. It is much faster than going to the Sites and Services snap-in. Go under Action Replication Partner Check current USN and unreplicated objects. This will show the replication queue for a given partition/replication partner and show objects that have not yet replicated. There are also some powerful server options. Right click a DC icon and a list of actions will be shown (Figure 5). Most are obvious and the results can be saved as text files.
Figure 5
Synchronize each directory partition (for this DC) with all servers. This includes the option to "push" replication to other DCs. No other tool does this. Show Replication Topologies -- Careful! This only shows intra-site replication topology (pretty useless). Show Group Policy Object Status -- This shows all GPOs in the domain, the GUID, the AD and Sysvol versions. It's similar to a mini GPOTool output. Show Attribute Meta-Data for Active Directory Object -- This displays attributes for a given object (originating server, version, last write time and so on). It is very similar to the repadmin/showobjmeta command, but with a very cool feature. Click on one attribute and hit the compare button. It shows you that attribute on all DCs in the domain (or forest) -- much easier than doing that with the repadmin command. And, of course you can save it to a text file. You can see DCs in the domain and global catalog servers in the enterprise. At the end of the list shown in Figure 5, there is a Properties option where there are some more cool features: FSMO Roles -- As shown in Figure 6, this tab lists all FSMO role holders, but notice the query button. NTDSUtil and various MMCs (and even Netdom) will list FSMOs, but ReplMon will query them to see if they are responsive. Inbound Replication Connections -- This offers details about each replication connection- GUID, reasons for the connection, replication partner, etc.
Figure 6
Finally, to eliminate the need to manually connect to the domain controllers each time you use ReplMon, go to File-Save Monitored List As. You can save the list of DCs in the tool to a text file (*.ini). You can also edit the file to add additional DCs. Then you can select File-Open Script and select the .ini file you saved to load the DCs. While all of these features are great, I've left the best for last -- the Status Report. Right click on the DC icon and select Generate Status Report. Keep the default options and provide a file name. This status report is a dump of all data related to replication. It evaluates DNS, replication objects, connections and so forth. You can then take the status report and construct the replication topology -- site names, DC names, site link information, as well as replication related errors and significant events. It serves as a very nice one-stop shopping list for troubleshooting Active Directory replication failure. Yes, there are a lot of sophisticated tools out there, but don't forget ReplMon. It is still a very powerful tool for monitoring and troubleshooting all aspects of Active Directory replication. Do you have an Active Directory issue or problem that you'd like Gary to write an article about? Email him at glo11749@yahoo.com. Note: Gary cannot answer each query personally or guarantee that all will be answered. However those queries that have widespread interest or involve common AD issues will be addressed.

Updated: September 26, 2008 Applies To: Windows Server 2008 Active Directory replication problems can have several different sources. For example, Domain Name System (DNS) problems, networking issues, or security problems can all cause Active Directory replication to fail.
Note A comprehensive document that describes how you can use the Repadmin tool to monitor and troubleshoot Active Directory replication is available; see Monitoring and Troubleshooting Active Directory Replication Using Repadmin (http://go.microsoft.com/fwlink/?LinkId=122830). For information about how Active Directory replication works, see the following technical references:
Active Directory Replication Model Technical Reference (http://go.microsoft.com/fwlink/? LinkId=65958)
Active Director Replication Topology Technical Reference (http://go.microsoft.com/fwlink/? LinkId=93578)
Inbound or outbound replication failure causes Active Directory objects that represent the replication topology, replication schedule, domain controllers, users, computers, passwords, security groups, group memberships, and Group Policy to be inconsistent between domain controllers. Directory inconsistency causes either operational failures or inconsistent results, depending on the domain controller that is contacted for the operation. Active Directory Domain Services (AD DS) depends on network connectivity, name resolution, authentication and authorization, the directory database, the replication topology, and the replication engine. When the root cause of a replication problem is not immediately obvious, determining the cause among the many possible causes requires systematic elimination of probable causes. In this topic
Event and tool solution recommendations Ruling out intentional disruptions or hardware failures Root causes General approach to fixing problems Using Repadmin to retrieve replication status Replication problems and resolutions Event messages that indicate Active Directory replication problems
Event and tool solution recommendations

Ideally, the red (Error) and yellow (Warning) events in the Directory Service event log suggest the specific constraint that is causing replication failure on the source or destination domain controller. If the event message suggests steps for a solution, try the steps that are described in the event. The Repadmin tool and other diagnostic tools also provide information that can help you resolve replication failures. For detailed information about using Repadmin for troubleshooting replication problems, see Monitoring and Troubleshooting Active Directory Replication Using Repadmin (http://go.microsoft.com/fwlink/? LinkId=122830).
Ruling out intentional disruptions or hardware failures

Sometimes replication errors occur because of intentional disruptions. For example, when you troubleshoot Active Directory replication problems, rule out intentional disconnections and hardware failures or upgrades first. Intentional disconnections If replication errors are reported by a domain controller that is attempting replication with a domain controller that has been built in a staging site and is currently offline awaiting its deployment in the final production site (a remote site, such as a branch office), you can account for those replication errors. To avoid separating a domain controller from the replication topology for extended periods, which causes continuous errors until the domain controller is reconnected, consider adding such computers initially as member servers and using the install from media (IFM) method to install Active Directory Domain Services (AD DS). You can use the Ntdsutil command-line tool to create installation media that you can store on removable media (CD, DVD, or other media) and ship to the destination site. Then, you can use the installation media to install AD DS on the domain controllers at the site, without the use of replication. For more information about IFM, see Installing an Additional Domain Controller by Using IFM. Hardware failures or upgrades If replication problems occur as a result of hardware failure (for example, failure of a motherboard, disk subsystem, or hard drive), notify the server owner so that the hardware problem can be resolved. Periodic hardware upgrades can also cause domain controllers to be out of service. Ensure that your server owners have a good system of communicating such outages in advance. Firewall configuration By default, Active Directory replication remote procedure calls (RPCs) occur dynamically over an available port through the RPC Endpoint Mapper (RPCSS) on port 135. Make sure that Windows Firewall with Advanced Security and other firewalls are configured properly to allow for replication. For information about specifying the port for Active Directory replication and port settings, see article 224196 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=22578). For information about the ports that Active Directory replication uses, see Active Directory Replication Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=123774). For information about managing Active Directory replication over firewalls, see Active Directory Replication over Firewalls (http://go.microsoft.com/fwlink/? LinkId=123775).
Responding to failure of an outdated server running Windows 2000 Server

If a domain controller running Windows 2000 Server has failed for longer than the number of days in the tombstone lifetime, the solution is always the same: 1. 2. 3. Move the server from the corporate network to a private network. Either forcefully remove Active Directory or reinstall the operating system. Remove the server metadata from Active Directory so that the server object cannot be revived.
Note You can use a script to clean up server metadata on most Windows operating systems. For information about using this script, see Remove Active Directory Domain Controller Metadata (http://go.microsoft.com/fwlink/?LinkID=123599). By default, NTDS Settings objects that are deleted are revived automatically for a period of 14 days. Therefore, if you do not remove server metadata (use Ntdsutil or the script mentioned previously to perform metadata cleanup), the server metadata is reinstated in the directory, which prompts replication attempts to occur. In this case, errors will be logged persistently as a result of the inability to replicate with the missing domain controller.
Root causes
If you rule out intentional disconnections, hardware failures, and outdated Windows 2000 domain controllers, the remainder of replication problems almost always have one of the following root causes:
Network connectivity: The network connection might be unavailable, or network settings are not configured properly.
Name resolution: DNS misconfigurations are a common cause of replication failures. Authentication and authorization: Authentication and authorization problems cause "Access denied" errors when a domain controller tries to connect to its replication partner.
Directory database (store): The directory database might not be able to process transactions fast enough to keep up with replication time-outs.
Replication engine: If intersite replication schedules are too short, replication queues might be too large to process in the time that is required by the outbound replication schedule. In this case, replication of some changes can be stalled indefinitelypotentially, long enough to exceed the tombstone lifetime.
Replication topology: Domain controllers must have intersite links in AD DS that map to real wide area network (WAN) or virtual private network (VPN) connections. If you create objects in AD DS for the replication topology that are not supported by the actual site topology of your network, replication that requires the misconfigured topology fails.
General approach to fixing problems

Use the following general approach to fixing replication problems: 1. 2. Monitor replication health daily, or use Repadmin.exe to retrieve replication status daily. Attempt to resolve any reported failure in a timely manner by using the methods that are described in event messages and this guide. If software might be causing the problem, uninstall the software before you continue with other solutions.
3.
If the problem that is causing replication to fail cannot be resolved by any known methods, remove AD DS from the server and then reinstall AD DS. For more information about reinstalling
AD DS, see Decommissioning a Domain Controller (http://go.microsoft.com/fwlink/? LinkId=128290). 4. If AD DS cannot be removed normally while the server is connected to the network, use one of the following methods to resolve the problem:
Force AD DS removal in Directory Services Restore Mode (DSRM), clean up server metadata, and then reinstall AD DS.
Reinstall the operating system, and rebuild the domain controller.
For more information about forcing removal of AD DS, see Forcing the Removal of a Domain Controller (http://go.microsoft.com/fwlink/?LinkId=128291).
Using Repadmin to retrieve replication status

Replication status is an important way for you to evaluate the status of the directory service. If replication is working without errors, you know the domain controllers that are online. You also know that the following systems and services are working:
DNS infrastructure Kerberos authentication protocol Windows Time service (W32time) Remote procedure call (RPC) Network connectivity
Use Repadmin to monitor replication status daily by running a command that assesses the replication status of all the domain controllers in your forest. The procedure generates a .csv file that you can open in Microsoft Excel and filter for replication failures. You can use the following procedure to retrieve the replication status of all domain controllers in the forest. Requirements
Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
Tools:
Repadmin.exe Excel (Microsoft Office)
To generate a repadmin /showrepl spreadsheet for domain controllers 1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue. 2. At the command prompt, type the following command, and then press ENTER:
repadmin /showrepl * /csv >showrepl.csv

3. Open Excel. Click the Office button, click Open, navigate to showrepl.csv, and then click Open.
4. 5.
6.
Hide or delete column A as well as the Transport Type column, as follows:
Select a column that you want to hide or delete. To hide the column, right-click the column, and then click Hide.
Or
To delete the column, right-click the selected column, and then click Delete.
7.
Select row 1 beneath the column heading row. On the View tab, click Freeze Panes, and then click Freeze Top Row. Select the entire spreadsheet. On the Data tab, click Filter.
8. 9.
In the Last Success Time column, click the down arrow, and then click Sort Ascending.
10. In the Source DC column, click the filter down arrow, point to Text Filters, and then click
Custom Filter.
11. In the Custom AutoFilter dialog box, under Show rows where, click does not contain. In the
adjacent text box, type del to eliminate from view the results for deleted domain controllers.
12. Repeat step 11 for the Last Failure Time column, but use the value does not equal, and then
type the value 0. 13. Resolve replication failures.
For every domain controller in the forest, the spreadsheet shows the source replication partner, the time that replication last occurred, and the time that the last replication failure occurred for each naming context (directory partition). By using Autofilter in Excel, you can view the replication health for working domain controllers only, failing domain controllers only, or domain controllers that are the least or most current, and you can see the replication partners that are replicating successfully.
Replication problems and resolutions

Replication problems are reported in event messages and in various error messages that occur when an application or service attempts an operation. Ideally, these messages are collected by your monitoring application or when you retrieve replication status. Most replication problems are identified in the event messages that are logged in the Directory Service event log. Replication problems might also be identified in the form of error messages in the output of the repadmin /showrepl command. repadmin /showrepl error messages that indicate replication problems To identify Active Directory replication problems, use the repadmin /showrepl command, as described in the previous section. The following table shows error messages that this command generates, along with the root causes of the errors and links to topics that provide solutions for the errors.
Repadmin error The time since last replication with this server has exceeded the tombstone lifetime.
Root cause A domain controller has failed inbound replication with the named source domain controller long enough for a deletion to have been tombstoned, replicated, and garbagecollected from AD DS.
Solution Event ID 2042: It has been too long since this machine replicated
No inbound neighbors.
If no items appear in the Inbound Neighbors Fixing Replication section of the output that is generated by Connectivity Problems repadmin /showrepl, the domain controller (Event ID 1925) was not able to establish replication links with another domain controller. A replication link exists between two domain controllers, but replication cannot be performed properly as a result of an authentication failure. This problem can be related to connectivity, DNS, or authentication issues. If this is a DNS error, the local domain controller could not resolve the globally unique identifier (GUID)based DNS name of its replication partner. Fixing Replication Security Problems
Access is denied.
Last attempt at <date time> failed with the Target account name is incorrect.
Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Fixing Replication Security Problems Fixing Replication Connectivity Problems (Event ID 1925)
LDAP Error 49.
The domain controller computer account might Fixing Replication Security not be synchronized with the Key Distribution Problems Center (KDC). The administration tool could not contact AD DS. Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) Wait for replication to complete. This
Cannot open LDAP connection to local host
Active Directory replication has been preempted.
The progress of inbound replication was interrupted by a higher-priority replication
request, such as a request that was generated informational message manually with the repadmin /sync indicates normal operation. command. 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. This informational message indicates normal operation.
Event messages that indicate Active Directory replication problems The following table lists common events that might indicate problems with Active Directory replication, along with root causes of the problems and links to topics that provide solutions for the problems.
Event ID and source Root cause 1311 NTDS KCC The replication configuration information in AD DS does not accurately reflect the physical topology of the network.
Solution Fixing Replication Topology Problems (Event ID 1311) Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Strict replication consistency is not in effect, and a lingering object has been replicated to the domain controller.
1925 NTDS KCC
The attempt to establish a replication link for a writable Fixing Replication directory partition failed. This event can have different causes, Connectivity Problems depending on the error. (Event ID 1925) Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) The local domain controller has attempted to replicate an object from a source domain controller that is not present on the local domain controller because it may have been deleted and already garbage-collected. Replication will not proceed for this directory partition with this partner until the situation is resolved. Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Replication has not occurred with this partner for a tombstone Fixing Replication lifetime, and replication cannot proceed. Lingering Object Problems (Event IDs 1388, 1988, 2042) AD DS could not resolve the DNS host name of the source domain controller to an IP address, and replication failed. Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)
AD DS could not resolve the DNS host name of the source Fixing Replication DNS domain controller to an IP address, but replication succeeded. Lookup Problems (Event IDs 1925, 2087, 2088) A machine account failed to authenticate, which is usually caused by either multiple instances of the same computer name or the computer name not replicating to every domain controller. Fixing Replication Security Problems
5805 Net Logon
For more information about replication concepts, see Active Directory Replication Technologies in the Windows Server 2003 Technical Reference (http://go.microsoft.com/fwlink/?LinkId=41950).
Active Directory Operations Overview

Updated: January 06, 2003 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 Net Logon Event ID 5805 NTDS Event ID 1083 NTDS Event ID 1265 Root Cause 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. Solution If you do not find multiple instances of the computer name, verify that replication is functioning for the domain that contains the computer account.
A duplicate object is present in the Active Directory See "Troubleshooting Directory Data of the replication partner of the local domain Problems" in this guide. controller, so updating it is impossible. 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 Troubleshoot NTDS event ID 1311. information in Active Directory Sites and Services does not accurately reflect the physical topology of the network. This error is usually generated by a lingering object If the domain controller does not also which resulted from disconnecting a domain function as a global catalog server, see controller for too long. "Remove Lingering Objects from an
NTDS Event ID 1388
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 Troubleshoot GUID discrepancies. 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. A user account in one or more Group Policy objects Troubleshoot SceCli event ID 1202. (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.
SceCli event ID 1202
Top of page
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 No inbound neighbors. Root Cause Solution
If no items appear in the "Inbound See "Troubleshoot No Inbound Neighbors Neighbors" section of the output Repadmin.exe Error." generated by the repadmin /showreps command, the domain controller was not able to establish replication links with another domain controller. A replication link exists between two domain controllers, but replication cannot be properly performed. 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. 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. The domain controller computer See "Troubleshoot Access Denied Replication Errors."
Access is denied.
Last attempt at <date - time> failed with the "Target account name is incorrect."
See "Troubleshooting Active DirectoryRelated DNS Problems." Also see "Troubleshoot Access Denied Replication Errors."
No more end point.
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.
See "Troubleshoot Access Denied
account might not be synchronized withthe Key Distribution Center (KDC). Cannot open LDAP connection to local host. AD replication has been preempted. The administration tool could not contact Active Directory.
Replication Errors."
See "Troubleshooting Active DirectoryRelated DNS Problems."
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. The domain controller posted a replication request and is waiting for an answer. Replication is in progress from this source.
Last attempt @never was successful.
The KCC successfully
Synchronize replication from a
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.
source domain controller.Use the repadmin /queue <domain controller> command to check how many inbound synchronizations are in the queue.
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. Top of page
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. 2.
3.
Verify connection object.
If no connection object exists, create a connection object.
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.
Top of page
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. 4.
5.
Stop the KDC on the local domain controller.
Purge the ticket cache on the local domain controller.
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.
7.
Reset the computer account password on the PDC emulator.
Synchronize the domain naming context of the replication partner with the PDC emulator. If the repadmin /showreps command shows no replication partner, see "Link Sites for Replication" in this guide for procedures to create a replication link.
8. 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. Top of page
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.
3.
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.
4.
Verify that replication is functioning.
Top of page
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. 2. See "Troubleshooting Active Directory-Related DNS Problems to identify and resolve DNS issues." See "Troubleshooting Windows Time Service Problems" to identify and resolve time synchronization issues.
3. 4.
If the RPC service is not running, start the RPC service. If the RPC service is running, stop and start the RPC service. Verify network connectivity and resolve any issues.
Top of page
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.
a.
First, locate ISTG role holders by using Ldp.exe to search for the following attributes:
b. Base DN: CN=Sites,CN=Configuration,DC=ForestRootDomainName,DC=Com c. Filter: (cn=NTDS Site Settings) d. Scope: Subtree e. Attributes: interSiteTopologyGenerator
f. 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.
2.
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.
3.
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.
2.
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.
3.
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.
4.
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.
Top of page
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:
3. 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. 4. To find which setting contains the unresolved account, type the following command at a command prompt and press ENTER:
5. 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.
6.
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

7. Repair or modify the GPO, as necessary.
Replication Monitor HowTo

By Brian Gibson What is Replmon.exe? Replmon is the first tool you should use when troubleshooting Active Directory replication issues. As it is a graphical tool, replication issues are easy to see and somewhat easier to diagnose than using its command line counterparts. The purpose of this document is to guide you in how to use it, list some common replication errors and show some examples of when replication issues can stop other network installation actions. The Microsoft definition of the Replmon tool is as follows; This GUI tool enables administrators to view the low-level status of Active Directory replication, force synchronization between domain controllers, view the topology in a graphical format, and monitor the status and performance of domain controller replication. Symptoms of Replication Faults
Failure to extend the schema The Active Directory schema has to be extended for many reasons. Two of the most common are: o When installing an Exchange 200x server (by running setup.exe /forestprep and /domainprep) o When adding a 2003 Domain Controller to a Windows 2000 Active Directory network (by running adprep /forestprep and /domainprep). If there is a replication issue with any of the domain controllers on the Schema partition, the Schema will not allow any extension.
Failure to DCPromo a new Domain Controller When installing a new Domain Controller, the wizard waits until Active Directory is fully synchronised before continuing. Replication issues would cause this to hang at this point. (Although it can be forced to wait until later, this would only put off the problem). Installation of Active Directory aware software Software that creates a new user account per network or writes to the Active Directory could fail or produce ambiguous errors when replication issues exist on the network. Any recent warnings or errors in the File Replication Service log in Event Viewer Any recent NTDS Replication Errors in the Directory Service log in Event Viewer
How to Use Replmon To use Replmon logon to a Domain Controller, select Start|Run, type Replmon, and click OK. You will be presented with the following screen:
Right click on the Monitored Servers icon and select Add Monitored Server... Select the Search the directory for the server to add radio button. Ensure the correct domain populates in drop down list, and click Next.
Select an appropriate server from the list of Domain Controllers

If you know you are experiencing issues with a particular domain controller, choose that server. If you are checking general replication, or are not sure where the fault lies, choose the Forest Root. On larger networks, you will need to choose more than one server depending on the replication topology. (For information on viewing the replication topology, see Appendix A) and click Finish.
If your Active Directory contains only Windows 2000 domain controllers, you will see three Directory partitions.
If your Active Directory Forest Root is Windows 2003 you will see five Directory partitions.
By expanding the + on each directory partition you will be able to see each of the servers replication partners. Selecting one on the left shows the last replication attempt in the right hand pane.
If there are any replication issues the partitions on the domain controller the server cannot replicate with will show a red x.
Highlighting one of the problem replication partner servers will then show more verbose error messages in the logs pane explaining why it could not replicate.
Troubleshooting Replication Issues Step 1: Check validity of replication partners Perhaps an obvious step, but there can be replication issues when there are servers present in the replication topology that are no longer connected to the network. Look for replication agreements with non-existent servers, servers that have been forcibly removed from the domain or are simply turned off. Step 2: Force replication The last scheduled replication attempt could have failed for unaccountable reasons, but the failure cause may no longer be an issue. Get an accurate current understanding of the situation by right clicking on the replication partner server in each of the partitions and selecting Synchronise with this Replication Partner.
Then refresh the Tree view by pressing F5. Re-check the replication status in the right hand logs pane. Step 3: General IP checks Doesnt matter if youve done them, do them all again now! From a command prompt:
Can you ping the IP address of the destination server? e.g. Ping 192.168.3.201 If not: The issue will either be hardware (cable, switch, NIC, check all physical connections) or incorrect configuration of a servers (either destination or host server) IP details. Check the NICs IP address and Subnet Mask. Can you ping the netbios name of the destination server? e.g. Ping Replicadc1 If not: The issue will be a name resolution issue. Check there is an A host entry in the domains Forward Lookup zone. Check the NIC IP properties and ensure the Forest Root IP is entered as the Preferred DNS Server. Can you ping the FQDN of the destination server? e.g. Ping Replicadc1.RMTDS.Internal If not: The issue will be a DNS issue. Check as above, also
check the NICs IP Advanced Properties and ensure the correct DNS Suffix is being used. Open the DNS admin console and ensure there is a populated Forward Lookup zone for the domain. Can you reverse lookup the IP of the destination server? e.g. Ping a 192.168.3.201 If not: You have a reverse lookup zone issue. Open the DNS admin console and check for the existence of a Reverse Lookup zone per Class C IP range. e.g. 10.0.0.x Subnet 10.0.1.x Subnet Check there is a valid PTR record for each of the Domain Controllers in the relevant Reverse lookup zone.
Appendix A Other Replmon functions By right clicking the server you have selected to view Replication agreements from, you will see a range of options. A few of them are detailed below.
Update Status This will recheck the replication status of the server. The time of the updated status is logged and displayed in
the right hand pane. Check Replication Topology This will cause the Knowledge Consistency Checker (KCC) to recalculate the replication topology for the server. Synchronize Each Directory Partition with All Servers This will start immediate replication for all of the servers directory partitions with each replication partner. Generate Status Report - Creates and saves a verbose status report in the form of a log file. Show Domain Controllers in Domain will show a list of all known Domain Controllers. Show Replication Topologies - will show a graphical view of the replication topology. Click View on the menu and select Connection Objects only. Then right click each server, and select Show Intra/Inter-site connections. Show Group Policy Object Status shows a list of all the Domains Group Policies and their respective AD and Sysvol version numbers.

Troubleshooting Active Directory Replication Problems

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Troubleshooting Active Directory Replication Problems

Uploaded by

Copyright:

Available Formats

Troubleshooting Active Directory Replication Problems

NTDS Event ID 1311

NTDS Event ID 1388

SceCli event ID 1202

General Guidelines for Troubleshooting Replication Problems

No more end point.

LDAP Error 49.

See "Troubleshoot Access Denied Replication Errors."

Wait for replication to complete.

Replication posted, waiting.

Wait for replication to complete.

Last attempt @never was successful.

The KCC successfully

Synchronize replication from a

A large backlog of inbound

Troubleshooting No Inbound Neighbors Repadmin.exe Error

Procedures for Troubleshooting No Inbound Neighbors

Verify connection object.

If no connection object exists, create a connection object.

Troubleshooting Access Denied Replication Errors

Stop the KDC on the local domain controller.

Purge the ticket cache on the local domain controller.

Reset the computer account password on the PDC emulator.

Synchronize replication from a source domain controller.

10. Start the KDC on the local domain controller.

Troubleshooting GUID Discrepancies

Verify that replication is functioning.

Troubleshooting RPC Server Problems

Troubleshooting NTDS Event ID 1311

Troubleshooting SceCli Event ID 1202

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

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

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