none
Groups & Sets, FIM_TemporalEventsJob : unable to correct "cached membership" RRS feed

  • Question

  • Hi,

     

    We have some weird behavior regarding the execution of our temporal set job and we cannot determine if there is a bug or if something is wrong with our design.

     

    1. The FIM_TemporalEventsJob runs at 1:00 am every night.
    2. There are warning in the      Event Viewer (Windows Logs/Application) for the source Microsoft.ResourceManagement.ServiceHealthSource regarding some groups and      sets.
    3. Here is a sample message for      a group, stating that an attempt to remove a member has been done (event id 34).

    "The Forefront Identity Manager Service identified and corrected an error in the cached membership of a dynamic group: 10AEE3CE-FE3D-4FF8-81FD-483B044F3752.

     

    Correction:  Removal

    Member: 9153AC48-9AAE-48FE-AF52-51C180ADDCBF".

     

    Weird Behavior 1

    Every night, exactly the same execution occurs (i.e. same sets and groups corrected with the same members removal) in the Event  Viewer! The job seems to be unable to remove the users from this so called "cache". This is contradictory with the event IDs logged.

     

    Weird Behavior 2 (probably linked to #1)

    If I log-in to the portal and check one set ("View Members" button) the so-called corrected member is not listed as a member. That set is typically used in a transition-in MPR that determines the user status (active/inactive). In our case the user is never de-activated.

    If I change manually the attributes that determines the set membership (en date in the future and then back in the past), the user end-up being deactivated.

    If I re-run the SetTemporalJob again, the same event id occurs and the user ends being reactivated.

     

    Q1 : What's this "membership cache" ?

    Q2 : Any idea regarding how to fix this annoying behavior ?

     

    Thanks in advance for your help,

    Sylvain


    Edit (product version) : FIM 2010 R2 SP1 (build 4.1.3441.0)
    • Edited by Sylvain_Castillon Friday, November 22, 2013 2:31 PM added product version
    Friday, November 22, 2013 2:19 PM

All replies

  • I'm not offering an answer, but in my experience this tends to point to a problem with either the filter definition or with index fragmentation of selected FIMService database tables.  Check for evidence of the error in the above link.


    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Sunday, November 24, 2013 2:30 PM
  • Same issue for a temporal SET on this version (but with event ID 33).

    I updated to last build (4.1.3496.0) but the issue is not corrected.

    Monday, November 25, 2013 10:03 AM
  • I found it on SCOM MP for FIM documentation. So, SQL Job corrects membership but not entitlement. Manual action has to be done in order to check and correct entitlement.

    FIM Service Set Corrections

    The FIM Service periodically checks whether its set memberships are correct. If these memberships are incorrect, then users may have the wrong policy applied to them.

    This monitor changes state when the FIM Service discovers that a set membership was incorrect and users may be out of policy. An example of being out of policy is in a rare condition when a user may get provisioned an entitlement he or she would not otherwise have access to because of an incorrect set evaluation. The FIM Service corrects the set membership, but does not correct the entitlement. It is necessary for a FIM expert to audit the user’s entitlements to ensure that they match the desired policy.

    Because this monitor requires a FIM expert to investigate, the monitor is implemented as a manual reset monitor. We recommend enabling this monitor only if you have a process in place to investigate and resolve this monitor manually. Our experience shows most customer environments never encounter this situation and that this monitor may be safely disabled. Other mechanisms including auditing reports can help protect against undue entitlements.

    Target: FIM Service

    ID

    Microsoft.Forefront.IdentityManager.2010.Service.Monitor.ServiceVerifiesSetMembership

    Name

    Set Membership Cache is Correct

    Trace source

    Microsoft.ResourceManagement.ServiceHealthSource

    Event ID

    33

    Occurs

    When the FIM Service identifies an incorrect set membership, this monitor changes state.

    • Proposed as answer by UNIFYBobMVP Tuesday, November 26, 2013 1:09 PM
    Tuesday, November 26, 2013 11:32 AM
  • This WIKI article may assist further understanding.

    Bob Bradley (FIMBob @ TheFIMTeam.com) ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Tuesday, November 26, 2013 1:16 PM
  • Thanks for your replies.

    If I may add something, my guess is that when the FIM_TemporalEventsJob triggers too many membership updates you might encounter some "cached object removal/add" errors (Health ID 33/34).

    As a matter of fact, having too many Set correction should definitely be a thing to avoid and the Wiki article (Markus), your blog entry and this blog entry (Carol) explains very well the basics on how to prevent some design flaws, identify performance issues and monitor these events.

    • That was our case : we had too many dynamic groups with temporal filter defined; they were automatically generated based on some objects lifecycle.
    • After redesigning these group filters, deleting the old ones and generating the new ones, the FIM_TemporalEventsJob didn't triggered any new event ID 34.

    If I'm correct about the fact that what really explains this issue is the amount of membership update requests generated; you could probably encounter this error with a very simple filter definition after just batch updating users' attribute linked to this filter. Then, you would probably have to manually correct the associated errors with some workaround.

    • Redefine the XPath filter and exclude the users' Resource ID referenced in the events ID 34.
    • Save the Set.
    • Put back the original XPath filter.

    I'm still wondering whether the difference between ID 33/34 is linked to a "Set/Group" or to "Temporal/Not Temporal" concept though…

    Wednesday, December 11, 2013 11:04 AM