I have a weird situation. The scenario work in Sandbox, but after migration to Test it doesn't I have a set with the following criteria: Status is Pending Employee Start Date prior to 1 day from today Pending users with start date today or before is in the set when using View Members. The MPR is not triggered for users who has a start date within 8 days (on the minute) from today. Can anyone explain that? Thanks Willy

You should post the configuration of your MPR. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi There, Try running the SQL Agent Job named "FIM_TemporalEventsJob" and see if the group membership has changed for you to fire the MPR. I have had instances where I needed to run the SQL Agent Job for the MPR to fire if there was more than the temporal decision being made in the Set. The view member button would show me the users as part of the set however, the MPR still didn't fire until after the SQL job was executed. I have worked around this by creating some "flag" boolean attributes in the portal with only the temporal clause defined as these change immediately and then my other set (being based on non-temporal data) fired immediately. E.g. This MPR sets the flag MPR Set Account Expired Flag to True - Type - Transition In - Set - Users past expiration date (all users with expiration date before today) - Action Workflow sets value of the "AccountExpired" flag to true" This MPR fires when that MPR sets the flag among other criteria MPR Expire Account - Type - Transition In - Set - Users past expiration date (all users with account expired true and other criteria as required. - Action Workflow - Disable User Account Thanks B

I investigated the above issue for Willy based on Blain's post ... and I discovered that in the Test environment the job "FIM_TemporalEventsJob" were not able to execute ... everytime the SQL Agent tried to execute the job it gave the error "Unable to determine if the owner [DOMAIN\user] of Job FIM_TemporalEventsJob has server access ..." The owner was set by the FIM installation, so apparently the user that was used to install FIM do not have appropriate access. The user is part of the local administrators group and is sysadmin in SQL and owner of the FIMSevice Database ... When I changed the owner of the job to a user with Domain Admin rights th ejob was able to execute ... and when doing a new test the MPR is now triggered even though the job is only scheduled to run once a day ... so my guess is that FIM under the hood executes this job !? Can anyone tell me what the minimum required access rights are for the user who is owner of the four SQL Server jobs ? /Frank

That is an interesting question however, I don't see any errors when Im using my temporal sql agent job to recalculate the groups... I find that once the criteria get over a certain complexity, the temporal group/set components are not recalcuated.. B