locked
Orphaned EREs RRS feed

  • Question

  • Hello,

    Somehow i've ended up with 3 EREs in the FIMMA CS that don't have a Resource parent.  These generate an 'unexpected error' when the FIMMA runs Delta Import and Delta Sync.  They don't exist in the MV so i can't disconnect them from there.  Apart from tracking them down in the Database is there any other way of removing them from the system?

    If it has to be a database hack which is the correct table to remove them from, mms_cs_link? mms_connectorspace?

    KR

    Rob

    Friday, July 8, 2011 7:57 AM

Answers

  • Ok, so normally here we would configure a connector filter ISR that applies to the
    connector object so that it is disconnected & rely on the Object Deletion Rule to remove
    the MV object during the inbound phase of synchronization.

    If the MV object has no GUID, the Sync Engine wont know which CS object to disconnect it from!

    IMHO, if the above doesn't work, you are left with creating a new FIM Service MA.

    Cheers
    Tom Houston
    • Marked as answer by rob_wood Wednesday, July 13, 2011 3:16 PM
    • Edited by Thomas Houston Monday, November 28, 2011 10:05 AM
    Tuesday, July 12, 2011 1:06 PM

All replies

  • Do they still exist within the FIM portal? maybe you can track them there and delete it, then run a Full Import to cleanup your connector space (delta is also possible if deleted correctly)
    Need realtime FIM synchronization? check out the new http://www.traxionsolutions.com/imsequencer that supports FIM 2010 and Omada Identity Manager real time synchronization!
    Friday, July 8, 2011 8:19 AM
  • The only place the EREs can be seen is the FIMMA CS or the aforementioned database tables
    Friday, July 8, 2011 8:29 AM
  • There's a procedure (powershell script) on how to remove orphaned ERE's on the TechNet Wiki. However I'm currently unable to find it... Search for "A method to remove orphaned ExpectedRuleEntry objects from"

    And make sure to create a (temporary?) MPR to grant you permissions to delete ERE objects.


    http://setspn.blogspot.com
    Friday, July 8, 2011 11:21 AM
  • That'll only delete them from the FIM Service.  Rob says they're only in the MV.  To get rid of them find them in the MV using MV search and disconnect the connectors (there'll only be one connector per MV object).

     


    EDIT: Here's the script referred to by Thomas: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/3db4100d-16da-4002-9708-43949659a4f8
    Friday, July 8, 2011 12:16 PM
  • And here's the rub, I can't see them in the MV as when i try to a message box pops up with the error message 'GUID should contain 32 digits with 4 dashes' etc etc.  powershell scripts don't find the EREs so i'm guessing it maybe last resort and trash them in the database?

    Cheers

    Rob

    Friday, July 8, 2011 12:28 PM
  • The only place the EREs can be seen is the FIMMA CS or the aforementioned database tables

    No - these are ExpectedRuleEntry objects that should be visible in the FIM portal - navigate to All Resources from the home page, then select Expected Rule Entry.  If they are present and you wish to delete them, you need to create yourself a (temporary) MPR to give yourself the rights to do this. If the objects are not visible there, but are visible in the MV, then there has been a communication breakdown between the FIM Sync service and the FIM portal ... suggest you try restarting both the FIM portal and the FIM sync service and check the FIM and Application event logs for errors.
    Bob Bradley, www.unifysolutions.net (FIMBob?)
    Friday, July 8, 2011 3:44 PM
  • Bob,

    Trust me, the only place we can see these EREs is in the CS or the Database.  In the CS they report as connected=true but you can't then view them in the metaverse as the error message occurs as reported above.  They are not visible in the FIM portal and cannot be found by running a script.  FIM has thrown a wobbly and wer'e just investigating avenues to see if anyone else hasa had similar issues before deleting the objects from the database.

    Cheers

    Rob

    Monday, July 11, 2011 8:06 AM
  • Have to tried running a full import (only) yet?
    If they don't exist in FIM anymore, they should be deleted in the FIM CS by the obsoletion process.

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Monday, July 11, 2011 8:11 PM
  • Agree.  And if obsoletion doesn't help then you can consider deleting the CS...

    After that it's a call to Premier I think...

     

    Tuesday, July 12, 2011 8:05 AM
  • Guys, I wholeheartedly agree with all of your suggestions and have tried Full Import (Stage Only) and also deleting the CS. When deleting the CS it generated errors saying it couldn't delete the objects so had to skip to move on. Rebuilt the CS with another Full Import but the objects were still there! So, as mentioned before, in the FIMSynchronization database we can see the objects in the mms_connectorspace and mms_cs_link tables. Any reason why we can't delete them from the DB directly? Any other tables where they might occur?
    Tuesday, July 12, 2011 8:40 AM
  • On Tue, 12 Jul 2011 08:40:40 +0000, rob_wood wrote:

    So, as mentioned before, in the FIMSynchronization database we can see the objects in the mms_connectorspace and mms_cs_link tables. Any reason why we can't delete them from the DB directly? Any other tables where they might occur?

    First reason is that directly editing that database will put you into a
    completely unsupported state. Second reason is that there are some quite
    complex linkages between the various tables and records in that database.
    Deleting rows in that database directly is a very quick way to having to
    start all over again from scratch.


    Paul Adare
    MVP - Identity Lifecycle Manager
    http://www.identit.ca
    Structured Programming supports the law of the excluded muddle.

    Tuesday, July 12, 2011 9:01 AM
  • Rob,

    Can you create a new temporary FIM Service MA, & run FISO?
    Please post back if these orphaned ERE objects appear staged in this CS.

    Cheers


    Tom Houston

    Tuesday, July 12, 2011 9:19 AM
  • The Pauls :-) are right, if the supported methods don't help, you should contact CSS.
    Any other method can break your system, which is not a good idea...

    Cheers,
    Markus


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Tuesday, July 12, 2011 10:49 AM
  • Hi Tom, Created the new temp FIMMA and ran a FISO. No objects with the same ID exist and the object count is less (7!) than the other FIMMA CS. What next, i guess you can't have two running FIMMAs so would it be delete the other one before syncing and renaming the new one? Cheers Rob (hope you had a great honeymoon!)
    Tuesday, July 12, 2011 11:17 AM
  • Thanks Paul
    Tuesday, July 12, 2011 11:20 AM
  • Thanks Paul
    Tuesday, July 12, 2011 11:20 AM
  • Thanks Markus
    Tuesday, July 12, 2011 11:21 AM
  • Hi Tom, Created the new temp FIMMA and ran a FISO. No objects with the same ID exist and the object count is less (7!) than the other FIMMA CS. What next, i guess you can't have two running FIMMAs so would it be delete the other one before syncing and renaming the new one? Cheers Rob (hope you had a great honeymoon!)

    Ok, so we have verified that the ERE definately doesn't exist in the FIM Service.
    Returning to the original FIM Service MA, check the properties of one of these CS objects.

    Is the Object State reported as a Connector or Disconnector?

    Cheers
    Tom Houston
    Tuesday, July 12, 2011 11:48 AM
  • The object state is Connector, to the MV no doubt, but the object doesn't exist in the MV!  Of interest, in the CS Object properties i have 3 tabs, Import, Synchronization Error and Lineage.   The sync error reported is unexpected-error.  When you select the Lineage tab and click MV Object properties you get the error box reporting a malformed GUID (Its missing!).  On the Import tab the only attribute change is delete: Resource Parent (which was the last thing i did in the Portal, i.e. delete the orphaned ERE).  All other attributes are normal.

    Cheers

    Tuesday, July 12, 2011 12:47 PM
  • Ok, so normally here we would configure a connector filter ISR that applies to the
    connector object so that it is disconnected & rely on the Object Deletion Rule to remove
    the MV object during the inbound phase of synchronization.

    If the MV object has no GUID, the Sync Engine wont know which CS object to disconnect it from!

    IMHO, if the above doesn't work, you are left with creating a new FIM Service MA.

    Cheers
    Tom Houston
    • Marked as answer by rob_wood Wednesday, July 13, 2011 3:16 PM
    • Edited by Thomas Houston Monday, November 28, 2011 10:05 AM
    Tuesday, July 12, 2011 1:06 PM
  • Cheers Tom, Can you call me at work please, can't get hold of you!

    Rob

    Tuesday, July 12, 2011 1:10 PM