none
Exported-Change-Not-Reimported on FIM MA Import RRS feed

  • Question

  • I am having an issue with the Exported-Change-Not-Reimported warning.  The warning is raised on text fields on user records (First Name, Last Name, Display Name) and appears to be caused by a difference in case between the data in the MV and the data in the FIM MA.  It looks like the warning is being raised when a field other than the one where case is difference is updated (eg email address).  

    For example, a record for John Smith exists in the FIM MA and the MV.  The last name in the FIM MA is 'SMITH' and in the MV it is 'Smith'.  John's email address is updated in an external data source and the change is imported into the MV.  The change is then exported from the MV to the FIM MA.  When a confirming Delta Import is run on the FIM MA the warning is raised that the exported value (eg 'Smith') is different from the imported value ('SMITH').  What I find weird is that as far as FIM is concerned the only value that it should have been concerned with was the email address.  So why is it complaining that the last name is different between the export and import?  

    A couple of additional questions

    1) Is there anything I can do to ensure that all values in the MV match those in the FIM Portal?

    2) Is it possible to force attributes to be exported to an MA even if their value has not been identified as updated?

    Friday, August 3, 2012 7:48 PM

Answers

  • If it's something you can edit via the FIM Portal's plain old fields, do so, then let the FIM Sync Service discover and "fix" the data.  Otherwise, poke at the data in its authoritative source (AD, HR, et al.).
    • Marked as answer by Woggi Friday, August 10, 2012 10:37 PM
    Wednesday, August 8, 2012 2:30 AM

All replies

  • Hi,

    Could you please verify your Attribute Precedence for the attributes in question?

    Cheers

    Monday, August 6, 2012 3:44 AM
  • Good question.  There is only one attribute flow set per attribute.   Maybe I have misdiagnosed the issue.  I have been trying to reproduce the behaviour in a test environment but have not been able to do so.

    My understanding is that the Exported-Change-Not-Reimported warning occurs when a attribute value different from the value that was exported is imported during the confirming delta import.  FIM identifies that there is a difference between the value it exported and the value it imported and raises the warning.  Is that correct and if it is is there a simple way to force this warning to occur using the FIM Portal?  I have been trying to reproduce the warning by exporting a value to the Portal and then changing that value in the Portal before re-importing this updated value in to the MV.  However, this does not cause the warning to be raised.

    Tuesday, August 7, 2012 4:39 PM
  • I've seen the same issue -- most likely due to a case-insensitive compare somewhere in the FIM ResourceManagement service.  One kludgy workaround is to change "a" -> "b" -> "A" (essentially the same thing you'd have to do to fix the casing on an LDAP DN which is stored case-sensitive but compared case-insensitive).
    Tuesday, August 7, 2012 4:44 PM
  • Hi Steve,

    Thanks for the response however I am not totally clear on the fix you are suggesting.   In the example you have given ("a" -> "b" -> "A") I am assuming "a" is the value in the MV but am not sure what "b" -> "A" represent.  

    To clarify the details of the FIM set up that I have:

    1) User details comes from an external SQL db into the MV via an inbound sync rules(declarative attribute flows)

    2) User data is exported to the FIM Portal (FIMMA) via non-declarative attribute flows

    3) No attribute flows are set up to import User data from the FIMMA into the MV

    Tuesday, August 7, 2012 5:24 PM
  • To clarify, the "exported-change-not-reimported" warnings occur because, for example, the FIM Sync Service tried to change FirstName "john" to "John", but the FIM Service silently ignored that change request because the values are the same in case-insensitive collation.  However, if you change "john" to "jack" and *then* to "John", the change will be stored in the correct case, and the FIM Sync Service will stop carping.
    Tuesday, August 7, 2012 6:06 PM
  • I've also seen this with data that has line breaks in it (e.g. a mailing address).

    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Tuesday, August 7, 2012 8:54 PM
    Moderator
  • Ok, that's a little clearer.  Dumb question, how exactly would I do that?  Would this be something I do on the external DB side or the FIM side?
    • Edited by Woggi Tuesday, August 7, 2012 11:01 PM
    Tuesday, August 7, 2012 11:00 PM
  • If it's something you can edit via the FIM Portal's plain old fields, do so, then let the FIM Sync Service discover and "fix" the data.  Otherwise, poke at the data in its authoritative source (AD, HR, et al.).
    • Marked as answer by Woggi Friday, August 10, 2012 10:37 PM
    Wednesday, August 8, 2012 2:30 AM
  • Ok, it sounds like the solution will be to manually update the case of attributes that are causing this issue.  The challenge then is going to be finding these records.  Our FIM implementation manages about 30,000 user records and only a fraction are affected by this.  Is there a way to search  the FIM Portal data for records that have attributes (FN, LN, display name) where more than the first letter is capitalized?
    Wednesday, August 8, 2012 9:38 PM
  • Just run a full import from the FIM MA, and the inconsistent entries will be noted.  If it's just a few, do 'em by hand... if a lot, look into batch options.  Certainly you could extract the data and use regular expressions to check capitalization, although there are plenty of names that contain more than one capital letter in proper case.
    Thursday, August 9, 2012 5:54 AM