Has anyone encountered issue with DG rebuild post upgrade to 7.5.3 ?

We just upgraded from 7.3.1 to 7.5.3.
dynamic groups had execution host set to specific ARS servers to split processing load.

Part of upgrade requires a break in replication.  we upgraded one environment, and made it publisher in SQL.

doing this makes the winning publisher completely unaware of the execution host that is set for dynamic groups pointed to the losing host.

ARS does no harm.  if the execution host shows '<Unknown>' - then no new processing is performed - but existing members remain.

We realized this after the upgrade and ran a script to set execution host to the new ARS host attached to the publisher.

however, the DG did not completely rebuild - for several ... to many, groups.

forcing a 'rebuild' ddin't change the member count

only after making a change to the properties of the rule forced re-evaluation and the group membership grew.

has DG processing changed between 7.3 and 7.5  in a way that might explain this behavior

our DG's were build using powershell, worked for years - until the issues encountered during the upgrade

'custom/advanced' membership rules config

(&(&(objectcategory=computer)(samaccounttype=805306369))(&(edsvaComputerConfig=I-AM-A-RULE)(objectclass=computer)))

I was able to trigger the rebuild to execute properly by adding a custom search by field, and setting the rule there.  

  • We've found a very weird bit of behavior for advanced ldap filtering for a dynamic group in 7.5.3
    if we list the same custom VA query TWICE in the filter, then it properly populates the group.

    below - works after the upgrade to 7.5.3, 

    (&(&(objectcategory=computer)(samaccounttype=805306369))(&(edsvaComputerConfig=I-AM-A-RULE)(edsvaComputerConfig=I-AM-A-RULE)(objectclass=computer)))

    opening a ticket with support.

  • Hello,

    I did see such an issue with Dynamic Groups (DG) after upgrade to 7.5.x. The issue is sporadic and not on all my customers, but few. DG shows execution host shows '<Unknown>'. After setting explicitly the DG execution host = ARS01.xxx.zzz, the issue is resolved, and group membership returns to be correct again.

    Unfortunately, the issue was confirmed with support. There is a KB article, you may find. I recommend to open SR to confirm the workaround suggested in the KB.