Active Directory Replication Troubleshooter

Active Directory Replication Troubleshooter




Active Directory Replication Troubleshooter

This document covers troubleshooting procedures for Active Directory replication problems. The following symptoms are covered:

  • Name Resolution Errors
  • RPC Server is too busy errors
  • Global Catalog Errors
  • Authentication Errors
  • Replication Topology and Connectivity Errors
  • Replication Engine Errors
  • Lingering Objects
  • Relative Identifier (RID) Master Failures

Before troubleshooting, determine what domains and domain controllers are relevant and in which sites they reside, and then determine the domain controller replication partners.


Determine the relevant domains and domain controllers and in which sites they reside.

To determine the relevant domains and domain controllers and in which sites they reside, use one of the following methods:

  • Open a command prompt and type the command: repadmin /showreps.

    NOTE:

    Repadmin is part of Microsoft Windows Support Tools. For more information on repadmin, refer to the Microsoft support site at: http://support.microsoft.com.

  • Run the Directory Services Microsoft Configuration Capture Utility (MPS_Reports) tool.

    NOTE: After running the MPS_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:

    Article ID: 818742 Title: Overview of the Microsoft Configuration Capture Utility (MPS_REPORTS)



Determine a domain controller replication partners.

To determine a domain controller's replication partners, perform these steps:

  1. Open Active Directory Sites and Services, and then click NTDS Settings.
  2. Select the Replicate Now setting on each partner domain controller.
  3. Note the partner domains that fail replication, as well as the error given.
  4. Run MPS_Reports on failed domain controller partners.

NOTE:

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

ID: 818742 Title: Overview of the Microsoft Configuration Capture Utility (MPS_REPORTS)



Active Directory experiences name resolution errors during replication.

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.



Perform preliminary troubleshooting on name resolution errors during Active Directory replication.

Before troubleshooting specific name resolution errors, perform these preliminary troubleshooting steps:

  • Perform concurrent network traces from replication partners.
  • Run DNSLint.exe and examine the output.

NOTE:

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: 321046 Title: 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: 261968 Title: 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:

    ID: 304491 Title: Conditional Forwarding in Windows Server 2003



Verify the proper zone delegation in an Active Directory environment.

To verify the proper zone delegation, perform these procedures:

  • 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: 255248 Title: 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:

  1. Verify the configuration settings on the client and zone, as discussed in previous sections.
  2. Delete netlogon.dns and netlogon.dnb files on the domain controller and restart the Net Logon service.

    NOTE: For more information concerning Net Logon service events, refer to the Microsoft Knowledge Base article below:

    ID: 259277 Title: Troubleshooting Netlogon Event 5774, 5775, and 5781

    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

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

  4. 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.
  5. Verify that domain controllers that are replication partners in the affected domain have their GUID's registered in the forest root zone.

    NOTE: Example of domain GUID record:

    Name: e99e82d5-deed-11d2-b15c-00c04f5cb503._msdcs.contoso.com
    Type: CNAME
    Data: dc01.contoso.com

    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.

  6. Ensure that each domain controller has a host record registered for their name (CNAME) in the DNS zone record.
  7. Verify that both domain controllers involved in the Active Directory replication can resolve DNS records for each other.
  8. 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: 275278 Title: DNS Server Becomes an Island When a Domain Controller Points to Itself for the _Msdcs.ForestDnsName Domain



Troubleshoot endpoint mapper errors in an Active Directory environment.

In the course of Active Directory replication, the following error message may appear, indicating a problem with name resolution:

There are no more endpoints available from the endpoint mapper

To troubleshoot this error, perform the following procedures:

  • Collect information on the network hardware (routers, switches, firewalls, etc) that separate partner domain controllers.
  • Run the Directory Services MPS_Reports on problem domain controllers to gather further data.
  • Perform steps listed in the following sections: Verify open ports, Test for black hole issues, and Check for Kerberos fragmentation.



Verify open ports on any network hardware separating domain controllers in an Active Directory environment.

Verify that the following network ports are open on any network hardware separating the domain controllers using portqry:

  • 389 TCP (LDAP) or TCP 686 is using Secure Sockets Layer (SSL)
  • 389 UDP (LDAP ping)
  • 88 TCP/UDP (Kerberos)
  • 53 TCP/UDP (Domain Name Service)
  • 445 TCP/UDP (SMB over IP traffic)
  • Remote Procedure Call (RPC) ports

NOTE:

For more information concerning RPC ports, refer to the following Microsoft Knowledge Base articles:

ID: 224196 Title: Restricting Active Directory Replication Traffic to a Specific Port

ID: 154596 Title: How to configure RPC dynamic port allocation to work with firewalls

