eG Help

Active Directory servers must be available for Exchange 2013 to function correctly. Microsoft Exchange Server 2013 stores all configuration and recipient information in the Active Directory directory service database. When a computer running Exchange 2013 requires information about recipients and information about the configuration of the Exchange organization, it runs LDAP queries on the Active Directory to access the information. For this purpose, as soon as Exchange 2013 starts, it binds randomly with a domain controller and global catalog server in its own site. If any of these domain controllers process the LDAP queries slowly, Exchange 2013 server roles may not have the recipient/configuration information they require on time; this in turn may significantly slowdown mission-critical operations of the Exchange server such as authentication, mail delivery, etc.

If this is to be avoided, administrators should keep a close watch on the LDAP queries to each domain controller in the same site as Exchange 2013, measure the time taken by each controller to process the queries, and swoop down on domain controllers that are experiencing serious processing bottlenecks. For this purpose, administrators can use the Exc2013AccCtrlTest test.

This test auto-discovers the domain controllers used by Exchange 2013, and reports how quickly every controller processes the LDAP requests it receives. In the process, the test accurately pinpoints the slow controllers.

Measurement	Description	Measurement Unit	Interpretation
Ldap_read_cal	Indicates the rate at which Depth 0 LDAP search calls are made to this domain controller.	Calls/Sec	Depth 0 calls refer to search queries that search only the base DN. Compare the value of this measure across domain controllers to identify which domain controller is the busiest in terms of the frequency of such calls.
Ldap_read_tim	Indicates the time taken by this domain controller to execute LDAP read requests and return a response.	Secs	The average value for this measure should be less than 50 milliseconds. Spikes (Maximum) should not be higher than 100 milliseconds. Compare the value of this measure across domain controllers to identify which controller is processing read requests slowly.
Ldap_srch_cal	Indicates the rate at which Depth 1 and 2 LDAP search calls were made to this domain controller.	Calls/Sec	Depth 1 and 2 calls refer to search queries that search 1 and 2 levels below the base DN. Compare the value of this measure across domain controllers to identify which domain controller is the busiest in terms of the frequency of such calls.
Ldap_srch_tim	Indicates the time taken by this domain controller to process LDAP search queries and return a response.	Secs	The average value for this measure should be less than 50 milliseconds. Spikes (Maximum) should not be higher than 100 milliseconds. Compare the value of this measure across domain controllers to identify which controller is processing search queries slowly.
Ldap_tim_lim_min	Indicates the number of LDAP searches to this domain controller that executed beyond a configured duration in the last minute.	Number	MaxQueryDuration is an LDAP administration limit that represents the maximum time a domain controller should spend on a single search. When this limit is reached, the domain controller returns a “timeLimitExceeded” error. By comparing the value of this measure across domain controllers, you can identify that controller with the maximum number of long-running queries. Such controllers could be experiencing serious processing bottlenecks.
Ldap_tim_out_min	Indicates the number of LDAP searches to this domain controller that timed out in the last minute.	Number	Ideally, the value of this measure should be low. A high value indicates that too many LDAP searches timed out.
No_outstand_req	Indicates the current number of pending LDAP operations to this domain controller.	Number	Compare the value of this measure across domain controllers to identify that controller with the highest number of pending operation. The reason for this anomaly should be investigated and the source of the processing bottleneck should be cleared for optimal performance of Exchange 2013.