Netlogon Event ID 5807

LDAP requests MaxPoolThreads

The problem that can arise from this can be explained as follows.

If the DC receives a name resolution request, it will take time to answer it, clearly.
A client can get up to 6 IP addresses with an activated IPv3 protocol. An IPv6 private (link-local), an IPv6 public and an IPv4 address.

If the client now makes a request to the DC, the DC (Netlogon) tries to assign the client to a subnet / site mapping first, this happens with the LDAP ping and the transmitted IP address of the client.

Netlogon is designed in such a way that if the subnet / site mapping cannot be determined using the LDAP ping, the client tries again with the NetBios name of the client. If a response comes back and the client's IP address could be assigned to a subnet / site mapping, everything is fine.

If this behavior occurs at peak times, other important LDAP requests will be answered with a delay. The whole thing is delayed because the pool (MaxPoolThreads) of LDAP requests is limited. And if Netlogon starts another attempt via the client's NetBios name, a thread from the limited LDAP pool is blocked until it is answered. Inquiries are piling up!

One solution would be to switch off NetBios over TCP / IP on the client's network card in order to avoid unnecessary traffic.

The real cause and solution is:
The trigger is that an IP segment has not been assigned to an Active Directory site. The solution to the problem now arises automatically.

Netlogon Event ID 5807

15 characters Active Directory password policy solution