ID: 319553 Title: How to Restrict FRS Replication Traffic to a Specific Static Port




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:

ping computername-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:

ID: 159211 Title: Diagnoses and Treatment of Black Hole Routers



Check for Kerberos fragmentation in an Active Directory environment.

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:

ping computername-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:

ID: 244474 Title: How to force Kerberos to use TCP instead of UDP



Active Directory experiences RPC server busy errors during replication.

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:

    W32Time: BEGIN:GetSocketForSynch
    W32Time: NTP: ntpptrs[0] - DC01
    W32Time: rgbNTPServer DC01
    W32Time: NTP: gethostbyname failed
    W32Time: Port Pinging to - 123
    W32Time: NTP: connect failed
    W32Time: END:Line 1147

NOTE:

For more information concerning this issue and how Windows Time service works, refer to the following Microsoft Knowledge Base articles:

ID: 257187 Title: RPC Error Messages Returned for Active Directory Replication When Time Is Out of Synchronization

ID: 224799 Title: Basic Operation of the Windows Time Service



Active Directory experiences global catalog errors during replication.

Global catalog errors during replication of an Active Directory may occur. This section covers the following two error conditions:

  • No Global Catalog can be contacted errors
  • Global catalog fails to promote errors.

Refer to the following sections for troubleshooting these errors.



Global catalog unavailable error occurs.

Global catalog discovery errors can occur for a number of reasons. First, determine if the global catalog is actually unavailable or if the problem client is not receiving the advertisement.

To verify that the global catalog is unavailable, perform these procedures:

  • Run the following command to locate a global catalog server, where FQDN is the fully qualified name of the domain:
    nltest /dsgetdc:FQDN /gc /force
  • Log in from a client with the User Principal Name (UPN). For example: someone@microsoft.com.
  • Attempt to find a user name in the Windows Address Book by performing these steps:
    1. Click the Start button, click Run, type WAB and then click OK.
      The Windows Address Book opens.
    2. Click the Find People button, and then select Active Directory from the Look In box.
    3. 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:
    1. Open Active Directory Sites and Services, expand the problem server's site, and select the server object of that domain controller.
    2. Right-click on its NTDS Settings object and select New Active Directory Connection.
    3. Locate a domain controller that hosts the missing domain partition, double-click it, and then click OK.
    4. 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-name DC=com ProblemServerName SourceServer_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:

ID: 31480 Title: How to configure Active Directory diagnostic event logging in Windows Server

Set the following registry entries to the indicated values:

Replication Events: 3
Inter-Site Messaging: 2
Internal Processing: 1
Global Catalog: 4

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:

  1. Start the LDP tool included in the Microsoft Windows Support Tools.
  2. On the Connection menu, click Connect.
  3. In the Server Name box, type the name for the global catalog server used for lookup.
  4. In the Port Number box, type 3268.
    In the right column, several lines of text display.
  5. 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 –n domain-controller -p tcp –e 3268

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

ID: 310456 Title: 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:

  • Investigate the Active Directory environment
  • Review the directory service event log.
  • Determine partition replication status and investigate global catalog or domain controller performance issues.



Investigate the Active Directory Environment

Gather the following information before proceeding to troubleshoot a failed global catalog promotion:

  • Number of domains in the Active Directory forest.
  • Names of domains hosted by domain controllers in the global catalog local site.
  • Names of domains hosted by domain controllers in remote sites.



Review the directory service event log for relevant events

Review the directory service event log for the following relevant events:

  • 1559
  • 1578
  • 1110
  • 1126

NOTE: If relevant events do not exist in the event viewer, enable diagnostic logging on the global catalog by configuring the following registry values:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
Inter-Site Messaging: 2
Replication Events: 3
Internal Processing: 1
Global Catalog: 4

For more information concerning setting diagnostic logging, refer to the following Microsoft Knowledge Base article:

ID: 314980 Title: How to configure Active Directory diagnostic event logging in Windows Server



Determine partition replication status and investigate global catalog or domain controller performance issues.

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 experiences authentication errors during replication.

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:

  1. Run MPS_Reports.
  2. Access the computername_userrights.txt file, where computername is the name of the computer to be checked.
  3. 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:

    ID: 818742 Title: Overview of the Microsoft Configuration Capture Utility (MPS_REPORTS)



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:
    1. Click the Start button, click the Run menu option, and then type adsiedit.msc and click the OK button.
    2. Expand the Domain NC container.
    3. Expand the next object.
    4. Expand OU=Domain Controllers.
    5. Right-click CN=domain_controller and then click Properties, where domain_controller is the name of the domain controller.
    6. 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:

  1. Open Active Directory Domains and Trusts.
  2. Right-click the desired domain and select Properties.
  3. Click the Trusts tab.
  4. Highlight the domain to verify and click Edit.
  5. Click Verify.

