none
Criteria-Based Groups Changing to Manual Groups RRS feed

  • Question

  • 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. 

    Tuesday, April 16, 2013 10:44 PM

Answers

  • 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.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Proposed as answer by Todd_Mollerup Wednesday, April 17, 2013 5:52 PM
    • Marked as answer by Scott Holmes Thursday, April 18, 2013 3:00 AM
    Wednesday, April 17, 2013 4:22 PM
    Moderator

All replies

  • Are you importing any attributes of groups from AD or another data source?

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Tuesday, April 16, 2013 10:57 PM
    Moderator
  • I am importing some groups, but these are just ones I'm creating from scratch that this is happening to.
    Tuesday, April 16, 2013 11:20 PM
  • You're probably overwriting MembershipLocked in your import rules.

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Proposed as answer by Furqan Asghar Wednesday, April 17, 2013 9:59 AM
    Tuesday, April 16, 2013 11:54 PM
    Moderator
  • 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).
    Wednesday, April 17, 2013 1:21 PM
  • 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.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Proposed as answer by Todd_Mollerup Wednesday, April 17, 2013 5:52 PM
    • Marked as answer by Scott Holmes Thursday, April 18, 2013 3:00 AM
    Wednesday, April 17, 2013 4:22 PM
    Moderator
  • 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.

    Wednesday, June 19, 2013 9:45 AM
  • 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.

    Wednesday, June 19, 2013 12:22 PM
  • 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.

    Monday, January 6, 2014 9:35 AM
  • 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.
    Monday, January 13, 2014 8:59 PM