Address List browsing fails when list contains more than 51 objects — Exchange Server 2019

Question

Address List browsing fails when list contains more than 51 objects — Exchange Server 2019

Summary

Browsing any address list in the directory fails when the list contains more than 51 recipients. Lists with 51 or fewer objects render correctly. ANR-based search always works regardless of list size. The issue has existed since the organization was installed and affects all three servers.

Symptoms

• OWA (People → Directory → any list): "Your request cannot be completed right now. Please try again later."
• Outlook in online mode (Address Book → Global Address List): "The operation failed."
• Search by name works correctly in both clients and returns expected recipients.
• Cached mode works correctly — OAB-based address book renders the full GAL.

Reproduction and exact threshold

Test address lists were created with filters selecting a controlled number of user mailboxes:

| Objects | Result |

|---|---|

| 5 | Renders correctly |

| 15 | Renders correctly |

| 28 | Renders correctly |

| 50 | Renders correctly |

| 51 | Renders correctly |

| 52 | Fails |

| 53 | Fails |

| 57 | Fails |

| 72 (All Distribution Lists) | Fails |

| 404 (All Users) | Fails |

Threshold is consistent and reproducible. A newly created address list with a Latin-character name behaves identically, so the issue is not tied to the built-in localized list objects.

Environment

• Exchange Server 2019, build 15.2.1748.10, Enterprise, three servers in one DAG
• Organization created 29 Nov 2023, clean installation, no migration from earlier versions
• AD schema version 17003, organization objectVersion 16763, MESO objectVersion 13243
• Domain controllers: Windows Server 2019, two DCs across two AD sites
• Approximately 409 mail-enabled recipients total

Verified as healthy — ruled out

Directory side:

• Direct LDAP VLV queries against the global catalog (port 3268) with server-side sort on displayName succeed for page sizes of 11, 50, 100, 200 and 500 entries, using System.DirectoryServices.Protocols.LdapConnection with SortRequestControl and VlvRequestControl.
• Single LDAP query policy (Default Query Policy), no per-site or per-DC policy assigned. Limits are default: MaxPageSize 1000, MaxTempTableSize 10000, MaxQueryDuration 120, MaxValRange 1500, MaxResultSetSize 262144.
• MSExchange ADAccess event 2080 reports both DCs as fully capable: CDG 1 7 7 1 0 1 1 7 1.
• Get-ADObject queries with the same LDAP filters used by the address lists return correct results in 80–230 ms.

Permissions:

• Open-Address-Book extended right granted to NT AUTHORITY\Authenticated Users on all address list objects, on the All System Address Lists container, and on the VLV objects. Permissions on failing lists are identical to permissions on working lists.

Configuration:

• No Address Book Policies exist in the organization; no mailbox has one assigned.
• msExchQueryBaseDN is empty on all users.
• Address list RecipientFilter values are valid; Get-Recipient -RecipientPreviewFilter returns the full expected recipient set for every list, including the failing ones.
• All VLV system address list objects present with valid purportedSearch filters.
• Default throttling policy, no custom limits.
• No custom registry values under MSExchangeAB or MSExchangeADAccess.
• No overrides in OWA or Sync web.config.
• /mapi/nspi and /mapi/emsmdb applications present under Exchange Back End with correct physical paths; MSExchangeMapiAddressBookAppPool running.
• MAPI virtual directory authentication identical on all three servers: Ntlm, OAuth, Negotiate.
• No recipients with empty DisplayName, missing legacyExchangeDN, or malformed alias.
• Address lists rebuilt with Update-AddressList and Update-GlobalAddressList — no change.
• Application pools restarted (MapiAddressBook, OWA, MapiFrontEnd, Rest) — no change.

Server scope:

• Reproduces for mailboxes homed on two different mailbox servers.
• Reproduces when connecting directly to a mailbox server, bypassing the proxying server (verified via hosts file override).

Logging

No errors are written to the Application log by any Exchange source at the moment the failure occurs. MSExchange ADAccess diagnostics raised to Expert produced only routine 2150/2132 connection pool entries. The only OWA errors logged are event 139 regarding an unconfigured WacUrlHostName, which is unrelated.

Request

The failure threshold of 51 objects suggests the paged-results continuation between the Exchange NSPI/directory layer and Active Directory is not functioning, given that equivalent VLV requests issued directly against the same global catalog succeed at far larger page sizes. Request assistance with ExTRA tracing of the NspiServer and ADProvider components to identify the failure point.

Answer 1

