Dynamic Group - Update

Yes, there are a few ways to do this.

The easiest way is to simply re-write the existing accountNameHistory value to the accountNameHistory attribute.

This will trigger a Dynamic Group rebuild.

You could use something like this:

$group = Get-QADGroup GroupDN -IncludedProperties accountnamehistory

$accountnamehistory = $group.accountNameHistory
   
Set-QADGroup $group.dn -ObjectAttributes @{accountNameHistory=$accountnamehistory}

Thank you. still testing but looking good 

There is a schedule task in the Server Configuration section of Active Roles called 'Dynamic Group Updater.'  Is there a reason to use this PowerShell script over that scheduled task?  

Does the above still apply for v8.6?
Does it still log an event (2589) for the manual DG rebuild trigger?

I see an event 2692 for successful accountNameHistory attribute update for a DG but don't see the 2589 event?  The metadata of the group member does not update either, so not sure if the manual DG rebuild is working as expected?   

Hi pramkris,

Could you clarify whether by “manual DG rebuild” you mean:

- clicking Rebuild on the Dynamic Group’s Members tab, or
- rewriting accountNameHistory with the PowerShell example above?

The PowerShell trick still works in Active Roles 8.6, but these actions are not equivalent in 8.6. The PowerShell example modifies an internal storage attribute; any rebuild is just a side effect, not a supported rebuild interface. Event 2692 confirms only that the attribute update succeeded and it does not confirm a rebuild.

The MMC Rebuild button is the supported targeted method and should log Event 2589 when the rebuild is queued. If membership is already correct, no member update is performed, so the group’s modification metadata may remain unchanged.

For routine reconciliation, I recommend using the built-in Dynamic Group Updater task under:

Active Roles MMC → Configuration → Server Configuration → Scheduled Tasks → Builtin

Hi Ferenc,

Thanks for the reply. I am using the rewriting accountNameHistory with the PowerShell method.

On v8.6, after setting DynamicGroupEventLogVerbosity to 1, I can see 2589 events. When DynamicGroupEventLogVerbosity set to 0, I do not see the 2589 events, but I would guess the manual force rebuilds are still being triggered, it's just that it won't log it.

Sure, I understand the built-in Dynamic Group Updater task. The PS method is only a temp workaround while we upgrade to v8.6.

However, on v8.2.0, since DynamicGroupEventLogVerbosity is unavailable/ unsupported, I am unsure if it's the same behavior as in v8.6? Please advise.

Your assumption is correct for 8.6 in one respect: DynamicGroupEventLogVerbosity controls which events are recorded; it does not control whether the request is processed. However, rewriting accountNameHistory queues a normal, non-forced evaluation. It is not equivalent to the MMC Rebuild command which queues a high-priority, forced rebuild.

In 8.6:

- At verbosity 0, a membership-changing rebuild is logged (Event 2589), but a no-change completion is not.
- At verbosity 1, the no-change completion is also logged (Event 2589).
- Therefore, seeing Event 2589 only at level 1 is consistent with an evaluation that ran but found no membership difference.
- Event 2692 confirms only the accountNameHistory attribute write.

The 8.2 implementation is different and has no DynamicGroupEventLogVerbosity setting:

- Events 2529 and 2588 indicate that the membership evaluation started and completed.
- If that evaluation detects a membership difference, Events 2528 and 2587 indicate that the actual membership update started and completed.
- Event 2589 represents an evaluation failure in 8.2.

In both versions, rewriting accountNameHistory is an unsupported side-effect workaround, not a manual force-rebuild interface. The MMC Rebuild button remains the supported method for intentionally rebuilding one group.