locked
FIM RTM Attribute Recall issues when using Inbound SR and Export error to FIM MA RRS feed

  • General discussion

  • Anyone else seeing this issue?

     

    So, confirmed this with our new customer, clean installation of RTM, no prior config or upgrades – disconnecting a csobject (AD) which has contributed data to the mvobject via an Inbound SR does not have its attributes recalled if there is a pending-export error on the FIM MA.  This seems to mimic the behavior of removing an attribute flow on an existing connector which doesn’t recall the value, but disconnecting the object has always recalled any  prior contributions from that MA.

     

    To repro:

    1.       Project an object from another source (HR), contribute to the portal

    2.       On your AD MA, add whenCreated to the attribute inclusion list

    3.       Create an inbound SR with some flow rules for AD, join on a common attribute and contribute whenCreated to employeeStartDate

    4.       Preview Commit the join from AD – SR should contribute the values to the MV

    5.       Export to the FIM MA – should fail with datetime-string-format-incorrect error

    6.       Open the metaverse object and disconnect the AD MA connector – AD information remains

     

    I tried disconnecting the object without first attempting the export and it recalls fine, so it must be something to do with encountering the error condition which is preventing the recall from happening on the disconnect.

    This has been filed on Connect under:

    https://connect.microsoft.com/site433/feedback/details/549072/rtm-attribute-recall-issues-when-using-inbound-sr-and-export-error-to-fim-ma

     


    Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
    Tuesday, April 6, 2010 5:49 PM

All replies

  • I'm not sure if I have this issue since i'm new and still figuring everything out, but mabe something familiar:

    I tried to have a clean start so deleted my HR source, Deleted users in FIM portal and deleted them in AD(so far i only had some provisioning working). My plan was to try and create sets based on employeeStartDate so I could try and provision and later deprovision based on employeeStartDate and employeeEndDate.

    I can't seem to get employeeStartDate to populate in the portal, keep getting datetime0string-format-incorrect. But this makes me having the same kind of error that you have in my fimma connector. However when I export my ADMA is populates allready deleted users back into my portal.

    Thursday, April 8, 2010 2:02 PM
  • It may be related, but to circumvent your problem, you will likely need to delete each of your connector spaces, including the FIM MA.  You are likely dealing with an Outbound SR that is trying to reprovision the deleted AD users because you processed the deletes from AD without breaking the connectors first.

    To solve your datetime problem, see this post in the FIM Experts Corner:

     http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/59e8668a-65c5-45e6-b85f-01994a2004cf


    Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
    Monday, April 12, 2010 3:07 AM
  • I'm having an issue which is more or less related:

    SQL MA, FIM MA
    Attribute1 contributed by both, SQL MA is first in precedence
    Attribute2 contributed only by SQL MA

    If I delete the entry in the SQL, the CS object is deleted, and the MV entry remains (object deletion rules configured that way). The default deprovisioning  setting on the SQL MA is to recall attributes, and I didn't changed that.

    I'm seeing the contributing MA be changed from SQL to FIM for attribute1 (which makes sense), but the attribute 2 is not recalled. I would expect it to disapear. But it remains in the MV. The MV object has no connection to the SQL MA (as the CS object is gone).

    Any thoughts? Or is this by design and am I misunderstanding the "Do not recall attributes contributed by objects from this management agent when disconnected."


    http://setspn.blogspot.com
    Thursday, July 1, 2010 9:52 AM
  • Attribute recall is followed by a repopulation sequence.

    CS1.X – MV.X – CS2.X

    Let’s assume, CS1 has the highest precedence for X and you have synchronized X to CS2.
    You have IAF flow mappings for X configured on CS1 and CS2.
    MV.X has a value of 1.

    When you disconnect CS1, X=1 is pulled (recalled) from the metaverse.
    The next step is a repopulation.

    CS2 has now the highest precedence and can populate X.
    Since CS got the value form CS1, CS2 populates X with 1…

    While it may look like the sync engine didn’t recall the attribute value – it only looks like that.
    You will see the difference when checking the Contributing MA for the attribute value in the metaverse.

    Sometimes, this is desired – sometimes, this is a result of IAF mappings that shouldn’t be there…

    Does this make sense?

     
    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Thursday, July 1, 2010 10:17 AM
  • Markus,

    Thanks a lot for your explanation and time. However you explained the scenario which I understood :) What I'm seeing, and don't understand is the following scenario:

    CS1.Y – MV.Y - CS2

    Let’s assume, CS1 is the only contributor for Y.
    You have IAF flow mappings for Y configured on CS1.
    MV.Y has a value of 1.

    When you disconnect CS1, Y=1 should be pulled (recalled) from the metaverse.

    But: in on my MV object I still see MV.Y=1 and the contributing MA still is CS1. I would expect this attribute to dissapear completely from the MV entry.


    http://setspn.blogspot.com
    Thursday, July 1, 2010 11:46 AM
  • Ahhhhh - OK...

    In this case, if you can repro it, your expectation is correct.
    That would be a bug - unless, you have disabled attribute recall...

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Thursday, July 1, 2010 2:36 PM
  • I will re-try my findinds and probably escalate towards MS then

    Regards,
    Thomas


    http://setspn.blogspot.com
    Thursday, July 1, 2010 8:32 PM
  • Perhaps a small bump or re-vival of this topic. Does anyone else came across strange stuff with attribute recall? I recently started looking into it again, and i'm still stuffering the attributes not being recalled. The contributing MA is a SQL MA (SQL 2008). On what step are the attributes supposed to be recalled? On the first synchronization run after the import which triggered the CS object deletion?

    Regards,
    Thomas


    http://setspn.blogspot.com
    Friday, August 6, 2010 2:10 PM
  • Yes, directly after the disconnect.

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Friday, August 6, 2010 5:36 PM
  • After logging a PSS case for the Attribute Recall issue we found out that this was directly linked to the FIM Precedence issue. I can confirm that my issue is fixed with FIM Build 4.0.3561.2

     This is the build referenced in FIM 2010 Self Service Password Reset now supports Enforcement of all domain password policies (http://support.microsoft.com/KB/2443871)


    http://setspn.blogspot.com
    Saturday, November 6, 2010 11:47 AM