The LDAP client, in this case, is Exchange. If the clientĭoes not catch up then it will be disconnected. Requests will be processed until the client catches up.
Is not processing the results of it's requests fast enough.
Internal event: An LDAP client connection was closed because of an error.ġ236 The network connection was aborted by the local system.īut the first one gave us something to go on: 1Ĩ616 The LDAP servers network send queue has filled up because the client Source: Microsoft-Windows-ActiveDirectory_DomainService The second 1216 event it generated wasn’t particularly helpful: 1 With that set to 2, the DC started generating a pair of Event ID 1216 events every time it disconnected Exchange. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\16 LDAP Interface Events Once we discovered that, we set the following registry value to 2 in order to increase the logging level on the DC: 1 Network traces revealed that the DC was intentionally closing the LDAP connection. ExchangeĪctive Directory Provider will attempt to reconnect with this domain (Active directory response: The LDAP server is unavailable.). Exchange Active Directory Provider lostĬontact with domain controller. Usually, the error we saw was a 0x51 indicating the DC was down: 1 This would repeat until it exhausted all in-site DCs, generated an event 2084, and started hitting out-of-site DCs, often returning the same error. Then, it would change DCs and lose connection to the new one as well. The behavior we observed was that Exchange would lose its connection to its config DC. In this blog post, I’m going to document this behavior in detail, in hopes of saving anyone else who runs into this a lot of time and effort. The error messages that described the reason for the disconnect were rather misleading, and we ended up wasting quite a bit of time taking steps that had no chance of improving the situation. I recently worked on an issue where the domain controllers kept intentionally disconnecting the Exchange servers.