When responding to this FIM forum post tonight it occurred to me that monitoring for and troubleshooting these events is something I’ve probably not rated highly enough on the priority list.
Digging a bit further I stumbled upon this TechNet WIKI article from Markus – and it reinforced the thought that behind every recurring set correction you are likely to uncover a policy design flaw that’s probably going to be a pain in the !@&*#! to track down. This is right up there with the failed FIM request that occurs when two multiple workflow instances are spawned attempting to concurrently apply the same action on a FIM object – where one succeeds and the other fails with a “denied” exception. These types of errors are really the hardest to pin down, and it’s why I’m bothering to post about them.
Markus explains a scenario which can cause the set correction condition to occur – I had to read it a couple of times before I understood this. Maybe you will too – in which case the following variation may help:
The end result of multiple updates for the same FIM resource may well be that the resource satisfies a set criteria, but each not after each request individually. If requests are processed on a single thread sequentially, then the last request would be expected to cause the criteria to be satisfied. However, in periods of high volatility and multi-threading, if the individual requests are processed concurrently it is possible for all requests to be fully processed without the set condition having been satisfied. When this happens set correction is required.
Of course there are going to be other reasons for set corrections being required too – such as exceptions occurring evaluating complex set criteria (particularly when the FIMService database indexes become overly fragmented, or when your criteria is just too complex for FIM to handle). There is always a trade-off here:
- reducing the number of set definitions you need at risk of increased complexity (and relying on a defrag/index rebuild regime)
versus - using additional nested sets to simplify individual set criteria but (arguably) reduce solution maintainability and risk running foul of stated best practices in this regard.
Note to self – whenever monitoring the health of the FIM Service, look not only at the exceptions and the failures, but also for the presence of set corrections. Of course if you have SCOM and the FIM 2010 Management Pack (my customer chooses not to) you will no doubt already have the following in hand:
The key monitoring scenarios covered by this management pack are listed below:
- End-User Availability
- Synchronization Service Availability
- FIM Service and Portal Availability
- FIM Portal Errors Shown to End Users
- FIM Portal Configuration Errors
- FIM Service Internal State
- FIM Service Set Corrections
- FIM Service Connectivity with Exchange
- FIM Synchronization Service Configuration Errors
IdM for Real 
Thanks for highlighting this. As you know I’ve been struggling with similar problems using complex sets that are critical in the active/inactive decision point. It’s made me think of another advantage of the Transitional Transition-In sets I blogged about recently (http://www.wapshere.com/missmiis/transitional-transitionin-sets). If you have very complex rules that involve some different sub-categories, but the end result is object gets flagged ‘Active’, then have different transitional sets representing each subcategory. Each triggers the same WF flagging ‘Active’ at which point the object moves out of the transitional set and into the final ‘Active Objects’ set, which always has a simple rule. Meanwhile, by using more than one transitional set, you’ve simplified their logic as well. You just have to make sure they don’t overlap.