NOTE: After running theMPS_Reports tool, output similar to the repadmin command appears in the computername_repadmin.txt file. For more information about MPS_Reports, refer to the following Microsoft Knowledge Base article:

Name resolution errors during Active Directory replication result in these error messages:

RPC Server is unavailable

There are no more endpoints available from the endpoint mapper.

Before troubleshooting these particular error messages, perform some general troubleshooting as described in the following section: Perform preliminary troubleshooting on name resolution errors during Active Directory replication.

The DNSLint tool is a Microsoft utility that runs on Microsoft Windows 2003 and earlier operating systems. Among its other uses, DNSLint can help troubleshoot Active Directory replication issues. For more information concerning DNSLint, refer to the following Microsoft Knowledge Base article:

ID:321046Title: How To Use DNSLint to Troubleshoot Active Directory Replication Issues

Troubleshoot Active Directory RPC Server Unavailable errors.

To troubleshoot RPC server is unavailable errors, it is important to understand name resolution configuration within the environment. In general, determine which servers are authoritative for the zone and how the client is configured to retrieve the DNS records.

NOTE:

In most cases, the client should only refer to DNS servers that can resolve the internal domain name.

Verify the following specific configurations:

Client Configuration

DNS Server Configuration

Zone Delegation

Internal Root Servers

DNS Records Registration

Verify the client DNS configuration in an Active Directory environment.

To verify the client DNS configuration, perform these procedures:

Check the local DNS settings in the TCP/IP settings for the client’s network adapter.

Verify that the client is not referring to an Internet Service Provider for the Preferred or Alternate DNS server.

NOTE:

ISPs do not normally register the service resource records (SRV) required to locate a domain controller.

NOTE:

Clients should only refer to internal DNS servers able to resolve the internal domain. The internal DNS server should resolve Internet names for the clients, which is often done by configuring forwarders on the internal DNS server. For more information on the Domain Name Resolver Client, refer to the following Microsoft Knowledge Base article:

ID:261968Title: Explanation of the Server List Management Feature in the Domain Name Resolver Client

Verify the Domain Name Server (DNS) configuration in an Active Directory environment.

To verify proper DNS server configuration, perform these procedures:

Determine if the DNS server in a child domain is forwarded to a DNS server in a parent or root domain.
Determine if the child DNS server is configured with a secondary zone for the parent domain.

Check for improperly configured forwarders. If the forwarder is unable to resolve records for the zone, query it directly using nslookup to verify that the forwarder configuration is the problem.

Verify that the DNS server is not configured to forward to a non-recursive DNS server.
To verify this, check the DNS Flags field in a network trace response from a forwarder.

NOTE: On a Windows Server 2003 system, the DNS server can be configured to forward queries for a specific domain to a specific domain server. This is also known as conditional forwarding. For more information on conditional forwarding, refer to the following Microsoft Knowledge Base article:

Ensure that the child zone is properly delegated from the parent. A Name Server (NS) record should exist in the parent domain for the child domain.

Ensure that the zone has not been delegated to a DNS server that is non-authoritative for that zone. Refer to the section on delegation in the Microsoft Knowledge Base article below.

NOTE:

The exception to this is if the child and parent domains are part of the same zone on the same DNS server. For more information on child to parent zone delegations, refer to the following Microsoft Knowledge Base articles:

ID: 255248Title: How To Create a Child Domain in Active Directory and Delegate the DNS Namespace to the Child Domain

Verify registration of DNS records in an Active Directory Environment

To verify the proper registration of DNS records, perform these steps:

Verify the configuration settings on the client and zone, as discussed in previous sections.

Delete netlogon.dns and netlogon.dnb files on the domain controller and restart the Net Logon service.

If a domain controller is not registering a globally unique identifier (GUID), the Net Logon service will log event 5774 referencing the SRV record. Check for a Mail Exchange (MX) record wildcard entry. For information concerning MX record wildcard entries, refer to the Microsoft Knowledge Base article below:

ID: 325208 Title: GUID Records Are Not Registered If MX Record with Wildcard Character Is Present

Determine if the domain controller has disjointed namespace.

NOTE:

For more information on determining disjointed namespace on a domain controller, refer to the following Microsoft Knowledge Base article:

ID: 257623 Title: Domain Controller's Domain Name System Suffix Does Not Match Domain Name

Verify that the RegisterDNSARecords value in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters registry key is set to 1.

NOTE: If the SRV records are properly registering and Net Logon A records are not, verify that the UseDynamicDNS value in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters registry key is set to 1.

Verify that domain controllers that are replication partners in the affected domain have their GUID's registered in the forest root zone.

Records for global catalog servers are registered in the forest root domain, regardless of whether the domain controller is in a child domain or a different tree of the forest. The forest root domain is the first domain created in the forest.

Domain controllers attempting to replicate will initiate a query to Active Directory for their configured replication partner and GUID. They then initiate a DNS query for the CNAME record for the GUID, similar to the record in the example above. If the GUID is not present in the DNS zone, the domain controller will not replicate with that partner.

Ensure that each domain controller has a host record registered for their name (CNAME) in the DNS zone record.

Verify that both domain controllers involved in the Active Directory replication can resolve DNS records for each other.

If there are replication problems in the forest root zone, verify that domain controllers are not pointing to themselves for DNS resolution.

NOTE: As a rule, only one domain controller in the forest root domain should be pointed to itself as either a Preferred or an Alternate DNS server in their TCP/IP properties settings. All other domain controllers should be pointed to DNS servers other than themselves. For more information concerning domain controllers referring to themselves for DNS resolution, refer to the Microsoft Knowledge Base article below:

ID: 275278Title: DNS Server Becomes an Island When a Domain Controller Points to Itself for the _Msdcs.ForestDnsName Domain

NOTE: For more information concerning portqry, refer to the following Microsoft Knowledge Base article:

ID: 310456 Title: How to Use Portqry to Troubleshoot Active Directory Connectivity Issues

Test for black hole issues in an Active Directory environment.

Black hole router issues may occur when a network router receives a packet larger than the Maximum Transfer Unit (MTU) of the next network segment and that packet has the IP layer "don’t fragment" (DF) bit flagged. In this case, the router sends a Internet Control Message Protocol (ICMP) destination unreachable message back to the sending host. If the ICMP message is not sent, packets can be dropped causing errors that vary with the application communicating over the failed link.

Use the ping command with the DF flag (-f) and the buffer size parameter (-l) to test for black hole routers. For example:

pingcomputername-or-ipaddress-f -l 1472

(where computername-or-ipaddress is the domain name or IP address of the computer you wish to test)

This command sends a packet of size of 1472 bytes to another computer and commands all network devices relaying this request to not fragment the packet.

By successively increasing the packet size (with the -l parameter), the maximum MTU can be determined for the interposing network. Thus, if a ping packet of MTU 1472 is successful and a ping packet of MTU 1473 fails, the maximum MTU for the link is 1500 bytes (1472 bytes plus 28 bytes of ICMP headers).

NOTE:

For more information on testing for black hole router issues using the ping command, refer to the following Microsoft Knowledge Base article:

To check for Kerberos fragmentation, type the following where computername-or-ipaddress is the domain name or IP address of the node you wish to test:

pingcomputername-or-ipaddress-f -l 1500

Increase the packet size parameter (-l) until the ping fails. If the ping fails before a packet size of 2000, then the Kerberos packets are probably being fragmented before reaching their destination node.

NOTE:

For more information concerning Kerberos packet fragmentation, refer to the following Microsoft Knowledge Base article:

When an Active Directory replication between two domain controllers fails, the following error message may display in the Event Log:

The RPC server is too busy to complete this operation.

This is typically caused by incorrect time synchronization.

Synchronize the time between domain controllers in an Active Directory environment.

To synchronize the time between domain controllers, perform one of these procedures:

On the local computer, type the following command where pdc-emulator is the primary domain controller emulator that holds the operations master role:

net time \\pdc-emulator/set /y

Use the W32tm tool to determine if a time server is explicitly configured for the local computer and if synchronizations against the host are not working. Type the following command on the server displaying the error:

w32tm -v

This sample output depicts a time server (DC01) that is unreachable by the local computer:

