[Rebuild] - script call to rebuild a dynamic group, anyone?

Not sure if you have considered this but could you make a different (and hopefully less busy) ARS server responsible for your two large dynamic groups?

The affinity of the group is stored in the virtual attribute edsaDGOriginatingService.

Just thought I would put that out there.

consideration.

ARS rebuilds Dynamic Group based on "how heavy"  ldap query.

For example, if ldap query includes memberOf AD\group_condition is "heavy" for ARS - the change of membership of the AD\group_condition will make ARS to rebuild *all* members of the Dynamic Group. In large 50K users AD it might take 12h for ARS to finish up the rebuilt.

Recommendation1:  replace AD\group_condition to VA_condition attribute (single-valued number or string) per Dynamic Group. ldap query based on the VA is "light" and used to show time rebuilt drop from 12h+ to few min because it rebuilts the single member without affecting others already being member of the DG.

Option1: you may consider to ARS-focus DG group rebuilt to a dedicated new ARS server .Keep in mind that the slowdown might come form the DC response and not from ARS.

Interesting strategy so you are suggesting using another script to populate a VA of the user object when the user is added to the group being used as an include for the dynamic group?

If the processing overhead of using a group include is so high why is this strategy not part of the product?

Dynamic Group membership = F(ldap query). Ldap query can be any.

Stress testing is a different story. ARS is coded to guaratee a *correct* build of the DG membership. DC DirSync service does not provide very transparent infromation on  AD group (used for condition)  membership changes, that';s why ARS needs to do very heavy recalculations on its own.

We can target a different ARS host for execution of the Dynamic Group rebuild - and that introduces a different wrinkle ... when you split rebuilds across ARS servers, then any changes made have to replicate back to the others.  Merge replication has it's own issues in our environment, so I'm not sure that will be a long term solution, unless we move them all at the same time to a different ARS instance.  i.e. throw more money at the problem.

The original question was about whether or not it was possible to script a rebuild of an individual dynamic group.  Easy enough to track the count of members after a rebuild and - where there is a significant drop, trigger the individual rebuild - if such an animal exist.

I kept looking - and found this old post - tried the powerShell version further down the thread, which didn't work for me with powershell complaining :

Method invocation failed because [Quest.ActiveRoles.ArsPowerShellSnapIn.Data.ArsGroupObject] does not contain a method named 'InvokeSet'

en.community.dell.com/.../19555803

So, any of you experts have a way to make the PowerShell script from the above URL work in ARS 6.9+  ?

Hello, Dyannic.

I just tried a the code from that old post using v7.0.2 and it seemed to work just fine for me (with a minor adjustment):

$Constants = New-Object 'System.Object'
$Constants | Add-Member -MemberType NoteProperty -Name EDS_CONTROL_FIX -Value 4
$Constants | Add-Member -MemberType NoteProperty -Name EDS_CONTROL_CHECK_POLICY_COMPLIANCE -Value 5
$Constants | Add-Member -MemberType NoteProperty -Name DGPolicyGUID -Value "84C1A76B-2A6B-4f4b-837A-22D2CCAC777A"
$Constants | Add-Member -MemberType NoteProperty -Name ADS_PROPERTY_CLEAR -Value 1

$Group = [ADSI]"EDMS://CN=Test Dynamic Group,OU=Business Unit1,DC=qsftdemo,DC=com"
$Group.PutEx($Constants.ADS_PROPERTY_CLEAR, 'member', $null)
$Group.SetInfo()
$Group.InvokeSet('Control', $Constants.EDS_CONTROL_FIX, $true, @($Constants.DGPolicyGUID)) 
$Group.InvokeSet('Control', $Constants.EDS_CONTROL_CHECK_POLICY_COMPLIANCE, $true, @($Constants.DGPolicyGUID)) 
$Group.psbase.Invoke("CheckPropertyValues")

If "$Group.InvokeSet()" continues to fail for you, try "$Group.psbase.InvokeSet()" instead.

Good luck!
Shawn.

A good script, is like fine art.  Just looking at it makes you feel something.

This runs clean for me ... now I just have to wait for something catastrophic to happen....  ;)

If this does the job - I'll add it with the other suggestions to my admin tool belt, right next to the sonic screwdriver.

Thanks Shawn!

This reminds me of a task on my to-do list- stop using the lame built in dynamic group function. You may want to do some custom scripting to improve upon this. 

For instance, do a compare do the existing group, then action the existing group.  This is what ARS really needs to do, the way they do it now is extremely dangerous.

IE: Dynamic group rule is all members of department "Purchasing"

GroupA is a dynamic group.

asmith
bsmith
tthompson

some hiring and firing was done, and now all Purchasing people are:

asmith
tthompson
arogers
abanana

Currently, ARS will "rebuild" the group. Deleting all, and adding the filter match.   This is so bad on so many levels.

What needs to happen is this:

$1 = get group members of group A. (asmith, bsmith, tthompson)

$2 = get users that match condition department IT, (asmith,tthompson,arogers,abanana)

do a comparison.

for users that exist in list $2 but do not exist in $1, add to group A.  (tthompson, arogers, abanana)

for users that do not exist in $2 but exist in $1, remove from group A. (bsmith)

Write a failure to email or eventvwr and report on it.

This is so much safer on so many levels to just action the group based on changes rather than completely demolish it.  Since ARS does not support doing this natively, write yourself a script to do so. I haven't made one yet but it's on my to-do list.

You might want to take a look at Group Family - a different flavor of dynamic groups.  I don't believe it does the membership wipe.

You are correct, that functional logic was a little dangerous.

It's a good thing that we don't do that anymore. :-)

Defect TF00379596 was fixed in ActiveRoles Server 6.9 Patch 3.

Instead of clearing all members and rebuilding from scratch, we now only add the delta, similar to your description.

This is the same behavior carried forward in Active Roles 7.0.

For your reference, here are the release notes for ActiveRoles Server 6.9 Patch 3:

support.software.dell.com/.../133478