FIM 2010 R2–Diving into Filtered Outbound Synchronization Rules

So, I’m a bit behind the curve right now. I have been on a long engagement and we’re only starting to move towards the R2 version of FIM right now. I have to admit there are quite a few new things I like in the release but most of all, the filtered outbound synchronization rules are probably my favorite right now.

The filtered outbound synchronization rules are a huge improvement over the existing method for outbound synchronization rules but there are some trade offs. Key things of note are:

  • Filtered Outbound Synchronization rules still have the option to codelessly provision an object into the connected directory. There is however, no option to deprovision the object once it is no longer being applied to the object.
  • The criteria used in the FIM Service can still be used for the Outbound Synchronization rules in many cases so long as the Metaverse contains the information. This may result in more import rules from the FIM MA but in the long run, I really think it is worth it.
  • To deprovision objects that were provisioned using the filtered outbound synchronization rules, the metaverse extension provisioning code will have to be used to call the deprovision()
  • The outbound synchronization rules are limited to comparison of values and therefore, if there are comparisons between attributes or wanting to look back into the connector space of the object, these rules will not apply. Classic rules using a rules extension may still be the best choice.

In my implementations, this will save a lot of workflow churn in the FIM Service. I no longer have to add and remove the synchronization rules based on transitions into a set. This is especially important because I can now use the filtered outbound synchronization rules to switch out reference values where I couldn’t before (e.g. A disabled group no longer flows a populated reference attribute but a blank one). This took two synchronization rules, two sets, two workflows and two MPRs to implement before and that isn’t even including the ERE churn that has to pass through the FIM MA for it to operate.

Looking at it from a straight numbers perspective when looking at the total metaverse object count, this is huge. For simple implementations where the simple criteria can be met in the metaverse, it is now possible to remove the ERE’s. In an environment where there are 100,000 groups being synchronized and provisioned to active directory this is 100,000 ERE objects I no longer have to have in my environment. SWEET!

Advertisements
This entry was posted in Forefront Identity Manager 2010. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s