none
Issue w/ ambiguous-import-flow-from-multiple-connectors RRS feed

  • Question

  • My current issue is not so much with why am I getting an ambiguous-import-flow-from-multiple-connectors error message, but why I am not.

    I am using the Active Directory Domain Services MA for FIM 2010 R2 (Version 4.1.3441.0).

    I have a join rule using the employeeID metaverse attribute--String (Indexable); Multi-valued: No; Indexed: Yes.

    In one ADDS MA used to manage regular users, I am using the AD employeeID attribute to join to the employeeID metaverse attribute. I will get the following error if an AD object is already connected to the metaverse object, which is what I expect:

    "Import flow was rejected because the destination metaverse object had multiple connectors from the source management agent."

    In another ADDS MA used to manage administrative accounts, I am using the AD extensionAttribute1 attribute to join to the employeeID metaverse attribute. With this MA I am able to connect multiple connector space objects from this admin MA to a single metaverse object, which is what I don't want.

    Note that these ADDS MAs are connected to the same metaverse object. There should be not more than one regular user ADDS (ADDS MA 1) CS object and one admin ADDS (ADDS MA 2) CS object connected to a single person metaverse object.

    Has anyone else encountered this issue? For importantly, has anyone resolved this?

    Monday, September 16, 2013 10:40 PM

Answers

  • Hi-

    The key is that you need a direct import flow rule that applies for both objects. Do you have this in MA #2?


    Thanks, Brian

    • Marked as answer by Toshi Teruya Tuesday, September 17, 2013 11:03 PM
    Tuesday, September 17, 2013 9:37 PM
    Moderator

All replies

  • The issue is only if you have multiple connectors within the same MA (and direct flow import rules for those connectors). When you have connectors across multiple objects, that is where precedence comes in so there's no error here.

    Given your requirements you could do this validation in your provisioning code (throw an exception if you have connectors to multiple AD MAs). You could also use the ResolveJoinSearch method to see if the matching mventry has existing AD connectors and throw an exception here. This would prevent the join from ever occurring.


    Thanks, Brian


    Tuesday, September 17, 2013 1:06 AM
    Moderator
  • Hi,

    As per my understanding You can do following things :

    1. Use rule extension for ADDS MA2 for User provisioning.
    2. In this Rule Extension check if User's connector is already present for ADDS MA1 and mventry also.
    3. If both are present you can set nothing or some erroror exception for object already present.
    4. If not not then commit new connector.

    I hope this will help you.

    Thanks~

    Giriraj Singh

    Tuesday, September 17, 2013 2:42 PM
  • Thanks Brian and Giriraj for your quick responses.

    Sorry if I did not clearly relay my problem so let me restate.

    Let us also assume that provisioning is turned off. I'm only concerned with direct join rules between a single-valued AD attribute and a string-indexable, single-valued, indexed metaverse attribute.

    I have one ADDS MA (ADDS MA 1) with a direct join rule for AD:employeeID <---> MV:employeeID. I have another ADDS MA (ADDS MA 2) with a direct join rule for AD:extensionAttribute1 <---> MV:employeeID.

    Now let's assume I have one user object from ADDS MA 1 connected to a MV person object (MV 1). I also have one user object from ADDS MA 2 connected to the same MV person object, MV 1.

    In the case of ADDS MA 1, if I have another user object with the same employeeID attribute value, during the ADDS MA 1 sync, I encounter the infamous "ambiguous-import-flow-from-multiple-connectors" error message. Yay! That is exactly what I want and expect.

    However, in the case of ADDS MA 2, if I have another user object with the same extensionAttribute1 attribute value, this second user object joins to the MV person object, MV 1, so now I have TWO user objects in the ADDS MA 2 CS connected to a single MV person object. This is NOT what I want. I want the aforementioned AIFFMC (for lack of better initialism) error.

    I know I can programmatically join multiple objects in the same CS to a single MV object via rules extensions, but this case involves a direct join rule.

    As Brian mentioned in his reply, I can write custom code to throw an exception to avoid this.

    My conundrum is this...

    Why does the ADDS MA 1 scenario work one way and the ADDS MA 2 scenario work differently?

    They both work with user objects in the same partitions. They both match against the same metaverse attribute on the same metaverse object, employeeID. The only difference is the AD attribute used for the direct join rule--employeeID vs. extensionAttribute1. I have two environments set up with their own AD domain, and I am able to replicate this inconsistency.

    Tuesday, September 17, 2013 9:30 PM
  • Hi-

    The key is that you need a direct import flow rule that applies for both objects. Do you have this in MA #2?


    Thanks, Brian

    • Marked as answer by Toshi Teruya Tuesday, September 17, 2013 11:03 PM
    Tuesday, September 17, 2013 9:37 PM
    Moderator
  • Ahhh...awesome catch!

    I did not have import attribute flows for ADDS MA 2, only export attribute flows. Since I was using it to manage administrative accounts, I only had an export attribute flow rule for userAccountControl.

    Knowing this and reconciling with the error message, it makes more sense.

    For some reason, I was thinking it was the Join and Projection step that threw the exception. Seeing your response and doing some testing shows me that that error is thrown in the Import Attribute Flow step and not the Join and Projection step.

    Interesting...although it is a bit unnerving that I can, sans rules extensions, join multiple CS objects to a single MV object just by removing any import attribute flow rules. And, only by close monitoring or by adding import attribute flow rules after syncing, will these errors start showing up.

    In any case, I learned something new and know what to look for in the future.

    Thanks again Brian!

    Tuesday, September 17, 2013 11:02 PM