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.
- TheFIM_TemporalEventsJob runs at 1:00 am every night.
- There are warning in the Event Viewer (Windows Logs/Application) for the sourceMicrosoft.ResourceManagement.ServiceHealthSource regarding some groups and sets.
- Here is a sample message for a group, stating that an attempt to remove a member has been done (eventid34).
"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)