For the past 4 weeks I’ve found myself taking a trip down memory lane with rules extensions … in VB.Net and not my preferred C# no less. Ironically this was my first FIM R2 experience, and I was hardly prepared to discover that everything old is new again :). What this has allowed me to do is re-balance the scales a little (well a lot actually) in the argument of declarative vs. non-declarative. While there have been several learnings for me in this time, and plenty of them about the R2 Lotus Notes MA, the observation I want to share is concerning IAF and inbound precedence.

When I first rolled up my sleeves to begin implementing one of the more complex sync designs I’ve seen, I was determined to stick to the KISS (Keep It Simple Stupid!) principle. I decided the best strategy to approach what is effectively a 5-way GAL sync was to focus exclusively on the inbound flows first, and only look at outbound once we were 100% confident the inbound was right. This turned out to be a sound strategy, given the number of times I changed my mind on how I would actually do it.

I started out surfacing as many IAFs as possible in the form of sync rules, but soon ran into several challenges, including the following:

• one authoritative source was Lotus Notes, and with nearly all properties being multi-valued, with many mapping to single metaverse properties, I soon dispensed with plans to do any kind of declarative flow with this MA;
• I needed to use multiple join rules to map data to Notes and AD (including advanced joins on the multi-valued InternetAddress, ShortName, ListName and FullName properties of the Notes MA CS), and quickly realised that pursuing multiple declarative rules here with variations in relationship was going to be at best still very clumsy … this was a no-brainer, so I decided if I used rules extensions for join rules that I could still combine these with portal-defined IAFs on a simple relationship such as objectSID.

I could go on with a few more … but if the above weren’t enough of an argument to give up on declarative IAFs altogether, the final nail in the declarative coffin for me was what happened when I was forced to delete and recreate an MA in my solution several times. I had to do this for two MAs for various reasons, and each time I did this it meant that I had to delete and recreate my declarative sync rules for the new MA instance guid. This meant the following:

1. an awful lot of rework in re-creating sync rules;
2. long sync times to reapply these new rules to my sync config; and (and here was my clincher)
3. redefining all my attribute precedence rules for 4 different metaverse object classes across more than half a dozen MAs

After I found myself doing #3 above for the third time, I decided enough was enough, and deleted all of my IAFs in favour of the traditional direct/rules extension option. I did this with great reluctance mainly because so much expectation exists in the maintenance value proposition of declarative sync rules over the alternative, and believe me I didn’t take this decision lightly. Every issue discovery resulted in one compromise after another, eventually resulting in a mix of the two styles where the portal sync rules ended up being shadows of the original design. Resorting to 100% non-declarative in this case appeared my only option, and I certainly had already run out of whatever “discovery” time I had allowed myself, and needed to get some “runs on the board”.

Now back onto my point about precedence … when building a FIM Sync solution I really don’t want to have to go back to the metaverse designer and reset precedence on every object and attribute in the case where I need to delete and recreate an MA. Why does avoiding declarative inbound rules help here? Here’s my argument:

• with no declarative rules, I can export my MA definition, export the full server configuration, delete and recreate my MA (new instance from exported MA), and then reimport the server export to reset precedence … this seems to work in resetting the attribute precedence back to what it was before the MA deletion; but
• with declarative rules, when I try the above method, of course after the additional (tedious) steps to recreate all your sync rules in the portal, I find that the precedence doesn’t get reset to what it was (I’ve seen this happen during config migration too many times … maybe this is just a bug, but I think it may actually be a FIM design limitation)

I am still expecting to be able to implement all but probably the Notes MA using outbound flows as declarative OAFs, but as it stands we have an IAF-free zone now. When I look at why this is the case, I am convinced that the success of a declarative sync rule model is entirely dependent on the integrity of your most problematic management agent/connected system – in this case it is Notes and will always be Notes (mainly because the Notes schema seems to be of only mild passing interest to the Notes Client, which allows users to enter multi-values in single value attributes and no end of other schema violations), topped off by the fact that the Notes DN is derived from the multi-valued FullName and ListName properties of the user and group objects respectively, the integrity of which is at the mercy of the ADMIN_P process which tries to play traffic cop with wayward directory entries.

So looking back over the last couple of years’ experience in implementing portal-based sync policy, I am convinced that the reason I’ve been able to barely write a line of rules extension logic is because invariably I was syncing “apples with apples” … i.e. AD to AD, or Identity Broker to AD, or even Notes to Notes. To expect that you can never lift a hand to code sync rules any more just because we’ve entered the FIM R2 age is to be very mistaken indeed.