Click the Find People button, and then select Active Directory from the Look In box.

Type in a valid user name, and then click Find Now.
The user name appears.

If the global catalog is unavailable, follow the procedures outlined in the following sections:

Verify there is a global catalog configured in the client’s site.

Check the directory service event log for global catalog events.

Determine what partitions have not yet replicated.

Determine if the global catalog or domain controller is experiencing performance issues.

Verify that port 3268 is available on the network for the global catalog server.

Verify a global catalog server is configured in the client’s site

To verify that a global catalog server is configured in the client’s site, open the Active Directory Sites and Services and check the properties of the NTDS Settings object on each domain controller site.

Check the directory service event log for global catalog errors.

Check the directory service event log for the following global catalog error IDs:

1559

1578

1110

1126

1119

To expedite the synchronization, perform one of the following procedures:

Use Active Directory Sites and Services:

Open Active Directory Sites and Services, expand the problem server's site, and select the server object of that domain controller.

Right-click on its NTDS Settings object and select New Active Directory Connection.

Locate a domain controller that hosts the missing domain partition, double-click it, and then click OK.

Right-click the new connection object and select Replicate Now.

Use Repadmin to force replication by typing the following command at the command line:repadmin /sync DC=missing-domain-nameDC=comProblemServerNameSourceServer_GUID

NOTE:

To obtain the GUID of the server, run the following command, where source-server is the source server you wish to determine the GUID of:repadmin /showreps \\source-server

Determine what partitions have not yet replicated.

If an Event ID 1119 has not been logged, or the domain controller is not advertising as a global catalog, determine what partitions have not yet replicated. Event ID 1265 (Knowledge Consistency Checker errors) assists in determining what partitions the global catalog is having problems with.

NOTE:

If no helpful events are logged, enable diagnostic logging. For more information on diagnostic logging, refer to the following Microsoft Knowledge Base article:

NOTE: Remove these settings when finished troubleshooting, as they will continue to fill up the event log.

Once relevant events are identified, determine the reason for the replication failure. This is often listed at the bottom of the event description, referring to a DNS lookup failure or Access is denied error. After obtaining the error refer to previous sections and follow steps in the section pertaining to that error message.

After resolving all of the relevant errors, ensure that the isGlobalCatalogReady registry value is set to TRUE by following these steps:

Start the LDP tool included in the Microsoft Windows Support Tools.

On the Connection menu, click Connect.

In the Server Name box, type the name for the global catalog server used for lookup.

In the Port Number box, type 3268.
In the right column, several lines of text display.

Find the isGlobalCatalogReady value and ensure that it is set to TRUE.

Determine if the domain controller or global catalog server is experiencing performance issues.

If all of the previous troubleshooting fails to reach a root cause, determine if the domain controller or global catalog server is experiencing performance issues by performing these procedures:

Take an inventory of users accessing the domain controller or global catalog server.

Determine what applications are running queries.

NOTE:

For more information concerning these performance issues, refer to Microsoft TechNet for domain controller and global catalog server best practices.

Verify that port 3268 is available on the network for the global catalog server.

If no relevant event log errors exist on the global catalog server, determine if port 3268 is blocked from the failing client on a router or firewall by using the following portqry command, where domain-controller is the relevant domain controller. :

portqry –ndomain-controller -p tcp –e 3268

NOTE:

For more information concerning the portqry tool, refer to the following Microsoft Knowledge Base article:

ID:310456Title: How to Use Portqry to Troubleshoot Active Directory Connectivity Issues

Global catalog promotion fails.

When promoting a server to be a global catalog, Event ID 1119 indicates a successful promotion; Absence of this event indicates a promotion problem. If the promotion fails, perform the procedures in the following sections to determine a root cause:

If an Event 1119 exists stating that the domain controller successfully promoted as a global catalog, refer to the previous troubleshooting procedures in the Troubleshoot global catalog unavailable errors section of this document:

Determine what global catalog partitions have not yet replicated.

Determine if the domain controller or global catalog server is experiencing performance issues.

Active Directory may experience authentication errors during replication. Refer to the following sections for relevant authentication errors:

Access is denied errors

