Criteria-Based Groups Changing to Manual Groups

I have searched quite a bit, but have been unable to find anyone with the same problem as I am seeing.

I can create "Criteria-Based Groups" using the portal.  They seem to work, and the "View Members" button shows the expected results.  But after a period of time, they always get changed to be "Manual" groups and no longer have any members.  If I flip the radio button back to "Criteria-based", the members come back, but then the groups revert back to "Manual" after some time.  When you try to view the properties of the group after the change an error appears in red text at the bottom of the screen - "static group has a filter".

I am trying to sync the groups out to AD.  I think that it may be when the MA runs to sync them to AD that they are getting changed, but I haven't been able to prove that, or figure out why.

One other test seemed to indicate that a "Manual" Group will also be changed (by the same process?).  If I set the Membership Add Workflow to "None", after a time, it get's set back automatically to what appears to be the default of "Owner Approval".

Any ideas?

I am running the latest version of  FIM 2010 R2. 

April 17th, 2013 1:44am

Are you importing any attributes of groups from AD or another data source?
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2013 1:57am

I am importing some groups, but these are just ones I'm creating from scratch that this is happening to.
April 17th, 2013 2:20am

You're probably overwriting MembershipLocked in your import rules.
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2013 2:54am

From what I can tell, the Inbound Sync Rule (which is setting the MembershipLocked as you suspected) is set up to run on the set of groups which does not include these "Groups Managed by FIM".  There is a separate Sync Rule set up to run only an Outbound sync on these Criteria-Based groups which will only be managed in FIM.  Is that not the way to do this?  

I double checked, and I don't see where the the MembershipLocked attribute would be overwritten for these "FIM Managed Groups" as these groups are not in the set "Groups Not Managed by FIM" to which the inbound Synchronization Rule applies.

Thank you for all of your help so far.  It is helping me better understand the problem (even though I haven't been able to fix it yet).
April 17th, 2013 4:21pm

Scott-

Inbound sync rules don't get applied to objects like outbound ones. Instead, they apply to all objects of the specified type in the connected data source. The only way to filter what they apply to is using the connector filter on the sync rule itself.

Free Windows Admin Tool Kit Click here and download it now
April 17th, 2013 7:22pm

Hi Scott,

I am facing the similar issue. so please suggest .

I have removed the membershiplocked attribute maaping from inbound rule as well stilll the issue is remain. its definately after we do the synchronization.

Appreciate your help!!!

Thanks

Vinayak Misal.

June 19th, 2013 12:45pm

This was the key for me:

Scott-

Inbound sync rules don't get applied to objects like outbound ones. Instead, they apply to all objects of the specified type in the connected data source. The only way to filter what they apply to is using the connector filter on the sync rule itself.

I had to put an "Inbound System Scoping Filter" on the Synchronization Rule to not have the dynamic groups brought back into FIM. This was the part that was confusing to me, as I had already set the "Apply Rule" to not apply to those groups using the MPR, set, and workflow, but in this case you also have to add the filter.

I hope that helps.

Free Windows Admin Tool Kit Click here and download it now
June 19th, 2013 3:22pm

This was the key for me:

Scott-

Inbound sync rules don't get applied to objects like outbound ones. Instead, they apply to all objects of the specified type in the connected data source. The only way to filter what they apply to is using the connector filter on the sync rule itself.

I had to put an "Inbound System Scoping Filter" on the Synchronization Rule to not have the dynamic groups brought back into FIM. This was the part that was confusing to me, as I had already set the "Apply Rule" to not apply to those groups using the MPR, set, and workflow, but in this case you also have to add the filter.

I hope that helps.

Hi Scott,

     I know this is an old thread but when you said you created an inbound scoping filter, I assume you mean you added that to your existing inbound rule for security groups in the fim portal. May I ask what was the criteria for this filter as I am experiencing the same issues.

January 6th, 2014 12:35pm

My inbound filter was easy as we named all of the groups with the same naming convention.  I just set up the rule to be sAMAccountName, not starts with, My-NamingConvention.  Your may not be as simple.  I hope that helps.
Free Windows Admin Tool Kit Click here and download it now
January 13th, 2014 4:03pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics