Hi,

I am having a problem with Set Transition kicking of a MPR, in FIM 2010 R2 which I have never seen before after numerous implementations of both FIM and FIM R2. 

Scenario: 

My MPR kicks off a workflow which adds 6 sync rules, to users based on the "set transition in" set with criteria IsADConnected=true.

The user is transitioned into this set but the MPR never fires. Everything is enabled and I have checked everything obvious. When I view the set in the "Sets" screen in FIM I can see that the user has transitioned in, and is a computed member based on my criteria "IsADConnected=true"

The "FIM_MaintainSetsJob" job runs at 1am which auto corrects set membership and this does cause the MPR to kick off and consequently the sync rules to be applied. So it does work, just not when it should.

•  What I have tried to fix this:

Created a new workflow, set and MPR which does exactly the same job as the "broken" Set/MPR/workflow - Same thing happens (ie. it doesn't work)

I read on one post that someone re-indexed the FIM service database and this fixed it for them - I tried this also but no joy. (some indexes were at 98/99% but they have been reduced after reindexing)  

Has anyone ran into this issue before and does anyone have any idea what can cause it? It's doing my head in at this stage!

Thanks

Paul

Hi,

I think your set is not temporal based? in this case, it will be immediate when you add someone into the Set. Also, when add someone into a set, do you see System Events on the Search Requests page? I think FIM_MaintainSetsJob primarily ensures the set populations based on date/temporal events. I've seen my MPRs not triggered for set based transitions when there is an issue with my WFs. 

Hi Prakaaz,

              The set is not temporal based. And it is not applying immediate each time a user transitions into a set. No system events are being created in the search requests screen. On the "update Person" where it will show any MPR's which should be fired, the MPR mentioned is not being fired. 

Just a while ago, I have actually tried creating new attribute called "ADconnected" (rather than my old attribute "isAdConnected" and applied the same MPR/Sync rule when this new attribute is true and the MPR runs and this adds the sync rule as expected.

I might just go with this fix, creating and using a new attribute but I still wonder how an attribute can get messed up and cause the set not to be updated in the background..

I'm glad that the new attribute worked for you. By any chance, do you use more than 1 FIM Services under LB? If that is the case, after creating new attribute / binding, i would recycle FIM services on all the instances. Not sure if that is the case on your scenario. 

Hi Prakaaz,

       No we only have the one FIM service server, so no LB.

This is a strange one which we have never seen before, particularly strange since the MPR did work originally, stopped working but still worked on policy update and when the maintenance job ran but not in real time as it should. One other thing to note is it is an "indexed string" type of attribute which I was using, this is what makes me think the indexes got messed up, but reindexing this at a SQL level, did not solve this. 

 I already have a case opened with MS, and will try push them for an answer as to how this can happen (however unlikely will not get an answer as I have it "fixed"). If anyone else out there can give me a reason of what could have happened please do as i'm curious. 

Thanks

Paul

Hi,

Were you able to figure out the cause of this issue or were you provided with an answer from microsoft? I'm having a similar issue but I have several attributes in the set that are used throughout the FIM Service and recreating all of them isn't a great option :).

When my mpr is triggered and the set criteria-based membership is calculated imediately the email notification is sent as expected. However, if the user is not added to the set imediately and I run the maintain sets job the user is added to the set as desired but the email notification workflow associated to my request based mpr is not triggered. I have no idea when/why the set calculates imediately sometimes and not immediate other times. This set is not a temporal set.

Thanks in advance!

I ran into the same problem using the pattern for expected state detection:

/Person[DetectedRulesList = Set[ObjectID='<GUID of the Set with the DREs>']/ComputedMember]

Pasted from <http://technet.microsoft.com/en-us/library/ff608269(v=ws.10).aspx> 

My users weren't transitioning into the set when they got a DRE.  Went on a wild goose chase until I saw this post.  Enabling the FIM_MaintainSetsJob fixed the problem.  Pretty frustrating...