MA vs Sync Rule
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.
October 5th, 2010 2:13pm

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: Does most complex also mean most dynamic in your opinion? //HenrikHenrik Nilsson, ILM/FIM MVP Blog: Company: Cortego (
Free Windows Admin Tool Kit Click here and download it now
October 5th, 2010 4:46pm

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 ;-)
October 6th, 2010 3:09pm

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
Free Windows Admin Tool Kit Click here and download it now
October 7th, 2010 12:38am

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.
October 7th, 2010 10:54pm

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
Free Windows Admin Tool Kit Click here and download it now
October 7th, 2010 11:03pm

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.
October 7th, 2010 11:14pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics