FIM2010-Referential Confusion

I have to admit, every once in a while I come across something I used to do in the sync engine that isn’t possible anymore. I wrote about the issue I was having with reference attributes in a previous post when I was talking about how these changes defined a case for me to use declarative rules (https://identityminded.wordpress.com/2011/07/26/fim-2010-a-case-for-declarative-rule-use/)

The scenario that I was working on required that the attributes in a group’s membership be removed while the group was inactive while still preserving it in FIM and another connected data source.

Synchronization Engine Configuration Requirements:

1. A schema addition to the group object in the FIM Synchronization Engine which was simply an empty multi-valued reference attribute. I called it “blankMembership”.

FIM Service Configuration Requirements:

1. A criteria-based set of groups that were enabled.

2. A criteria-based set of groups that were disabled. (I prefer to use transition in MPRs which can take advantage of the “Run on policy update” setting in workflows so you need to have the object join a group for this to occur.)

3. An “Active Group” outbound synchronization rule that had my flows including the “member” to “member” flow from the metaverse into Active Directory.

4. An “Inactive Group” outbound synchronization rule that had my flows including the “blankMembership” to “member” flow from the metaverse into Active Directory.

5. A Transition in MPR that applied the active synchronization rule to a group object when it was enabled (whether by manual or automated processes) and removed the inactive sync rule (if it was present).

6. A Transition in MPR that applied the inactive synchronization rule to a group object when it was disabled and remove the active sync rule (if it was present).

Once these steps were completed, I was able to make modifications to the groups status (active or inactive) and do a delta-import from FIM and see the membership in Active Directory be added or removed as required.

Believe me, I had tried a variety of different variants of the solution (including a flow rule in the declarative sync rule that did the mapping based on the value of the “group active” flag) but to no avail as it gave me a similar error to the one the sync engine gave me in the posting I referred to above. I needed to have the actual physical change of the rules for the operation to work correctly.

Anyway, I figured I should close the loop on the discussion so that anyone who was playing around with this would have a bit more robust of a recipe for making it happen.

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