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

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!

The only place the EREs can be seen is the FIMMA CS or the aforementioned database tables

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

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

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

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?)

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

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, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Agree. And if obsoletion doesn't help then you can consider deleting the CS... After that it's a call to Premier I think...

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?

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.

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 Identity & Metadirectory, Hewlett-Packard UK

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, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

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!)

Thanks Paul

Thanks Markus

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? CheersIdentity & Metadirectory, Hewlett-Packard UK

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

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. CheersIdentity & Metadirectory, Hewlett-Packard UK

Cheers Tom, Can you call me at work please, can't get hold of you! Rob