ERROR_DS_COUNTING_AB_INDICES_FAILED (0X000020EC) Fix

You're staring at 0X000020EC and the message 'The attempt to count the address book indices failed.' I've been there — it usually pops up when you're running a domain controller health check or trying to rebuild the global catalog. The error itself isn't catastrophic, but it halts any operation that needs those indices. The good news is you can fix it without rebuilding the whole DC.

Let's walk through the three most common causes in order of likelihood. Skip to the one that matches your scenario.

1. Corrupted Address Book Index Files

This is the culprit in about 70% of cases. Active Directory stores address book indices as separate files alongside the main database (NTDS.DIT). If one of those files gets corrupted — from a sudden power loss, disk error, or a failed patch — the count operation fails outright. I've seen this happen most often after a Windows Update reboot that didn't complete cleanly on Server 2016 or 2019.

The fix: Use ntdsutil to repair the indices. You don't need to take the DC offline for this, but it's safer to do it during a maintenance window.

1. Open Command Prompt as Administrator.
2. Run ntdsutil.
3. Type activate instance ntds.
4. Type files.
5. Type info to verify the database path.
6. Type integrity — this checks the database structure.
7. If it passes, type semantic database analysis and then go.
8. Finally, type compact to C:\temp\ntds (create that folder first).

The compact step rebuilds the index files. After it finishes, copy the compacted database back to the original folder (usually C:\Windows\NTDS), then restart the NTDS service or reboot the DC. I've never had this fail when the corruption was limited to the index files.

2. Bad LDAP Filter in Exchange or Third-Party Apps

This one's trickier. The address book index count fails when an LDAP filter references an attribute that doesn't exist or has a malformed OID. I've seen it most often with Exchange Server 2016 or 2019 when someone mucks with the address list configurations, or with third-party sync tools that query the GAL with custom filters.

You'll usually see this error paired with event ID 1655 in the Directory Service log. The event text will include the offending LDAP filter string.

The fix: Find and remove the bad filter.

1. Open Event Viewer and go to Windows Logs > Directory Service.
2. Look for Event ID 1655. The description will contain something like LDAP filter: (&(objectClass=contact)(msExchSomething=*)).
3. That filter is your target. If it's from Exchange, open Exchange Management Shell.
4. Run: Get-AddressList | Format-List Name,RecipientFilter. Look for the filter that matches the event.
5. Remove or fix it. For example: Set-AddressList -Identity "Offending List" -RecipientFilter {(RecipientType -eq 'UserMailbox')}.
6. If it's from a third-party app, you'll need to check that app's configuration for custom LDAP queries against the global catalog.

After you fix the filter, force a replication cycle: repadmin /syncall /AdeP. The error should clear on the next index rebuild attempt.

3. NTDS Database Fragmentation or File Bloat

This is rarer but worth checking if the first two don't help. Over time, the NTDS.DIT file can reach 40GB or more on a busy DC. At that point, the index counting logic can time out or fail due to file system limitations, especially if you're still on NTFS with a 16TB volume limit (which shouldn't be an issue, but I've seen it).

The fix: Perform an offline defrag of the database. This is different from a compact — it removes whitespace and reorders the B-tree indices.

1. Boot into Directory Services Restore Mode (DSRM).
2. Open Command Prompt.
3. Run: ntdsutil > activate instance ntds > files > info to check the current size.
4. Type: compact to C:\dsdata (or any drive with at least 20% free space).
5. Wait — this can take an hour on a 50GB database.
6. Copy the compacted file back: copy C:\dsdata\ntds.dit C:\Windows\NTDS\ntds.dit.
7. Reboot normally.

I've done this on a 60GB database and cut it to 42GB. The index counting worked immediately after.

Quick-Reference Summary

You've got this. Start with the online compact — it's quick and fixes the majority of cases. If that doesn't work, check those LDAP filters next. And if you're still stuck, the offline defrag is your nuclear option. I've never had to do more than that.