Optimizing Custom AD Schema Attributes After adprep /forestprep

Question

Following an adprep /forestprep schema upgrade, a legacy application querying custom attributes on the User object is experiencing degraded LDAP search performance. The custom attributes were introduced through a previous schema extension and are currently not indexed. What's the recommended method for modifying searchFlags on existing schema attributes to support indexed searches without introducing replication overhead or Global Catalog inconsistencies?

Answer 1

Hello,

When you extend the forest schema with adprep /forestprep, any legacy application querying custom attributes can suffer degraded LDAP performance if those attributes were never indexed. By default, schema extensions often leave searchFlags at 0, meaning no indexing. The recommended and supported way to improve query performance is to modify the searchFlags value on the attribute definition in the schema partition, but this must be done carefully to avoid replication overhead or Global Catalog inconsistencies.

For attributes that need to be indexed, you update the searchFlags property in CN=Schema,CN=Configuration,DC=<forest> under the specific attribute object. Setting bit 1 (value 1) enables indexing. If you want the attribute to be included in the Global Catalog, you set bit 4 (value 4). If you only need indexing within the domain controllers and not GC replication, you should set searchFlags=1 and avoid setting the GC bit. This ensures the attribute is indexed locally for LDAP searches without introducing unnecessary replication traffic across the forest.

The modification must be performed with adsiedit.msc or via ldifde/PowerShell using Set-ADObject. For example, in PowerShell:

powershell

Set-ADObject -Identity "CN=customAttribute,CN=Schema,CN=Configuration,DC=contoso,DC=com" -Replace @{searchFlags=1}

After the change, allow schema replication to complete, then restart the Active Directory Domain Services on each DC to ensure the new index is built. You can confirm indexing by checking the NTDS.dit database with esentutl or by monitoring LDAP query performance.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.