Resolved — root cause was on the domain controller, not Exchange The two servers are in different AD sites and therefore use different domain controllers: NODE4 (site HDE) uses RM-DC1, NODE7 (site Hundred) uses RM-DC2. Pointing NODE4 at RM-DC2 via the ConfigDCHostName / GCHostName registry values under HKLM\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess\Instance0 and restarting MSExchangeADTopology resolved the issue immediately — address list browsing now works with the database active on NODE4. RM-DC1 logs Directory Service event 1173 repeatedly: Exception: e0010001 Error value: 8430 (ERROR_DS_INTERNAL_FAILURE) Internal ID: 20103dc The events correlate directly with each failed browse attempt — eight occurrences within 16 minutes while testing. The same Internal ID every time suggests a consistent failure point, likely a corrupted index in the NTDS database. Next step is running semantic database analysis and an integrity check on RM-DC1.

Answer 2

Update — additional findings

We have narrowed the issue significantly. The failure is tied to which server holds the active database copy, not to the client or the proxying server.

Behaviour

• Active copy of the user's database mounted on NODE4 → address list browsing fails
• Active copy moved to NODE7 → browsing works immediately, no service restart needed
• Moving the database back to NODE4 → fails again immediately

Verified with two different databases (DB01, DB02) and two unrelated mailboxes. Switching is instantaneous and fully reproducible in both directions. Both servers run the same build (15.2.1748.10) in the same DAG.

Note that clients always connect to the same namespace, which resolves to NODE4. So when the database is on NODE7, the request is proxied NODE4 → NODE7 and succeeds; when the database is on NODE4, the request is handled locally on NODE4 and fails. Testing with a hosts-file override to reach NODE7 directly produced the same result — the determining factor is where the mailbox database is mounted, not which server the client reaches.

Compared between NODE4 and NODE7 — all identical

• Exchange binaries: V15\Bin contains 1079 files totalling 641,759,715 bytes on both servers, byte-for-byte identical. All file versions 15.02.1748.010, including Microsoft.Exchange.AddressBook.Service.dll.
• ClientAccess\mapi\nspi directory: 4 files, 19,925 bytes on both.
• nspi\web.config: contents identical apart from the X-DiagInfo / X-BEServer custom headers carrying the local server name.
• MSExchangeMapiAddressBookAppPool_CLRConfig.config: identical hash.
• Extended Protection: tokenChecking="Require" on /mapi/nspi, /mapi/emsmdb, /owa, /ecp, /EWS on both servers, identical configuration throughout.
• Back End (port 444) SSL binding: each server correctly bound to its own self-signed CN=Node4 / CN=Node7 certificate.
• Antivirus: only Microsoft Defender on both, same services running.
• Setup registry keys: MsiBuildMajor 1748, MsiBuildMinor 10, same install path.

Tested and ruled out

1. Extended Protection. Set extendedProtection.tokenChecking to None on Exchange Back End/mapi/nspi on NODE4 via appcmd /commit:apphost, restarted IIS, moved the database to NODE4 — the failure persisted. Setting restored to Require.
2. Network offload features. The only material difference found between the servers was on the NICs — NODE4 has an Intel X520 (driver 4.1.254.0, 2024) with Recv Segment Coalescing (IPv4) and IPsec Offload enabled; NODE7 has a Broadcom NetXtreme Gigabit (driver 17.2.1.0, 2015) without those features. Disabled RSC and IPsec Offload on NODE4, moved the database back — the failure persisted. Settings restored.
3. Information Store restart. Restarting MSExchangeIS on NODE4 did not change the behaviour.
4. Application pool restarts. MSExchangeMapiAddressBookAppPool, MSExchangeMapiFrontEndAppPool, MSExchangeOWAAppPool, MSExchangeRestAppPool — no effect.
5. Address list rebuild. Update-AddressList and Update-GlobalAddressList — no effect. A newly created address list containing 53 objects fails identically, while one containing 51 objects renders correctly.

Current state

All active database copies are kept on NODE7 as a workaround, and address list browsing works for all users. No errors are logged by any Exchange source on either server at the moment of failure.

Question

Given that the binaries and configuration are provably identical between the two servers and the behaviour differs deterministically, we suspect local state on NODE4 that is not reflected in file contents or IIS configuration. Would a Setup.exe /Mode:Upgrade reinstall of the same build be expected to reset whatever state is responsible, or is a full /Mode:RecoverServer required? Any guidance on what local state to inspect before resorting to a reinstall would be appreciated.