I have been doing a lot of work within my clients where I have been basing set information on boolean values that were set with other MPR’s and workflows. It allowed me a couple of benefits in that I would have clearly defined logic in my set/group definitions.
In my travels however, I noticed a bit of a wrinkle and although rather easy to get around, if you’re not aware, you can run into issues of users not being in groups/sets when expected.
There are three states to the Binary Attributes in FIM:
- <no value>
The <no value> setting is the default and therefore, you can have logic failures if you simply test for a boolean attribute being either true or false because you leave out an entire condition. The FIM service does not assume that this value is False. It leaves it up to you to define the initial value.
For these examples, assume that we want to <no value> to be considered false when we’re creating sets. We have a couple ways to accomplish the set of users who are true and those who are false
Create the set of users who have the attribute value set to “True” and then create the secondary set of users who don’t have the attribute set to “True”. Granted this uses the “not” function that we’ve been warned against but the performance seems to be rather healthy on the systems I’ve been playing with.
Create the set of users who have the attribute value set to “True” and then create the secondary set of users as those who are not members of the first set. This is the solution that Microsoft provided to me when I logged the issue on connect. It is functional as well and also treats the value as though it was false.
Mitigation Strategy and Workaround
Personally, I prefer to have some form of happy mitigation whereby I always have a set value in the boolean attributes and I am not making assumptions. Therefore, a simple mitigation strategy I use that sets the value to false if there is no value is as follows:
- Create a set of users who have an attribute value of neither “True” or “False”.
- Create a workflow that sets the value of the target attribute to false.
- Create a transition set workflow that on transition in will trigger the workflow.
This allows the objects to be created and then when there is no value in the appropriate attribute, it sets it. You could reduce the search overhead for the initial set of users by simply saying “is not True” but the initial execution of the workflow would have *everyone* who had a value of false or <no value> updated with False. You can decide on the tradeoff for initial loading of the values versus the ongoing costs of the searches in your environment.