The objective of this article is to help you to identify whether your FIM service has an issue with processing too many set correction requests.

What is a set correction

A set correction is necessary when a set definitions consists of at least two attributes that have been changed simultaneously.

For example, request 1 changes the attribute a1, for object o1 to be value v1.
Simultaneously, request 2 changes the attribute a2, for the same object o1 to be value v2.

A set that relies for an object to have both v1 and v2 would now need to be corrected since when each request was evaluated, the set condition was not satisfied.
However, after both requests have completed, the condition is now satisfied.

How to determine whether set corrections are occurring

You can determine whether set corrections are occurring by looking at the event log for set correction related FIM health events.
The health events identify, which sets are being corrected.
The set correction process is controlled by a SQL agent jobs - FIM_TemporalEventsJob.

In the job, the FIM_MaintainSetsStep step is used to correct the Sets in the system.
Be default, the job runs once a day and can be confirmed by reviewing the SQL agent jobs configuration.

Determine the frequency of the set corrections

Assuming the job is running nightly, how often are the health events being generated? Nightly? Weekly?

Isolate which requests may be causing set correction needed to be applied

This can be done by increasing the frequency of when the set correction job executes.
The requests in the window between the last set correction run and the current run which generated the health event are candidate requests that are causing the set correction to fire.
Once you have the candidate list, does the replay of the any of the requests followed by the execution of the job cause a health event to be fired?

What frequency of set correction health events is reason to be concerned

In general, set correction should not be occurring on regular bases.
They should be an exception and are normally caused by multiple simultaneous requests that are together affect the set membership of an object.
Under normal conditions such a condition would not occur frequently.



note Note
To provide feedback about this article, create a post on the FIM TechNet Forum.