50269296 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 Root Cause Solution

Net Logon Event ID 5805

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

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

NTDS Event ID 1083

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

See "Troubleshooting Directory Data Problems" in this guide.

NTDS Event ID 1265

Replication failed for the reason stated in the message text.

Use Repadmin.exe to further identify the problem, and use Table x.x to determine the appropriate action to take for the message generated by Repadmin.exe.If the event message indicates a DNS lookup failure or the RPC server is unavailable, see "Troubleshooting Active Directory-Related DNS Problems" in this guide.If the event message indicates that the target account name is incorrect, troubleshoot GUID discrepancies.If the event message indicates a time difference between the client and server, synchronize replication from the PDC emulator.

NTDS Event ID 1311

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

Troubleshoot NTDS event ID 1311.

NTDS Event ID 1388

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

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

http://technet.microsoft.com/en-us/library/bb727055.aspx






http://technet.microsoft.com/en-us/library/bb727057.aspx#EAAA%23EAAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EBAA%23EBAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#ECAA%23ECAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EDAA%23EDAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EEAA%23EEAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EFAA%23EFAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EGAA%23EGAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EHAA%23EHAA

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

NTDS Event ID 1645

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

Troubleshoot GUID discrepancies.

SceCli event ID 1202

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

Troubleshoot SceCli event ID 1202.

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 Root Cause Solution

No inbound neighbors.

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

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

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

See "Troubleshoot Access Denied Replication Errors."

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

This problem can be related to connectivity, DNS, or authentication issues.If it is a DNS error, the local domain controller could not resolve the GUIDbased DNS name of its replication partner.

See "Troubleshooting Active Directory-Related DNS Problems."Also see "Troubleshoot Access Denied Replication Errors."

No more end point. This can be caused because no more end-points are available to establish the TCP session with the replication partner.This error can also result when the replication partner can be contacted, but its RPC interface is not registered. This usually indicates that the domain controller's DNS name is registered but with the wrong IP address.

Use Netstat to check the currently established sessions. Free up TCP sessions, if necessary.Correct the IP address and see Troubleshooting "Active Directoryrelated DNS Problems."

LDAP Error 49. The domain controller computer account might not be synchronized


http://technet.microsoft.com/en-us/library/bb727057.aspx#mainSection%23mainSection

withthe Key Distribution Center (KDC).

Cannot open LDAP connection to local host.

The administration tool could not contact Active Directory.

See "Troubleshooting Active Directory-Related DNS Problems."

AD replication has been preempted.

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

Wait for replication to complete.

Replication posted, waiting.

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


Last attempt @never was successful.

• The KCC successfully

created the replication link

between the local domain

controller and its replication

partner, but because of the

schedule or possible

bridgehead overload,

replication has not occurred.

• A large backlog of inbound

replication must be performed

on this domain controller.

• Synchronize replication from a

source domain controller.Use the

repadmin /queue <domain

controller> command to check

how many inbound synchronizations

are in the queue.

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. Verify connection object.

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

3. After you create the connection objects, see "Linking Sites for Replication" for procedures to

create a site link. Replication should occur automatically at the scheduled time.

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. Stop the KDC on the local domain controller.

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

5. Verify that the domain controller is in the Domain Controllers OU, the default domain controllers

GPO is linked to the OU, and the "access this computer from network" policy is effective in this

domain.

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

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

8. If the repadmin /showreps command shows no replication partner, see "Link Sites for

Replication" in this guide for procedures to create a replication link.

9. Synchronize replication from a source domain controller.

10. Start the KDC on the local domain controller.











11. If you get a new "access denied" error message, you must create a temporary connection link

between the domain controller and its replication partner for the naming contexts.

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. See "Troubleshooting Active Directory-Related DNS Problems to identify and resolve DNS issues."

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

synchronization issues.

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

start the RPC service.

4. Verify network connectivity and resolve any issues.

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


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.

Troubleshooting Active Directory Replication ProblemsUpdated: 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 DisconnectionsIf 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-from-media 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 UpgradesIf 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. Move the server from the corporate network to a private network.

2. Either forcefully remove Active Directory or reinstall the operating system.

http://technet.microsoft.com/en-us/library/cc779518(WS.10).aspx


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. Monitor replication health daily, or use Repadmin.exe to retrieve replication status daily.

2. 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 HealthFor 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 StatusReplication 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)

http://go.microsoft.com/fwlink/?LinkId=41369





• 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 status1. Open a command prompt, type the following command, and then press ENTER:

repadmin /showrepl * /csv >showrepl.csv

2. In Excel, on the File menu, click Open.

3. In Files of type, click Text Files (*.prn;*.txt;*.csv).