Target account name is incorrect errors

LDAP bind error 31 errors

An Access Denied error occurs during Active Directory replication.

Access denied errors during replication typically indicate a Kerberos authentication problem. Resolve the authentication problem before continuing to troubleshoot the replication failure. To resolve authentication problems, follow the procedures in the following sections:

Check User Rights for the source server

Ensure that the proper services and settings are enabled for Active Directory replication.

Check the trust relationship between domain controllers

Alter settings for authentication problems between domain controllers from different domains.

Reset the computer account password and force a refresh of Kerberos tickets of downstream partners.

Ensure that the Service Principal Name is registered for each domain controller object.

Force replication of all computer accounts throughout the enterprise.

Specify the configuration partition for failing domain controllers residing in different domains.

Ensure that the Enterprise Domain Controllers group has the required permissions.

Ensure that the server object and corresponding NTDS Settings child object exist in the correct site.

Verify Group Policy security options on all partner domain controllers.

Check for Kerberos fragmentation.

Check the user rights in the source server security policy.

Ensure that the user rights are correct in the source server security policy by performing these steps:

Run MPS_Reports.

Access the computername_userrights.txt file, where computername is the name of the computer to be checked.

Confirm the groups listed have the Access this computer from network user right.

NOTE:

The Everyone, Authenticated Users and Enterprise Domain Controllers must have the Access this computer from the network user right for successful replication.

For more information concerning MPS_Reports, refer to the following Microsoft Knowledge Base article:

Ensure that the proper services and settings are enabled for Active Directory authentication.

Certain services and settings must be enabled to ensure Kerberos authenticates properly. Check the following services and settings:

Ensure that the Kerberos Key Distribution Center (KDC) service is started.

Ensure that the Trust computer for delegation check box is selected on the General tab of the domain controller Properties dialog box in the Active Directory Users and Computers window.

Confirm that the userAccountControl correctly set by performing these steps:

Click the Start button, click the Run menu option, and then type adsiedit.msc and click the OK button.

Expand the Domain NC container.

Expand the next object.

Expand OU=Domain Controllers.

Right-click CN=domain_controller and then click Properties, where domain_controller is the name of the domain controller.

Click the userAccountControl value and verify that the entry is 532480.

Check the trust relationship between domain controllers

If an authentication problem exists between domain controllers from different domains, check the trust relationship using either the Active Directory Domains and Trust window or by using the netdom tool.

Active Directory Domains and Trust
To check the trust relationship using Active Directory Domains and Trust, perform these steps:

Open Active Directory Domains and Trusts.

Right-click the desired domain and select Properties.

Click the Trusts tab.

Highlight the domain to verify and click Edit.

Click Verify.

The netdom Tool

To check the trust relationship between domain controllers using netdom, run the following command from the command line:

Reset the computer account password and force a refresh of Kerberos tickets of downstream partners.

To reset the computer account password and force a refresh of Kerberos tickets of downstream partners, perform these steps:

Run the following command on the problem domain controller:netdom resetpwd /server:DC /userd:domain\administrator /passwordd:password

NOTE:

DC is any domain controller other than the domain controller with an invalid password.

Set the Kerberos Key Distribution Center (KDC) service to manual on the problem domain controller and reboot the computer.

Restart the KDC service and switch it back to Automatic after the reboot is complete.

Ensure that the Service Principal Name is registered for each domain controller object.

To ensure that the Service Principal Name is registered for each domain controller object perform these procedures:

Run Netdiag and review the Registered Service Principal Names section of the output on partner domain controllers.

Export the SPN’s of each domain controller object involved in the replication failure by running the following command from the command line, where DN-of-DC is the domain name of the domain controller:ldifde -f spndump.txt -p base -l servicePrincipalName -dDN-of-DC

Use the Windiff tool to compare the files for differences.

NOTE:

Under the Options menu in Windiff, uncheck everything except for the following:

Show different files

Show left-only lines

Show right-only lines

Windiff is available from Microsoft Windows Support Tools.

Identify missing SPN’s.

Edit the good SPN file.

NOTE: Make the following changes to the SPN file:

Change changetype: add to changetype: modify.