The netdom Tool

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

netdom trust trusting_domain_name /domain:trusted_domain_name /userd:administrator /password:password /verify /kerberos

NOTE: The netdom utility is available on Microsoft Windows Support Tools.



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

If replication is failing for authentication problems between domain controllers in different domains, perform these steps:

  1. Add the following registry value to the upstream replication partner:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
    Value name: Replicator Allow SPN Fallback
    Value type: REG_DWORD
    Value data: 1
  2. Run the following command from the upstream partner:

    repadmin /add CN=Configuration,DC=domain controller,DC=com root DC name fully qualified name of child domain controller
  3. Remove the Replicator Allow SPN Fallback registry value after testing replication.



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:

  1. 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.
  2. Set the Kerberos Key Distribution Center (KDC) service to manual on the problem domain controller and reboot the computer.
  3. 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:

  1. Run Netdiag and review the Registered Service Principal Names section of the output on partner domain controllers.
  2. 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 -d DN-of-DC
  3. 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.

  4. Identify missing SPN’s.
  5. Edit the good SPN file.

    NOTE: Make the following changes to the SPN file:

    1. Change changetype: add to changetype: modify.
    2. Add replace: servicePrincipalName after the changetype line.
    3. Add "-" to the last line of the file.
  6. 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 /e problem-domain-controller DN-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:

ID: 296993 Title: "Logon failure: the target account name is incorrect" error when promoting domain controllers or creating replicas



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 /e problem-domain-controller DN-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:

ID: 296993 Title: "Logon failure: the target account name is incorrect" error when promoting domain controllers or creating replicas



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:

  1. Start Active Directory Users and Computers.
  2. On the View menu, click Advanced Features.
  3. Right-click the root domain object, and then select Properties.
  4. 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.



Review server objects for duplicate user or domain names, conflicting objects, or duplicate IP addresses.

To review server objects for duplication or object conflicts, peform these procedures:

  • Review the server objects of problematic domain controllers in Active Directory Sites and Services to ensure that there are no duplicates or conflicting objects present.
  • Search for duplicate computer or user accounts in the domain of the failing domain controller and its upstream replication partner.

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

    ID: 310340 Title: Error Message: Logon Failure: The Target Account Name Is Incorrect

  • 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:

    1. Click the Start button, click the Run menu option, and then type adsiedit.msc.
    2. Expand the Domain NC container.
    3. Expand the next object.
    4. Expand OU=Domain Controllers.
    5. Right-click the CN=domain-controller setting, and then click Properties, where domain-controller is the name of the appropriate domain controller.
    6. 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:

  1. 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.
  2. Set the Kerberos Key Distribution Center (KDC) service to manual on the problem domain controller and reboot the system.
  3. After the reboot, start the KDC service and set the service control to Automatic.

If the problem persists, perform these steps:

  1. 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.
  2. Highlight the No Name value and select Display binary data from the View menu.
  3. Confirm that the value in the HKEY_LOCAL_MACHINE\Security\Policies\PolPrDmN value is set to the NetBIOS domain name.
  4. 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.

  1. 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.
  2. Right-click the domain object, and then click Properties.
  3. 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.
  4. 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.
  5. 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 error message displays: Active Directory cannot verify the trust. Access is denied.
  6. Click the OK button.
    Active Directory Domains and Trusts displays the trust as a transitive, shortcut trust.
  7. Run the following netdom command, where local-domain is the domain on which the trust is created and remote-domain is the parent, child or root domain being trusted:

    NOTE: Use the fully qualified domain name. For example: server.mydomain.com.

    netdom trust local-domain /domain:remote-domain /userd:administrator /passwordd:* /usero:administrator /passwordo:* /reset /twoway

    The following message displays:
    Type the password associated with the domain user:
    Type the password associated with the object user:
    Resetting the trust passwords between
    local-domain and remote-domain. The trust between local-domain and remote-domain has been successfully reset and verified.
    The command completed successfully.
  8. Reboot the domain controller where the changes were made.
  9. 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.
  10. Test that user logons across the trust relationship are successful and that no errors are logged in the directory service event log.



Active Directory experiences topology and connectivity errors during replication.

Active Directory may experience replication topology and connectivity errors (Event ID 1311). The common causes of these errors include:

  • Improper Logical Configuration
  • Infrastructure Failure

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

How to troubleshoot Event ID 1311 messages on a Windows 2008 domain

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