4. In Look in, navigate to showrepl.csv, and then click Open.

5. 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.

6. Select the row just under the column headings, and then, on the Windows menu, click Freeze

Pane.

7. Click the upper-left corner of the spreadsheet to highlight the entire spreadsheet. On the Data

menu, point to Filter, and then click AutoFilter.

8. In the heading of the Last Success column, click the down arrow, and then click Sort

Ascending.

9. 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:

a. Under Source DC, click does not contain.

b. 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:

a. Under Last Failure, click does not equal.

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 ProblemsTo 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 Root cause Solution

The time since last replication with this server has exceeded the tombstone lifetime.

A domain controller has failed inbound replication with the named source domain controller long enough for a deletion to have been tombstoned, replicated, and garbage-collected from Active Directory.

Event ID 2042: It has been too long since this machine replicated

No inbound neighbors. 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.

Fixing Replication Connectivity Problems (Event ID 1925)

Access is denied. A replication link exists between two domain controllers, but replication cannot be performed properly due to an authentication failure.

Fixing Replication Security Problems









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 not be synchronized with the Key Distribution Center (KDC).


Cannot open LDAP connection to local host


Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)

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.

Wait for replication to complete. This informational message indicates normal operation.




Event Messages That Indicate Active Directory Replication ProblemsThe 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 Root cause Solution

1311 — NTDS KCC

The replication configuration information in Active Directory does not accurately reflect the physical topology of the network.

Fixing Replication Topology Problems (Event ID 1311)

1388 — NTDS Replication

Strict replication consistency is not in effect, and a lingering object has been replicated to the domain controller.

Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)

1925 — NTDS KCC

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)


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.


Replication has not occurred with this partner for a tombstone lifetime, and replication cannot proceed.



Active Directory could not resolve the DNS host name of 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).

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 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.

http://support.microsoft.com/kb/321046#top%23top

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-4876-

4b59-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.

http://support.microsoft.com/kb/244368

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



http://download.microsoft.com/download/2/7/2/27252452-e530-4455-846a-dd68fc020e16/dnslint.v204.exe

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 [email protected]. 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.

mailto:[email protected]

Troubleshooting Active Directory Replication ProblemsUpdated: 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

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_event_messages%23BKMK_event_messages

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_problems_resolutions%23BKMK_problems_resolutions

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_using_repadmin%23BKMK_using_repadmin

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_general_approach%23BKMK_general_approach

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_root_causes%23BKMK_root_causes

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_ruling_out%23BKMK_ruling_out

http://64.4.11.252/en-us/library/cc949120(WS.10).aspx#BKMK_event_tool%23BKMK_event_tool






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 disconnectionsIf 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 upgradesIf 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 configurationBy 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. Move the server from the corporate network to a private network.

2. 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.





http://64.4.11.252/en-us/library/cc816722(WS.10).aspx



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 indefinitely—potentially, 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. Monitor replication health daily, or use Repadmin.exe to retrieve replication status daily.

2. 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

http://go.microsoft.com/fwlink/?LinkID=123599

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.

4. Click the Office button, click Open, navigate to showrepl.csv, and then click Open.

5. Hide or delete column A as well as the Transport Type column, as follows:

6. 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.

8. Select the entire spreadsheet. On the Data tab, click Filter.

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 problemsTo 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 Root cause Solution

The time since last replication with this server has exceeded the tombstone lifetime.

A domain controller has failed inbound replication with the named source domain controller long enough for a deletion to have been tombstoned, replicated, and garbage-collected from AD DS.

Event ID 2042: It has been too long since this machine replicated

No inbound neighbors. 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.

Fixing Replication Connectivity Problems (Event ID 1925)

Access is denied. A replication link exists between two domain controllers, but replication cannot be performed properly as a result of 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 not be synchronized with the Key Distribution Center (KDC).


Cannot open LDAP connection to local host

The administration tool could not contact AD DS.


Active Directory replication has been preempted.

The progress of inbound replication was interrupted by a higher-priority replication

Wait for replication to complete. This






















request, such as a request that was generated manually with the repadmin /sync command.

informational message indicates normal operation.




Event messages that indicate Active Directory replication problemsThe 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 Solution

1311 — NTDS KCC

The replication configuration information in AD DS does not accurately reflect the physical topology of the network.

Fixing Replication Topology Problems (Event ID 1311)


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 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)


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.



Replication has not occurred with this partner for a tombstone lifetime, and replication cannot proceed.



AD DS could not resolve the DNS host name of the source domain controller to an IP address, and replication failed.



AD DS could not resolve the DNS host name of the source domain controller to an IP address, but replication succeeded.


