It is that time of year when kids get to write their letters to Santa and really hope that their wishes come true and the presents they asked for appear under the tree.. In that spirit, I am looking at some of the different bruises and such I received during the last couple implementations of FIM and have created this wish list (although those who have followed my blog will already know some of them).
1. Please allow reference attributes to be used in conditional statements either in declarative rules or via rules extensions. I have had to go through way more trouble to simply blank out an attribute value than I think its worth because of this issue. Rules extensions are a definite preference to me because the csentry(“referenceAttr”).Delete() was really all I needed and could have done with previous releases.
2. Manual Precedence for the FIM MA. This is huge to me. I have two sources of group information and depending on if it is a FIM managed group of manually managed group, the memberships of the groups flow from one source or the other. Regrettably, the lack of manual precedence has made me do the voodoo magic of pushing the membership of AD into a temporary attribute then use a custom workflow that runs if a change is made to that attribute when the sync engine updates the group in the service to either copy the value to the membership attribute in FIM or not.
3. Make the function evaluator smarter. There are other third party tools out there such as the Tools4FIM function evaluator but why does there need to be a third party tool. This should be native within the product to perform these simple functions:
- Date functions. Adding and subtracting a period of time from a date in an attribute or from today. We have these great things called temporal sets which really rock but not having good time manipulation functions so we can readily enforce business policies (such as setting expiration dates to some point in the future) is both bothersome and frustrating.
- Copying of all Attribute types. The current function evaluator cannot copy multi-valued reference attributes from one reference attribute to another. It seems to dereference them into a series of semi-colon separated strings that well, don’t get recognized as reference values in the target attribute. (This is on a straight one to one copy without any manipulations desired – see Manual Precedence wish to find out why I ended up having to have a workflow activity built to perform this task).
4. Standardize how the displayed names for attributes are collected. In the RCDC, the displayname that has been specified in the binding is used. In the summary page, this may be the displayname of the attribute type rather than the displayname in the binding, etc. A statement cannot be made that the settings in the binding will always override those at the attribute level in these cases.
5. Provide a good mechanism to build out custom display pages for the portal. Its great that there is some secret squirrel code in the back of the group objects that differentiate between security and distribution lists. If I want to do that somewhere else for contractor or employee objects, it just isn’t possible. If I want to hide the new/delete button I can use the search results page template but then I get “Search Results” as a title instead of the display name of the Resource Type.
6. Better application of Hotfixes to the FIM Service. I’m not sure why this happens and maybe it is just something I’m doing wrong however, when I go to apply hotfixes to multi-service environments, the first upgrade goes very well and the database gets updated. The next hotfix though doesn’t because it says the database is at the incorrect version and fails. Given the database has already been updated for the hotfix by the previous installation, please validate if the database is at the correct revision for the hotfix itself and if it is, please allow the update to continue. This will save a lot of time with keeping blank upgrade databases that I point the services to using a “change” installation of the original MSI, applying the hotfix and then doing another “change” installation to point it back to the original shared database.
Now some of these items may already be in the R2 release of the product. I haven’t had a chance to play with it in depth and perhaps Santa has come early (please comment if you know of some of these being captured in R2 as I really would love to know).