Hi, We are still confused as to why we can do attribute flows in the MA and the Sync Rule? When does one use which one? IMHO, compared to the other vendor's IDM solutions, FIM is most certainly the most complex we have come across... Thanks.

Backwards compability against the older versions like ILM and MIIS is the propably the reason why you can do it in both the MA and in Sync rules. Doing it in the MA config also allows you to use MA Extensions that allows you to do more advanced validations and manipulation of your data written in code. You can also use both at the same time in a hybrid solution but if you configure both at the same time for the same attribute the old MA config will win. Read more about it here: http://blogs.technet.com/b/doittoit/archive/2008/11/18/hybrids-not-just-for-you-prius-fans.aspx Does most complex also mean most dynamic in your opinion? //HenrikHenrik Nilsson, ILM/FIM MVP Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

thanks - and by 'most complex' I mean that I have worked with MS products for about 17 years...many MS infrastructure back-end products...and this one for some reason is eluding me...the logic behind FIM just doesn't compute...must be getting old or something ;-)

I have to admit, I agree. I have generally been settling with a "Hybrid" solution. I've been using the declarative rules to allow customers to readily see the "provisioning" of the new objects and simple attribute flows (and some more complex ones which can be readily handled within the declarative environment). I have remained using classic rules and rules extensions for the flows which require more indepth processing than is readily available within the declarative rules (including validation of connectors that are present, whether or not MV values are null or some other value, doing metaverse lookups, etc). Granted, some of the features I'm still using classic for can be completed by creating and deploying custom workflows but frankly, I've found it easier to simply maintain the rules extension project. As a side note, I have found that if I need to manage auxilliary object classes, I can still provision the basic connector using the declarative rule and then manage the auxilliary object classes within the provisioning code itself in the "connectors = 1" section of the code for the appropriate MA. Thanks B

What I mostly do is configure all flows from within the portal, exectp for the FIM MA (impossible) and the rules extensions. This way the MA are very basic. Hybrid is nice, but mixing too much makes it complex. And secondly you can benefit from being able to have multiple ISR's but with different filters on them. If you want some temporary trickery :) So I only see advantages with having both ways available.http://setspn.blogspot.com

Just be aware of the fact that declarative provisioning is much more than just the "codeless" implementation of what we had in the past. Key for declarative provisioning is the policy driven approach to managing your data. By using non-declarative provisioning (aka "the old way"), you are losing this feature. If there is a need for a data transformation, you can do this in a custom workflow as well. Whether you are developing a rules extension or a custom workflow - coding is coding :o) By writing a custom workflow, you can still take advantage of the policy driven approach... Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Absolutely true, and the only reason that I haven't used any custom workflows yet is because I simply don't get the right stuff together. It's like a hill I don't get over. Should look into it with the stuff Carol posted recently, perhaps this time I get past the .net workflow stuff.http://setspn.blogspot.com