5805 — Net Logon

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.


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

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 Root Cause Solution

Net Logon Event ID 5805

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

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

NTDS Event ID 1083

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

See "Troubleshooting Directory Data Problems" in this guide.

NTDS Event ID 1265

Replication failed for the reason stated in the message text.

Use Repadmin.exe to further identify the problem, and use Table x.x to determine the appropriate action to take for the message generated by Repadmin.exe.If the event message indicates a DNS lookup failure or the RPC server is unavailable, see "Troubleshooting Active Directory-Related DNS Problems" in this guide.If the event message indicates that the target account name is incorrect, troubleshoot GUID discrepancies.If the event message indicates a time difference between the client and server, synchronize replication from the PDC emulator.

NTDS Event ID 1311

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

Troubleshoot NTDS event ID 1311.

NTDS Event ID 1388

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

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







http://technet.microsoft.com/en-us/library/bb727057.aspx#EAAA%23EAAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EBAA%23EBAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#ECAA%23ECAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EDAA%23EDAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EEAA%23EEAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EFAA%23EFAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EGAA%23EGAA

http://technet.microsoft.com/en-us/library/bb727057.aspx#EHAA%23EHAA

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

NTDS Event ID 1645

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

Troubleshoot GUID discrepancies.

SceCli event ID 1202

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

Troubleshoot SceCli event ID 1202.

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 Root Cause Solution

No inbound neighbors.

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

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

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


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

This problem can be related to connectivity, DNS, or authentication issues.If it is a DNS error, the local domain controller could not resolve the GUIDbased DNS name of its replication partner.

See "Troubleshooting Active Directory-Related DNS Problems."Also see "Troubleshoot Access Denied Replication Errors."

No more end point. This can be caused because no more end-points are available to establish the TCP session with the replication partner.This error can also result when the replication partner can be contacted, but its RPC interface is not registered. This usually indicates that the domain controller's DNS name is registered but with the wrong IP address.

Use Netstat to check the currently established sessions. Free up TCP sessions, if necessary.Correct the IP address and see Troubleshooting "Active Directoryrelated DNS Problems."

LDAP Error 49. The domain controller computer See "Troubleshoot Access Denied


account might not be synchronized withthe Key Distribution Center (KDC).

Replication Errors."

Cannot open LDAP connection to local host.


See "Troubleshooting Active Directory-Related DNS Problems."

AD replication has been preempted.

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





Last attempt @never was successful.

• The KCC successfully

created the replication link

between the local domain

controller and its replication

partner, but because of the

schedule or possible

bridgehead overload,

replication has not occurred.

• A large backlog of inbound

replication must be performed

on this domain controller.

• Synchronize replication from a

source domain controller.Use the

repadmin /queue <domain

controller> command to check

how many inbound synchronizations

are in the queue.

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. Verify connection object.

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

3. After you create the connection objects, see "Linking Sites for Replication" for procedures to

create a site link. Replication should occur automatically at the scheduled time.

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. Stop the KDC on the local domain controller.

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

5. Verify that the domain controller is in the Domain Controllers OU, the default domain controllers

GPO is linked to the OU, and the "access this computer from network" policy is effective in this

domain.

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

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

8. If the repadmin /showreps command shows no replication partner, see "Link Sites for

Replication" in this guide for procedures to create a replication link.

9. Synchronize replication from a source domain controller.

10. Start the KDC on the local domain controller.











11. If you get a new "access denied" error message, you must create a temporary connection link

between the domain controller and its replication partner for the naming contexts.

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. See "Troubleshooting Active Directory-Related DNS Problems to identify and resolve DNS issues."

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

synchronization issues.

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

start the RPC service.

4. Verify network connectivity and resolve any issues.

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


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


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.

http://www.mcmcse.com/microsoft/guides/replmon.shtml#%23

• 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 server’s 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 partnersPerhaps 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 replicationThe 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 checksDoesn’t matter if you’ve 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.201If not: The issue will either be hardware (cable, switch, NIC, check all physical connections) or incorrect configuration of a server’s (either destination or host server) IP details. Check the NIC’s IP address and Subnet Mask.

• Can you ping the netbios name of the destination server? e.g. Ping Replicadc1If not: The issue will be a name resolution issue. Check there is an A host entry in the domain’s 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.InternalIf not: The issue will be a DNS issue. Check as above, also

check the NIC’s 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.201If 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 Subnet10.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 server’s 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 Domain’s Group Policies and their respective AD and Sysvol version numbers.

50269296 troubleshooting active directory replication problems

Documents

registry key

systemroot

systemrootsecuritylogs

systemrootsecuritylogswinlogon

cnntds site

knowledge

istg role

temporary