Add replace: servicePrincipalName after the changetype line.

Add "-" to the last line of the file.

Run the following command from the command line:ldifde -I -f goodSPNs.txt
The correctly registered SPNs import on the partner domain controllers.

Force replication of all computer accounts throughout the enterprise.

In domains with more than two domain controllers, all domain controllers must be synchronized with all other copies of their domain. To force all computer accounts to be replicated throughout the enterprise, run the following command on each computer that is reporting a replication error, where problem-domain-controller is the problem domain controller, and DN-of-domain is the distinguished name of the domain controller:

repadmin /syncall /d /eproblem-domain-controllerDN-of-domain

NOTE:

For large environments, remove the /e switch to replicate domain controllers with the same site or use /sync to target specific domain controllers in remote sites.

For more information, refer to the following Microsoft Knowledge Base article:

Specify the configuration partition for failing domain controllers residing in different domains.

To specify the configuration partition for failing domain controllers residing in different domains, run the following command from the command line, where problem-domain-controller is the domain controller have the problem and DN-of-config is the domain name of the configuration partition:

repadmin /syncall /d /eproblem-domain-controllerDN-of-config

NOTE:

For large environments, remove the /e switch to replicate domain controllers with the same site or use /sync to target specific domain controllers in remote sites.

For more information, refer to the following Microsoft Knowledge Base article:

Ensure that the Enterprise Domain Controllers group has the required permissions.

To ensure that the Enterprise Domain Controllers group has the required permissions on the directory partition access control list (ACL), perform these steps:

Start Active Directory Users and Computers.

On the View menu, click Advanced Features.

Right-click the root domain object, and then select Properties.

Click the Security tab, click Enterprise Domain Controllers in the name list, and then ensure the following permissions are selected under Allow:

Manage Replication Topology

Replicating Directory Changes

Replication Synchronization

Ensure that the server object and corresponding NTDS Settings child object exist in the correct site.

Use Active Directory Sites and Services to ensure the server object and its corresponding NTDS Settings child object exist in the correct site.

Verify Group Policy security options on all partner domain controllers.

Verify the following Group Policy security options under Security Settings match on all partner domain controllers:

Additional Restrictions for Anonymous Connections.

Digitally Sign Client Communication (Always)

Digitally Sign Client Communication (When Possible)

Digitally Sign Server Communication (Always)

Digitally Sign Server Communication (When Possible)

LAN Manager Authentication Level

Use the ping utility to check for Kerberos fragmentation.

Refer to the previous section Check for Kerberos fragmentation in an Active Directory environment for more information on this procedure.

A Target account name is incorrect error occurs during Active Directory replication

The Target account name is incorrect error may be indicative of a failure between domain controllers on different domains or the same domain. Review the directory service event logs closely to identify the source of the error. Perform troubleshooting procedures appropriate to the situation in the following sections:

Alter registry settings for replication failures between domain controllers on different domains

Search for duplicate computer or user accounts in the domain.

Review server objects of the problem domain controllers.

Determine if multiple server names with the same IP address are registered in Doman Name Service (DNS)

Force computer account replication for problems within a domain.

Specify the configuration partition for problems between domains.

Check the trust relationship for problems between domains.

Check for a trustedDomain object between domains.

Check the Service Principal Name (SPN) registration for each domain controller object.

Verify that multiple server names with the same IP addresses are not registered in Domain Name Services (DNS)

NOTE: Use adsiedit (available in Microsoft Windows Support Tools) to verify that the dNSHostName attribute on each domain controller is populated with the correct value. To verify this, perform these steps:

Click the Start button, click the Run menu option, and then type adsiedit.msc.

Expand the Domain NC container.

Expand the next object.

Expand OU=Domain Controllers.

Right-click the CN=domain-controller setting, and then click Properties, where domain-controller is the name of the appropriate domain controller.

Under Select a property to view, click dNSHostName and verify the value contains a fully qualified domain name for the server.

Check for a trustedDomain object between domains.

When a Target account name is incorrect error occurs while attempting replication between two domain controllers in different domains that have a parent/child or tree root trust relationship, this may be indicative of a missing trustedDomain object, representing the trust relationship between the two domains.