ID: 214745 Title: How to troubleshoot Event ID 1311 messages on a Windows 2003 domain



Troubleshooting improper logical configuration problems for Active Directory

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:

How to troubleshoot Event ID 1311 messages on a Windows 2008 domain

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

ID: 214745 Title: How to troubleshoot Event ID 1311 messages on a Windows 2003 domain



Troubleshooting an infrastructure failure for Active Directory replication.

An infrastructure failure occurs as a result of one of more of the following events:

  • A wide area network (WAN) link fails.
  • A domain controller that hosts a necessary naming context is offline.
  • A replication failure occurs for one or more naming contexts.
NOTE:

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

How to troubleshoot Event ID 1311 messages on a Windows 2008 domain

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

ID: 214745 Title: How to troubleshoot Event ID 1311 messages on a Windows 2003 domain



Active Directory experiences replication engine errors during replication.

This section covers replication engine errors during Active Directory replication. Refer to the following sections appropriate to the error message received:

  • Replication operation encountered a database error.
  • Event error lists problem with object.
  • Event error lists problem with naming context.



Enable diagnostic logging, force replication and translate the source server’s object GUID.

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

  1. Use Regedit to locate the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
  2. 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
  3. On the 19 Inter-Site Messaging value, click the Edit menu, click DWORD, and then change the entry to 2.
  4. Click the OK button.
  5. On the 5 Replication Events value, click the Edit menu, click DWORD, and then change the entry to 4.
  6. Click the OK button.
  7. On the 9 Internal Processing value, click the Edit menu, click DWORD and then change the entry to 1.
  8. Click the OK button.
  9. Quit Regedit.
  10. 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:

  1. Run repadmin /showreps from the server logging the events.
  2. 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:

  1. Open the Active Directory Sites and Services.
  2. Browse to the following, where domain is the relevant domain: CN=Directory Service, CN=Windows NT, CD=Services, CN=Configuration, DC=domain, DC=com.
  3. Right-click the CN=Directory Service object and click the tombstonelifetime value.
  4. 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 –d DN-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:

ID: 258310 Title: Viewing deleted objects in Active Directory



Dump the Microsoft Windows NT Directory Service database.

Dump the Windows NT Directory Service (NTDS) database.

NOTE:

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

ID: 315098 Title: How to Use the Online Dbdump Feature in Ldp.exe



Run an integrity check on the database and analyze the database for inconsistencies.

After collecting ldifde dumps, run an integrity check on the database. To do this, perform these steps:

  1. Reboot the server into Directory Services restore mode.

    NOTE: As a precaution, ensure that there is a recent backup of the system state from this server or another domain controller that is up-to-date.
  2. From the command prompt, type ntdsutil and press the <Enter> key.
  3. Type files, and then press the <Enter> key.
  4. Type integrity, and then press the <Enter> key.
  5. Verify that the integrity check completes successfully with no errors.

    NOTE: If errors occur, type recover, press the <Enter> key, and then run the integrity command again.

If the integrity check completes successfully, analyze the database for inconsistencies using the semantic analysis command in ntdsutil.

NOTE: For more information on semantic analysis, refer to the following Microsoft Knowledge Base article:

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



Review the ldifde dumps for object irregularities and make changes to the object.

Review the ldifde dumps for irregularities of the object name or attributes. The following is an example of an object listed in an event error:

Replication error: The directory replication agent (DRA) could not update object.
CN=Daniel P. Taylor,OU=Recipients,OU=North Kansas City,DC=Contoso,DC=Com
GUID

With the problem object identified, perform the following procedures:

  • Force an end-to-end replication using the repadmin /syncall command.
  • If unsuccessful, use adsiedit to modify the offending attribute.
  • 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:

    How to perform an authoritative restore to a domain controller in Windows 2008
  • 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:

  • Collect ldifde dumps on the failed partition, domain controllers and database.
  • Analyze the database for inconsistencies.
  • Use adsiedit to correct values for the domain, configuration, and schema naming contexts.
  • Perform an authoritative restore of the problem object.



Collect ldifde dumps on the failed partition, domain controllers and database.

Collect ldifde dumps on the following objects:

  • 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 -d DN-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: 315098 Title: How to Use the Online Dbdump Feature in Ldp.exe



Run a database integrity check and analyze the database for irregular objects.

Run an integrity check on the database by following these steps:

  1. Reboot the server into Directory Services restore mode.

    NOTE: As a precaution, be sure that there is a recent backup of the system state on this server, or on another domain controller with up-to-date data before running this command.
  2. From the command prompt, type ntdsutil and then press the <Enter> key.
  3. Type files, and then press the <Enter> key.
  4. Type integrity and then press the <Enter> key.
  5. Verify that the command completes without errors.

    NOTE: If errors occur, type recover and then press the <Enter> key, and then run the integrity check again.

