Every once in a while, I go digging about the various sites to see what I haven’t read before in regards to the FIM documentation. I kept missing this one however, a client recently pointed it out to me and I think this should be carefully reviewed by everyone who uses FIM to ensure that features that you are actively using are not removed.
The technet article is at this URL –> http://technet.microsoft.com/en-us/library/jj879229(v=ws.10).aspx
Key things that concern me are:
- Run Profile Changes – This bullet indicates a phasing out of the “combined” run profiles that are very important, at least when it comes to the functionality of the ones including the delta synchronization components. I have many clients who actively use the “Delta Import and Delta Synchronization” profile to prevent unnecessary processing of filtered disconnectors to allow more frequent synchronization. As this profile will process any “changed” objects including filtered disconnectors, they are evaluated when the data from the connected data source changes by default. Running a delta import and delta synchronization and two discrete steps means that the delta synchronization step will test all the filtered disconnectors to ensure they should still be in that state. In one client where there are 1,000’s of these items, even processing at 50 filtered objects per second adds 20 seconds per 1000 objects to the sync time. Scale that to 100,000 and suddenly its added 2,000 seconds (over 33 minutes) to the process!
- Attribute Precedence – This feature is removing equal precedence. Admittedly, I’m not a big fan of this function anyway, however, it still doesn’t address precedence issues with the FIM MA, as we can’t do manual precedence anyway. I would love to see this functionality modified so that the FIM MA allows for rules extensions and therefore, manual precedence. This would simplify many things I have to do for some clients without having to do some sort of weird work-around. (That said, I want to be able to do basic functions with reference attributes in classic code as well as in decision based flows in declarative rules – see “A Case for Declarative Rules Use” post which describes my issues with reference attributes)
- Attribute Flows – Allow Nulls – There are changes proposed for the “Allow Nulls” feature which would have this permanently enabled. I just think this is bad karma. I use this quite a bit to “protect” attributes from a future misconfiguration that may lead to the “necessary attribute” being deleted and/or an export error to be thrown. Sometimes protecting people from themselves is necessary and this is an important tool in that arsenal.
- Attribute Flows – Do Not Recall Attributes – This one goes hand in hand with the allow nulls. In many cases, when an object is disconnected and is the primary source for data, a recall of the attributes will cause the nulls that would otherwise be exported to other connected directories. There are best practices where these attributes should be replaced with a lower precedence source but given that it has to be selected by the user whether to recall or not, I would suggest it be left in. An enhancement to this would be to allow the “remaining” attributes to no longer be enforced within the precedence model and if a new “lower” source with a connector to the metaverse is updated with a new value, the system should accept the new value instead of following precedence rules against the “missing” contributing connector.
- Transaction Properties – YIKES! This was an important method for communicating information between different DLLs for a transaction. This would remove an important component for sending communication signals between the rules extensions and mvextension DLLs so that different tasks can be completed based on the outcome of tests performed during other parts of the objects synchronization processing.
I’ve also noted that they are removing the CLM MA. I find this interesting and wonder how the certification provisioning requests are to be managed within this system. Is there a new method that Microsoft is proposing for this tool or are they planning to decouple it as a separate product outside the realm of the FIM framework?
Anyway, take a look at the posting and see if you have similar or different concerns. I think it is important that we provide appropriate feedback to the product team so that we don’t end up with having to establish workarounds for common items that we may have been using fairly frequently and would like to continue to use.