To check this object, open Active Directory Users and Computers, and then open the System container. If the trustedDomain object is missing, refer to the Missing trustedDomain object section later in this document for troubleshooting procedures.

Force computer account replication for problems within a domain.

In domains with more than two domain controllers, all domain controllers must be synchronized with all other copies of their domain. To force all computer accounts to be replicated throughout the enterprise, refer to the previous procedure: Force replication of all computer accounts throughout the enterprise under the An Access Denied error occurs during Active Directory replication section.

Specify the configuration partition for problems between domains.

To specify the configuration partition for failing domain controllers residing in different domains, refer to the procedures in Specify the configuration partition for failing domain controllers residing in different domains in the An Access Denied error occurs during Active Directory replication section of this document.

Check the trust relationship for problems between domains.

If an authentication problem exists between domain controllers from different domains, check the trust relationship by following the procedures in Check the trust relationship between domain controllers in the section An Access Denied error occurs during Active Directory replication of this document.

Check the Service Principal Name (SPN) registration for each domain controller object.

To ensure that the Service Principal Name is registered for each domain controller object perform the procedures in the Ensure that the Service Principal Name is registered for each domain controller object under the An Access Denied error occurs during Active Directory replication section of this document.

Alter registry settings for replication failures between domain controllers on different domains

If replication is failing for authentication problems between domain controllers in different domains, perform the steps detailed in Alter settings for authentication problems between domain controllers from different domains under the An Access Denied error occurs during Active Directory replication section of this document.

Active Directory replication fails with an LDAP bind error 31.

During Active Directory replication, the system may experience LDAP bind error 31 errors. Follow the troubleshooting procedures in the following sections to correct the problem:

Reset the computer account password and force a refresh of Kerberos tickets.

Add the missing trustedDomain object for the remote domain.

Reset the computer account password and force a refresh of Kerberos tickets.

To reset the computer account password and force a refresh of Kerberos tickets, perform these steps:

Type the following netdom command from the command line on the problem domain controller where computername is any domain controller other than the controller with the invalid password:netdom resetpwd /server:computername /userd:domain\administrator /passwordd:password

NOTE:

The Netdom tool is available on Microsoft Support Tools.

Set the Kerberos Key Distribution Center (KDC) service to manual on the problem domain controller and reboot the system.

After the reboot, start the KDC service and set the service control to Automatic.

If the problem persists, perform these steps:

Use Regedt32 to view the HKEY_LOCAL_MACHINE\Security\Policy\PolAcDmN registry value.

NOTE: If the key is set to the computer name instead of the NetBIOS domain name, proceed with the next steps.

Highlight the No Name value and select Display binary data from the View menu.

Confirm that the value in the HKEY_LOCAL_MACHINE\Security\Policies\PolPrDmN value is set to the NetBIOS domain name.

Copy that value and paste it into HKEY_LOCAL_MACHINE \Security\Policies\PolAcDmN.

Add the missing trustedDomain object for the remote domain.

If an error is reported between two domain controllers of different domains which have a parent/child or tree root relationship, this error may be indicative of a missing trustedDomain object. If this object is not present, cross-domain authentication will fail. A missing trustedDomain object produces the following symptoms:

Event ID 1265 Target account name is incorrect

LDAP bind error 31 during replication

To determine if the trustedDomain object is missing, view the System container in Active Directory Users and Computers.

If the trustedDomain object is missing, perform these steps:

NOTE:

This procedure should only be performed if the trustedDomain object for the remote domain is not present.

From the domain generating the Event ID 1265, open Active Directory Domains and Trusts on the domain controller that holds the PDC Emulator operations master role for the domain.

Right-click the domain object, and then click Properties.

Click the Trusts tab and then click Add.
Both sides of the trust relationship are created.

NOTE: Since this creates a Kerberos trust, creating both sides of a trust is required. Creating the trusted side first generates the error message: Active Directory cannot verify the trust. Access is denied.

Click OK.
The Active Directory Domains and Trusts displays the trust as a transitive, shortcut trust.
The message To verify the new trust, you must have permissions to administer trusts for the domain <domain name>. Do you want to verify the new trust? dispays.

