none
Odd recall behaviour post-IAF deletion on FIM MA

    Question

  • Got an interesting situation that I haven't seen before.

    Have inherited a system where there's an IAF from FIM MA -> MV on Email. In the MV, Email has several contributing MA's with the FIM MA providing a value where none of the 3 authoritive systems (1 per user class) provide one.

    Have realised that the value the FIM MA is providing really isn't relevant and so deleted the flow from Email on that MA.

    Then I commit a preview on the FIM MA CS object, but notice that the email attribute is still set in the MV object, with the FIM MA as the contributing MA.

    "Don't recall attribute when disconnected" is turned on, so I switch that off just in case and do another commit preview. Same result - email still in MV with FIM MA contributing.

    Does anyone else think this is odd behaviour? In times past when I've done similar operations, I believe the contributed attribute has been cleared in the MV when a full sync is performed after the flow rule is cleared. Then again, in those times I may have cleared the connector space before doing a FIFS again to ensure it's all properly sync'ed - these days, I try to avoid clearing the FIM CS where I can


    MCTS: Forefront Identity Manager 2010, Configuring

    Wednesday, February 22, 2012 5:01 AM

Answers

  • On Wed, 22 Feb 2012 05:01:12 +0000, Ross Currie wrote:

    Have inherited a system where there's an IAF from FIM MA -> MV on Email. In the MV, Email has several contributing MA's with the FIM MA providing a value where none of the 3 authoritive systems (1 per user class) provide one.

    Have realised that the value the FIM MA is providing really isn't relevant and so deleted the flow from Email on that MA.

    Then I commit a preview on the FIM MA CS object, but notice that the email attribute is still set in the MV object, with the FIM MA as the contributing MA.

    "Don't recall attribute when disconnected" is turned on, so I switch that off just in case and do another commit preview. Same result - email still in MV with FIM MA contributing.

    This isn't going to accomplish anything as all you've done is to remove the
    IAF, you have not actually disconnected the CS object from the MV object.


    Does anyone else think this is odd behaviour? In times past when I've done similar operations, I believe the contributed attribute has been cleared in the MV when a full sync is performed after the flow rule is cleared. Then again, in those times I may have cleared the connector space before doing a FIFS again to ensure it's all properly sync'ed - these days, I try to avoid clearing the FIM CS where I can

    Deleting the CS obviously disconnects the CS object from the MV object as
    the CS object no longer exists.

    What you're seeing with regards to the email attribute is expected and is
    working as designed. Simply removing an IAF rule is not going to cause any
    contributed values to be removed.


    Paul Adare
    MVP - Forefront Identity Manager
    http://www.identit.ca
    The value of a program is proportional to the weight of its output.

    • Marked as answer by Ross Currie Wednesday, February 22, 2012 6:08 AM
    Wednesday, February 22, 2012 5:20 AM

All replies

  • On Wed, 22 Feb 2012 05:01:12 +0000, Ross Currie wrote:

    Have inherited a system where there's an IAF from FIM MA -> MV on Email. In the MV, Email has several contributing MA's with the FIM MA providing a value where none of the 3 authoritive systems (1 per user class) provide one.

    Have realised that the value the FIM MA is providing really isn't relevant and so deleted the flow from Email on that MA.

    Then I commit a preview on the FIM MA CS object, but notice that the email attribute is still set in the MV object, with the FIM MA as the contributing MA.

    "Don't recall attribute when disconnected" is turned on, so I switch that off just in case and do another commit preview. Same result - email still in MV with FIM MA contributing.

    This isn't going to accomplish anything as all you've done is to remove the
    IAF, you have not actually disconnected the CS object from the MV object.


    Does anyone else think this is odd behaviour? In times past when I've done similar operations, I believe the contributed attribute has been cleared in the MV when a full sync is performed after the flow rule is cleared. Then again, in those times I may have cleared the connector space before doing a FIFS again to ensure it's all properly sync'ed - these days, I try to avoid clearing the FIM CS where I can

    Deleting the CS obviously disconnects the CS object from the MV object as
    the CS object no longer exists.

    What you're seeing with regards to the email attribute is expected and is
    working as designed. Simply removing an IAF rule is not going to cause any
    contributed values to be removed.


    Paul Adare
    MVP - Forefront Identity Manager
    http://www.identit.ca
    The value of a program is proportional to the weight of its output.

    • Marked as answer by Ross Currie Wednesday, February 22, 2012 6:08 AM
    Wednesday, February 22, 2012 5:20 AM
  • this is normal behaviour since the the option was "Don't recall attribute when disconnected" was selected, FIM will not delete the contributing value by FIMMA from the metaverse object and the other inbound attribute flow from other MAs will not be re-calculated.

    and for "email" attribute FIMMA is not precedent and will not contribute it's value, so you need to run a full sync on the management agent which have the precedence for email attribute.

    always remeber to force an inbound synchronization to MV you need to run that on the specific management agent configured with that inbound attribute flow, other management agents will not have inbound synchronization until you run the synchronization profile on them.


    burn baby burn ... Idm Inferno


    Wednesday, February 22, 2012 5:24 AM
  • This isn't going to accomplish anything as all you've done is to remove the IAF, you have not actually disconnected the CS object from the MV object.

    Ah okay, for some reason I always thought deleting the rule would result in the value being recalled on a subsequent sync run.

    Deleting the CS obviously disconnects the CS object from the MV object as the CS object no longer exists.

    Yeah, I guess that's what I was getting at - whether there was any way to get rid of the attribute without disconnecting the CS object. Seems the answer is no.

    Cheers mate


    MCTS: Forefront Identity Manager 2010, Configuring

    Wednesday, February 22, 2012 6:18 AM