Dynamic Group Resolution Limit?

[jared_kobe]

We recently created a few dynamic groups to assign certain roles and access automatically. I have it set up to resolve these groups via a script that runs at the end of a maintenance job.

The issue we encountered upon our initial load was that it would only add 1000 users at a time via the script. Is there a setting somewhere in the console that puts this limit in place?

Alternatively, I tried to resolve the group from the group properties themselves. This also failed as it gave me a time out message; however it would not allow me to retry because a process to resolve the group was already running! Has anyone encountered this and found a way to terminate that process?

I was just wondering if anyone else had encountered these issues and how they resolved them.

Thanks,

Jared

[Former Member · Accepted solution]

Yes, on the initial load, they will only load 1000 at a time. We ran into this problem too (had one group of 12,000 people) but just ran it 13 times using Right Click -> Recalculate.

When they crash or deadlock, they will claim to still be running for a long time. This is because of the way they do locking:

1) When the recalculation starts, it chcecks the ModifyTime column on the attribute "MX_DG_AUTORESOLVE_INTERVAL" for that Dynamic Group. If it is in the past, it continues to step two, otherwise it aborts with the error saying it is already running.

2) It sets the ModifyTime on that attribute to a future date (I forget how long exactly, but we're talking about DAYS in the future).

3) It does the calculations.

4) It sets the ModifyTime to the time it finished.

So, you see the problem -- when it crashes, the time remains far in the future.

You mentioned you run the update from a script, and that is what we do too. There is supposed to be a way to trigger the calculation based on an Attribute Change, but the feature does not work as documented in the manual. Frustrating...

Anyway, this is how I get around the issue in our script:

function recalcInternetGroups(Par){
	uSleep(10000); //Give any previous attempts at least 10 seconds to finish resolving

	importPackage(Packages.com.valero.idm);
	var sqlClass = new SQLServerConnection();

	var SQL = "Select MSKEY FROM dbo.MXIV_SENTRIES WHERE searchvalue LIKE 'INTERNET_LEVEL_%' AND attrname = 'MSKEYVALUE'"
	groups = uSelect(SQL);
	var result = groups.split('!!');  //We have 9 INTERNET_LEVEL groups, refresh them all
	for (var i=0; i<result.length; i++) {
		dynamic_group = result<i>;

		// Manually set the date into the past (picked the date I wrote this script, as it doesn't matter how far in the past)
		var sql2 = "update MXI_VALUES set Modifytime = '2010-10-15 00:00:00.000' where MSKEY = " + dynamic_group + " and Attr_ID = 33";
		var resultUpdate = '' + sqlClass.uUpdate(sql2);

		recalc = uIS_ResolveDynamicGroup(dynamic_group);
		if (recalc.indexOf("ERROR")>0) {
			uError("Recalculating " + uIS_GetValue(dynamic_group, uGetIDStore(), "MSKEYVALUE"));
			uError(recalc);
		} else {
			uWarning("Recalculating " + uIS_GetValue(dynamic_group, uGetIDStore(), "MSKEYVALUE") + ' ' + recalc);
		}
	}
}

You'll note we have our own function to allow us to run database updates in Javascript, which is required for this to work, since uSelect() won't perform updates. Anyway, doing that solves the problem. I guess you could do the same thing if you just made a To Database pass that runs before this and does these changes.

If you pick up any other tips or tricks on dealing with Dynamic Groups, let me know, as we use them fairly extensively and still find them somewhat frustrating at times.

[jared_kobe · Accepted solution]

Adam,

Thanks for the tip and the script. I knew that there had to be some setting somewhere that controlled the "process running" setting. Its also a little comforting to know that we weren't the only ones that encountered this issue.

For the groups we encountered this issue with, we were trying to assign a role that gave members access to the Manage Tab privilege and another privilege with event tasks tied to it. Since this was only an issue on our initial load, my work around was to run a To Identity Store pass, with the group filter as the source query, to add the entires to the group under MXMEMBER_MX_PERSON. That was fine for adding everyone to the group. I then had to remove the autoassign to for the role and then re-add it to trigger the role assignments for the group members and the event task.

It was no where near as elegant as it should have been, but for the initial load it worked in a pinch. Since the additions/removals from the groups are expected to be significantly less than 1000 going forward, the termination script is expected to work fine.

Thanks,

Jared