Click the Yes button and then supply administrator credentials for the remote domain.

NOTE: When prompted for credentials, supply the NetBIOS domain name as well as the user name. For example: domainname\Administrator.

The following message displays:Type the password associated with the domain user:
Type the password associated with the object user:
Resetting the trust passwords betweenlocal-domainandremote-domain. The trust betweenlocal-domain and remote-domain has been successfully reset and verified.
The command completed successfully.

Reboot the domain controller where the changes were made.

Wait several minutes for Active Directory to establish a secure channel and the Knowledge Consistency Checker (KCC) to re-establish replication links to the domain controllers in the remote domain.

Test that user logons across the trust relationship are successful and that no errors are logged in the directory service event log.

A logical configuration is improperly configured when information in the Configuration Naming Context (NC) does not match the physical topology of the network that hosts the Active Directory forest. For example, a site may not be properly defined, sites that are missing from site links may be included, site links may not be interconnected, or incorrect bridgeheads may have been configured.

NOTE:

For more information regarding Event ID 1311 errors, refer to the following Microsoft Knowledge Base article:

To enable diagnostic logging and force replication, perform these steps:

Use Regedit to locate the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Note the original values of the following registry entries in order to restore them once the problem is identified:

19 Inter-Site Messaging

5 Replication Events

9 Internal Processing

On the 19 Inter-Site Messaging value, click the Edit menu, click DWORD, and then change the entry to 2.

Click the OK button.

On the 5 Replication Events value, click the Edit menu, click DWORD, and then change the entry to 4.

Click the OK button.

On the 9 Internal Processing value, click the Edit menu, click DWORD and then change the entry to 1.

Click the OK button.

Quit Regedit.

Open Active Directory Sites and Services, click the server object of the problem server, and then force inbound replication with one of its replication partners.

With diagnostic logging enabled, events should appear describing the upstream partners, by GUID, that the server is unable to replicate with. To translate the source server’s object GUID listed in the event description, perform these steps:

Run repadmin /showreps from the server logging the events.

Copy the object GUID from the event description and search for it under the Inbound Partners section.

NOTE:

Restore the following values on the indicated registry key once the problem is located:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

19 Inter-Site Messaging

5 Replication Events

9 Internal Processing

Temporarily lower the tombstonelifetime setting.

Lowering the tombstonelifetime setting forces the object to be garbage collected. The default setting is 60 days. To temporarily lower the tombstonelifetime setting, perform these steps:

Right-click the CN=Directory Service object and click the tombstonelifetime value.

Change the value to a setting less than 60 days.
Objects will be cleaned up during the garbage collection process.

NOTE:

If this is a large environment with many domain controllers spread out in many different sites, use caution when lowering the tombstone value, as it is a forest-wide change that can potentially create lingering objects if end-to-end replication has not taken place. Be sure to return the tombstonelifetime setting to its default when troubleshooting has completed.

Use the ldifde tool to dump out the partition listed in the event.

If the tombstonelifetime setting change does not move the affected object to the Deleted Objects container, use the ldifde tool to dump the partition that cannot replicate from its source replication partner (this partition is listed in the event).

To dump the partition using ldifde, type the following command, where servername is the name of the server and DN-of-object is the distinguished name of the object affected: ldifde –s servername –dDN-of-object–f c:\ldifdump.txt

Collect an ldifde dump on the following domain controllers:

The domain controller logging the event errors.

The source domain controller listed with the GUID in the event log description.

Any domain controller on the same domain that can replicate for comparison purposes.

NOTE:

For more information on viewing deleted objects, refer to the following Microsoft Knowledge Base article:

If an error occurs attempting to edit the object, add the System Only Change registry value on the server hosting the invalid object or attribute:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value name: Allow System Only Change
Value type: REG_DWORD
Value data: 1

If the previous steps still fail to resolve the error or a The name Reference is invalid error occurs while attempting to modify the attribute, perform an authoritative restore of that object on a different domain controller that has a valid copy of the object.

NOTE:

For more information on performing an authoritative restore, refer to the following Microsoft Knowledge Base article:

If an authoritative restore fails to resolve the issue or there is another domain controller with a valid copy of the object, delete the object with Active Directory Users and Computers, adsiedit or ldp, depending on the difficulty of creating the object.

An event error lists a problem with naming context.

When an event error lists a naming context error in the event description (for example: cn=configuration,dc=Contoso,dc=com), perform the procedures in the following sections:

The partition that cannot replicated from its source partner (listed in the event error)

The NTDS database

Domain controller logging the event errors

Another domain controller in the same domain that can replicate

Source domain controller listed with the GUID in the event log description

To run an ldifde dump on these objects, type the following command at the command prompt, where servername is the name of the server and DN-of-naming-context is the distinguished name of the naming context in the error:

ldifde -s servername -dDN-of-naming-context -f c:\ldifdump.txt

NOTE:

For more information on dumping the NTDS database, refer to the following Microsoft Knowledge Base article:

ID: 315136 Title: How to complete a semantic database analysis for the Active Directory database by using Ntdsutil.exe

Use adsiedit to correct values for the domain, configuration, and schema naming contexts

Once the offending attribute has been identified, perform these steps to correct the problem:

Open adsiedit and browse to the CN=NTDS Settings,CN=<ProblemDCname>,CN=Servers,CN=<sitename>,CN=Sites,CN=Configuration,DC=<domain>,DC=com object.

Right-click the object, and then select Properties.

Click the Select a Property to View drop-down box, and then select the hasMasterNCs attribute.
Viewing this attribute through adsiedit should display the correct values for the domain, configuration, and schema naming contexts with a CNF:GUID appended to it.

Attempt to modify the attribute by removing all instances of CNF:GUID.

NOTE:

If an error occurs during this operation, added the System Only Change registry value on the server hosting the invalid object:

If modification of the offending attribute fails or a The name Reference is invalid error occurs while attempting to modify the attribute, perform an authoritative restore of that object on a different domain that has a valid copy.

NOTE:

For more information on authoritative restore, refer to the following Microsoft Knowledge Base article:

If an authoritative restore is not successful or is not an option and there is only one domain controller with an invalid serverReferences attribute, demote the domain controller and force and end-to-end replication using repadmin /syncall command, then promote the domain controller again.

Active Directory retains lingering objects.

There have been some behavioral changes made to address lingering object issues, refer to the following Microsoft Knowledge Base articles for instructions on removing lingering objects:

ID:314282Title: Lingering objects may remain after you bring an out-of-date global catalog server back online

ID:816475Title: Lingering Objects May Remain After Using the Ldp.exe Tool

For more information, refer to the following Microsoft Knowledge Base article:ID:305475Title: Description of RID Attributes in Active Directory

Verify the following information from the ldifde dumps:

That both domain controllers have the correct DN listed for the FsmoRoleOwner attribute, and that the total RID pool (RidAvailablePool attribute) is not exhausted.

That the rIDSetReferences value on the computer object is using the correct DN. It should point to the cn=RID set object underneath the computer object.

That the RidAllocationPool (next pool of RIDs allocated), RidPreviousAllocationPool (current pool in use), and the RidNextRid (next RID to be allocated to a security principal) are set correctly.

If any of these attributes are not populated with the correct values, use adsiedit to modify them. In some cases the system will not allow for manual modification of the values unless the Allow Only System Change registry value in set to 1.

If the previous procedures were unsuccessful, but another domain controller is available, transfer the RID master role to another domain controller.

NOTE:

For more information concerning transfer of a RID master role to another domain controller, refer to the following Microsoft Knowledge Base article:

ID:255504Title: Using Ntdsutil.exe to seize or transfer FSMO roles to a domain controller

Quick Tips content is self-published by the Dell Support Professionals who resolve issues daily. In order to achieve a speedy publication, Quick Tips may represent only partial solutions or work-arounds that are still in development or pending further proof of successfully resolving an issue. As such Quick Tips have not been reviewed, validated or approved by Dell and should be used with appropriate caution. Dell shall not be liable for any loss, including but not limited to loss of data, loss of profit or loss of revenue, which customers may incur by following any procedure or advice set out in the Quick Tips.