If the integrity check completes successfully, analyze the database for inconsistencies using the semantic analysis command in ntdsutil. Review the dumps for the following example irregularities:

  • nCName attribute located on the crossRef object of a domain, i.e. CN=Contoso,CN=Partitions,CN=Configuration,DC=Contoso,DC=com.
  • serverReference attribute located on the server object i.e. CN=DC1,CN=Servers,CN=North Dakota,CN=Sites,CN=Configuration,DC=Contoso),DC=com.
  • hasMasterNCs attribute located on the NTDS Settings object of a server, i.e. CN=NTDS Settings,CN=DC1,CN=Servers,CN=North Dakota,CN=Sites,CN=Configuration,DC=Contoso,DC=com.
  • Example of a damaged attribute:
    hasMasterNCs::REM9ZGFsXApDTkY6ODVkYWY5N2QtYmU0Yi00MDFiLWJmMWItOWJiMGJmZjJjNmQ2LERD...
    hasMasterNCs::Q049U2NoZW1hLENOPUNvbmZpZ3VyYXRpb24sREM9TlJUSU5DLERDPU5SVA
    hasMasterNCs::Q049Q29uZmlndXJhdGlvbixEQz1OUlRJTkMsREM9TlJU

NOTE:For more information regarding semantic analysis, 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:

  1. Open adsiedit and browse to the CN=NTDS Settings,CN=<ProblemDCname>,CN=Servers,CN=<sitename>,CN=Sites,CN=Configuration,DC=<domain>,DC=com object.
  2. Right-click the object, and then select Properties.
  3. 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.
  4. 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:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value name: Allow System Only Change
Value type: REG_DWORD
Value data: 1



Perform an authoritative restore of the problem 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:

How to perform an authoritative restore to a domain controller in Windows 2008


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: 314282 Title: Lingering objects may remain after you bring an out-of-date global catalog server back online

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



Active Directory experiences a Relative Identifier (RID) Master Failure.

RID master failures during Active Directory replication are covered under the following sections:

  • Account-identifier allocator failed to initialize properly errors.
  • Maximum account identifier allocated to this domain controller errors



Troubleshoot a Account-identifier allocator failed to initialize properly error.

Account-identifier allocator failed to initialize properly errors typically occur as a result of new behavior introduced in Service Pack 3.

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

ID: 822053 Title: Error Message: "Windows Cannot Create the Object Because the Directory Service Was Unable to Allocate a Relative Identifier"

If the RID master has not been recently restored or transferred, perform the following procedures:

  • Verify the RID operations master is reachable, then from the problem domain controller, try to ping the RID master by fully qualified domain name.

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

    ID: 234790 Title: How To Find Servers That Hold Flexible Single Master Operations Roles
  • Verify authentication between servers with the following command, where domain is the domain, DC is the domain controller:
    nltest /sc_reset:domain\DC /server:RID-master
  • Verify Active Directory replication between the two domain controllers.
  • Review the RID section of the Dcdiag output for relevant errors that might indicated why the RID pool cannot be allocated.

If these procedures do not determine a root cause, perform the procedures in the following sections:

  • Obtain ldifde dumps from the RID owner and the domain controller.
  • Transfer the RID master role to another domain controller.



Obtain ldifde dumps from the RID owner and the domain controller.

In order to review all of the RID master objects generating errors, obtain ldifde dumps from the RID owner and the domain controller by running the following commands:

ldifde -s servername -d "CN=System,DC=mydomain,DC=<com>" -f c:\ldifdump.txt
ldifde -s servername -d "CN=problem DC,OU=Domain Controllers,DC=mydomain,DC=<COM>" -f c:\ldifdump.txt

NOTE: For more information, refer to the following Microsoft Knowledge Base article:
ID: 305475 Title: 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.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value name: Allow System Only Change
Value type: REG_DWORD
Value data: 1



Transfer the RID master role to another domain controller.

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: 255504 Title: 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.

Identifikátor článku: SLN18218

Dátum poslednej zmeny: 11/05/2014 09:37 AM


Ohodnotiť tento článok

Presné
Užitočné
Jednoducho pochopiteľné
Bol pre vás tento článok užitočný?
Áno Nie
Pošlite nám pripomienky.
Poznámky nemôžu obsahovať nasledujúce špeciálne znaky: <>()\
Ľutujeme, náš systém odosielania pripomienok je momentálne nefunkčný. Skúste znova neskôr.

Ďakujeme vám za pripomienky.