Update resolves a problem in which LDAP, Kerberos and DC locator responses are slow or time out with Windows

Applies to: Windows 7 Service Pack 1Windows 7 EnterpriseWindows 7 Professional


You notice that Lightweight Directory Access Protocol (LDAP) or Kerberos responses from the domain controller are delayed by 2 to 5 seconds. When the issue occurs, the Lsass.exe process CPU usage is low (even lower than usual).

Around the same time (but up to a 4-hour offset), you may receive Netlogon warning event 5807. This event indicates that many client IP addresses couldn’t be mapped to configured subnet definitions in Active Directory:As noted in the event, you may also receive many entries that have NO_CLIENT_SITE: in the Netlogon log when it is configured.


These LDAP ping requests are unexpectedly exhausting all available threads for LDAP requests and Kerberos requests. The delayed response may cause clients to retry the LDAP ping (DC Locator) and Kerberos requests, and this makes the situation worse. For technical details, please visit the "More Information" section.


This update adds the "Specify address lookup behavior for DC locator ping" Group Policy setting for Windows 7 and Windows Server 2008 R2. After the update is installed, the policy setting is available in the following location:
Computer Configuration\Administrative Templates\System\Net Logon\DC Locator DNS Records
The Group Policy setting added by this update enables administrator to control how domain controllers perform address lookups. The policy setting must be applied to domain controllers. You can set three values for the Group Policy setting:
  • 0 - Domain controllers will never perform address lookups.
  • 1 - This is the default behavior. Domain controllers will perform an exhaustive address lookup to discover additional client IP addresses.
  • 2 - Domain controllers will perform a fast, DNS-only address lookup to discover additional client IP addresses.
Policy Screenshot


Microsoft has created an updated binary and policy settings to enable administrators to control how NetBT is used to process LDAP pings.

More Information

When a domain controller receives a LDAP User Datagram Protocol (UDP) ping, the domain controller performs a client IP address lookup to find a matching subnet definition in Active Directory in order to provide the client with the corresponding logon site name.

If the domain controller cannot find a matching subnet for the client IP, it performs its own name resolution with the client's NetBIOS name for potentially finding a different IP having a subnet match.

The name resolution is performed in accordance with the domain controller's available resolution mechanism. In addition to DNS, WINS and NetBIOS may also be used, including broadcasts. According to the name resolution response or time-out, the related LDAP ping is locking one of the threads of the limited Active Thread Queue (ATQ) pool. Many of these LDAP pings over a longer time may constantly exhaust the ATQ pool. Because the same pool is required for regular LDAP and Kerberos requests, the domain controller becomes almost unavailable to users.

The domain controllers stop responding to the following workloads when the worker thread pool is exhausted, because they all share the same ATQ worker thread pool:
  • LDAP pings
  • LDAP queries
  • Kerberos
Failing those three core operations would cause many transitive errors on remote clients, applications, and domain controllers.

You may also observe the following symptoms:
  • Because the domain controller cannot perform workloads in this situation, CPU usage is lower than usual. (when Baseline Monitoring for comparison is in place)
  • The NTDS\ATQ Threads LDAP counter in Perfmon is equal to NTDS\ATQ Threads Total.
  • Domain controllers take about 2 seconds to service LDAP pings, as illustrated in the NETLOGON.LOG when debug logging is enabled by using "nltest /dbflag:0x2080FFFF." The log also contains frequent entries that contain "NO_CLIENT_SITE."

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates


Before this update is installed, the following workarounds were identified as avoiding the problem: