Find the LDAP query policy a DC uses

A policy object is not proof of an effective setting

Two DCs can return different results because they use different query policies. Listing CN=Query-Policies tells you what exists, not which object either DC selects. Query policy is directory configuration; it is separate from the policies that require LDAP signing or channel binding.

The selection order is the DC’s nTDSDSA object, its site’s nTDSSiteSettings object, then the Default Query Policy. This selects one policy object; it is not a Group Policy style merge of every named policy. Missing limits use the implementation’s defaults. MS-ADTS defines the selection and release-specific policy support.

Resolve the assignments on the same DC the application contacted. Configuration replication can itself be behind.

$dc = 'dc1.contoso.com'
$root = Get-ADRootDSE -Server $dc
$controller = Get-ADDomainController -Identity $dc -Server $dc
$dsa = Get-ADObject -Server $dc -Identity $controller.NTDSSettingsObjectDN `
    -Properties queryPolicyObject -ErrorAction Stop
$site = Get-ADReplicationSite -Server $dc -Identity $controller.Site
$siteSettings = Get-ADObject -Server $dc `
    -Identity "CN=NTDS Site Settings,$($site.DistinguishedName)" `
    -Properties queryPolicyObject -ErrorAction Stop

$policyDN = [string]$dsa.queryPolicyObject
$assignment = 'DC'
if ([string]::IsNullOrEmpty($policyDN)) {
    $policyDN = [string]$siteSettings.queryPolicyObject
    $assignment = 'Site'
}
if ([string]::IsNullOrEmpty($policyDN)) {
    $policyDN = "CN=Default Query Policy,CN=Query-Policies," +
        "CN=Directory Service,CN=Windows NT,CN=Services," +
        $root.configurationNamingContext
    $assignment = 'Default'
}
$policy = Get-ADObject -Server $dc -Identity $policyDN `
    -Properties lDAPAdminLimits -ErrorAction Stop
[pscustomobject]@{
    Server = $dc
    Site = $controller.Site
    Assignment = $assignment
    PolicyDN = $policy.DistinguishedName
}
$policy.lDAPAdminLimits | Sort-Object

If the assignment points to an unreadable or missing object, investigate that failure. Don’t silently substitute the default and report it as the selected policy. Keep the raw name/value strings from the policy too.

Ntdsutil can show the wrong policy for your question

This sequence reads policy values without committing a change:

ntdsutil
ldap policies
connections
connect to server dc1.contoso.com
quit
show values
quit
quit

Microsoft’s Ntdsutil procedure explicitly says it displays the default query policy, not custom policies. Connecting the tool to DC1 does not make this output a report of DC1’s custom assignment. Resolve the AD links above before treating show values as an explanation of the application’s limit.

Name the resource being limited

Start with the request and its final result: server, port, identity, base, scope, filter, attributes, controls, result code and cookie/range. A cut-off at a round number is a useful clue, but you’ll still need to find which limit caused it. Paging and range retrieval deal with different limits.

Stored values and enforced limits can differ

A value present in lDAPAdminLimits may be unsupported on that Windows release or constrained by an implementation ceiling. MaxActiveQueries, for example, is a historical Windows 2000 control that stopped being enforced in Server 2003. A copied old policy object does not make it effective again.

Microsoft documents a Server 2008/2008 R2 case where configured page/range limits exceeded hardcoded ceilings. Check what the particular release enforces as well as what’s stored in the policy. Don’t use that old case’s ceilings as sizing advice for current releases.

dSHeuristics can also change how some limits are interpreted. It is a positional, forest configuration string with unrelated settings sharing the same value. Read the current protocol definition for the target release. A whole-string replacement copied from an old fix can change other behavior. Preserve the original value and its rationale; bypassing a ceiling is not evidence that the resulting workload is supportable.

A longer timeout can make the incident larger

If the client cancels after 30 seconds, raising a server limit above 120 seconds cannot make that client wait longer. If a query already ties up expensive resources, allowing it to run longer can increase overlap with the next scheduled request. More overlapping work can worsen the original latency and affect unrelated authentication or replication work.

First separate bind time, search execution, data transfer and application processing. Use query performance evidence to examine scope, indexes, values returned and query frequency. A smaller page does not repair every poor query plan, and raising MaxPageSize does not implement paging in the client.

Bound and verify a justified exception

If a Microsoft procedure for the application calls for a temporary limit change, check its applicability first. Record the affected DC/site, original policy and values, expected workload, when you’ll restore it and who’s responsible. Check how the application selects DCs too: it may never contact the server you changed. Changing the default can affect many more servers.

Check the policy procedure’s activation/restart requirements for editing an existing policy versus assigning a new one. Then retry the original request and representative workloads, noting which DC and policy handled them. Check the final result code and cookie as well as the count; more returned objects don’t necessarily mean you received them all.