This is another one of those questions that I’m debating to myself. I want to minimize the use of “not” statements in my group criteria as recommended by Microsoft so that I don’t saddle my group performance with a lot of “high-cost” checks. In a lot of cases these checks are simply a means for me to validate whether or not a certain attribute is present so that a workflow can be triggered successfully.
To workaround the use of nots, I have a working scenario for this where I use MPR’s to set boolean attribute values in the FIM Service. There are a variety of pros and cons to this scenario in my mind:
- Easier to read group criteria. Simply being able to do a lot of “True” and “False” comparisons is much easier than having to read and look for all those attributes that are not equal to “%” (which really isn’t that readible to a client who is probably just ramping up in FIM).
- Better performance when generating group memberships in lieu of using “Not” statements in the filters.
- More attributes and MPRs to manage.
- Performance impact of extra MPR’s being run.
Note that both in the Pros and Cons section (specifically item 2) both refer to performance. It is important to test and balance the performance of the group creation to the performance of the MPRs which can slow the import of data into the system if you’re triggering too many.
Attribute values can be set for “True” and “False” based on presence using an action workflow which fires as part of a creation MPR. Using the function evaluator, set the target to the boolean attribute and then set up a custom expression that evaluates whether or not the attribute is present, IsPresent(<attribute>).
Again, FIM performance is a balancing act. There are many ways to do different things and you should try to explore a couple of the available options to ensure you get the best performance you can from your system.