Restoring legacy application compatibility after adprep /forestprep ?

The potential issue is the searchFlags value on the custom attributes. adprep /forestprep schema update can alter or replace the searchFlags configuration associated with custom attributes. The attributes themselves can remain intact while losing an indexing-related flag that the legacy application depends on.

Check the affected attribute definitions under Active Directory Schema or query them with PowerShell/ADSI and compare their searchFlags values with a known-good environment or backup. In particular, determine whether the attribute has the appropriate indexing bit enabled. The searchFlags attribute is a bitmask, so you should not just replace the entire value without checking what other flags are already set.

For example, you can inspect an attribute with:

Get-ADObject
    
    

If the required indexing flag was lost, correct the schema attribute definition, not each individual user object. After changing searchFlags, allow AD replication to complete and then verify the application's LDAP queries. Also check whether the application is relying on ANR (Ambiguous Name Resolution) or another specific search behavior, because not every searchFlags setting means "indexed." The exact bit that needs to be restored depends on what the application's LDAP query is doing.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Hello @Redda Krongpilas

Since the custom attributes are still present, I would not roll back the schema or restore Active Directory. adprep /forestprep extends the schema and updates AD as required for newer Windows Server domain controllers; schema changes aren't intended to be rolled back as a normal troubleshooting step.

If the legacy application depends on indexed searches against a custom attribute, check the attribute's searchFlags value in the schema. Microsoft documents that bit 0 (0x1) controls basic attribute indexing. When that bit is enabled, AD dynamically builds the index in the background.

For example, first inspect the affected attribute:

Import-Module ActiveDirectory
$schema = (Get-ADRootDSE).schemaNamingContext
Get-ADObject `
  -SearchBase $schema `
  -LDAPFilter "(lDAPDisplayName=YourCustomAttribute)" `
  -Properties lDAPDisplayName,searchFlags,isMemberOfPartialAttributeSet

If searchFlags no longer contains the required indexing bit, don't simply set it to 1, because that could unintentionally remove other flags. Preserve the existing flags and add the index bit:

$attr = Get-ADObject `
  -SearchBase $schema `
  -LDAPFilter "(lDAPDisplayName=YourCustomAttribute)" `
  -Properties searchFlags
$newFlags = ([int]$attr.searchFlags -bor 1)
Set-ADObject $attr -Replace @{searchFlags=$newFlags}

Perform schema modifications carefully on the Schema Master using an account with the appropriate Schema Admin permissions, preferably after confirming the attribute's previous definition in documentation or a known-good environment. Microsoft notes that searchFlags is a Schema Administrator-controlled property.

Also check whether the application queries a Global Catalog rather than a normal DC. isMemberOfPartialAttributeSet determines whether an attribute is replicated to the Global Catalog, so an attribute can still exist in AD while a GC-based application doesn't receive it as expected.

After correcting an indexing-related searchFlags value, index creation occurs automatically in the background. Depending on configuration, Windows Server 2012 and later can also delay index creation until a schema-cache refresh, DC restart, or implementation-dependent interval.

I would therefore compare the affected custom attribute's searchFlags and isMemberOfPartialAttributeSet values before and after the schema update before changing anything. If those values are unchanged, capture the LDAP query generated by the legacy application—the problem may be its query behavior rather than the AD schema itself.

Sharing these references with you:

Microsoft Learn – Indexed Attributes

Microsoft Learn – searchFlags attribute

Microsoft Learn – Adprep

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.