Invalid-DN During Export on a SQL MA RRS feed

  • General discussion

  • Hit a confusing error recently on a SQL MA.  This SQL MA has no reference attributes, and the anchor is simply a GUID (good enough for the FIM MA, right?).

    On Export there are a few objects with an Export Error of "invalid-dn".  This is confusing because this MA has no DNs.  The problem here is that the MA has pending exports for objects that don't exist in the target SQL table. 

    In my case these objects are waiting to be cleaned up by a Full Import, so I expect these to just go away naturally without any of my invasive meddling.

    Weird error, I would have preferred something more like "Object not found".  Hopefully the next person that gets this error finds this post ;-)

    CraigMartin – Edgile, Inc. –

    Wednesday, June 27, 2012 3:51 PM

All replies

  • Craig, I'm curious as to why you have pending exports for objects that don't exist and a full import will clean them up.  Are they not pending adds?  Does your SQL MA not have a way of importing deletes on a delta import?  I had that problem for awhile with one of my simpler SQL MAs. 

    I suspect in this case the "invalid-dn" error is really referring to your anchor value.  In many ways the anchor and DN are synonymous.


    Wednesday, June 27, 2012 8:10 PM
  • Hey Chris, it was an issue with the triggers creating our delta table entries that tricked the sync engine into having a CSEntry for an object that had no corresponding row in the SQL table.  So the row existed in the delta table, but not the full table.  A full import makes the issue go away, but doesn't solve the actual problem.

    In this case, the error ('invalid-dn') might be referring to the anchor, but my point is that the error doesn't reflect the actual problem (missing object in the SQL table).  I suspect on export the MA is looking for the target row (by the CSEntry DN) but doesn't find it.  When it fails to find the row in SQL it tells me 'invalid-dn' where I would have preferred to get detail such as "failed to find the object in SQL using query: select * from foo where hoof = 'hearted'", or simply "Object not found".

    Nitpicking?  Maybe.  The intent of the post is to make this easier for the next person that hits this error and wonders why the SQL MA thinks a DN is invalid ;-)

    CraigMartin – Edgile, Inc. –

    Wednesday, June 27, 2012 11:09 PM
  • I have noticed the same thing. Thankfully, a quick search turned up this post. 'Invalid-dn' is indeed a misleading error message for this situation. 'Invalid-anchor' would make much more sense to me in this scenario.

    For anyone else who hits this, the reason I came up with this is because I am using a view on my SQL MA to only show the last month's data. Before my update to the SQL Table could process, the entry it was trying to update dropped out of the 1 month period. This caused the entry to not exist in the view, which generated the 'invalid-dn' error.

    Thanks for taking the time to post this, Craig. It helped me find the cause of my error and eliminate some head scratching much more quickly than I would have without it.

    Monday, July 16, 2012 1:48 PM
  • Glad you found it!  Could you please vote the post as helpful?  It'll make people think I'm pretty ;-)

    CraigMartin – Edgile, Inc. –

    Monday, July 16, 2012 3:24 PM
  • I just had this problem, with an interesting underlying root cause that's worth mentioning.  I had just copied in the SQL database from a different environment, and wanted to run a full import/full sync/export cycle to update the connector space to match it.  I had discovery errors during import (for reasons unrelated to this problem) and they blocked object obsoletion from running, so old objects that were not present in the database were being retained in the connector space even after a full import full sync.  This lead to MIM generating Update exports for those objects, that should really have been Adds instead.

    TL;DR - If you have any discovery errors (even on unrelated objects) and you're seeing this error, fix the discovery errors.
    Friday, November 29, 2019 2:01 AM