none
MIIS: unexpected-error "The operation failed because the object cannot be found" RRS feed

  • Question

  • I have an MIIS server (version 3.2.559.0, Service Pack 2) which reads data from an AD Management Agent and exports it to an ADAM MA.

    When I run a synch operation on the AD MA, I get an "unexpected-error" for a group object. Checking the details, I see that the error is related to the "member" attribute, and the export step on the ADAM ma:


    Checking the event log, I see that the error is "The operation failed because the object cannot be found". I suppose that the object that cannot be found is one of the members of the group, yet I checked, and they are all present in the target Management Agent.

    How can I find the cause of this error?

    Thanks,
    Paolo

    P.S. here is the complete event log entry:

    The server encountered an unexpected error in the synchronization engine: "BAIL: MMS(3136): nscsimp.cpp(5897): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): nscsimp.cpp(6074): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): mvobj.cpp(3239): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): mvobj.cpp(3338): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): eafam.cpp(901): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): eafam.cpp(795): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): amexec.cpp(883): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): eaf.cpp(734): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): eaf.cpp(417): 0x80230405 (The operation failed because the object cannot be found) ERR: MMS(3136): synccoreimp.cpp(3472): 0x80230405 - export-flow failed 0x80230405 BAIL: MMS(3136): synccoreimp.cpp(3473): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): synccoreimp.cpp(3128): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): synccoreimp.cpp(6263): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): synccoreimp.cpp(1563): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): synccoreimp.cpp(2712): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): synccoreimp.cpp(5855): 0x80230405 (The operation failed because the object cannot be found) BAIL: MMS(3136): synccoreimp.cpp(2224): 0x80230405 (The operation failed because the object cannot be found) ERR: MMS(3136): synccoreimp.cpp(2240): 0x80230405 - CS to MV to CS synchronization failed 0x80230405: [CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch] BAIL: MMS(3136): synccoreimp.cpp(2076): 0x80230405 (The operation failed because the object cannot be found) ERR: MMS(3136): syncmonitor.cpp(2502): SE: Rollback SQL transaction for: 0x80230405 MMS(3136): SE: CS image begin MMS(3136): <cs-object cs-dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch" id="{C006A7C4-BCEC-4752-83E9-E4BDC9A068E6}" object-type="group"> <unapplied-export> <delta operation="none" dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch"> <anchor encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</anchor> </delta> </unapplied-export> <escrowed-export> <delta operation="none" dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch"> <anchor encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</anchor> </delta> </escrowed-export> <unconfirmed-export> <delta operation="none" dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch"> <anchor encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</anchor> </delta> </unconfirmed-export> <pending-import> <delta operation="none" dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch"> <anchor encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</anchor> </delta> </pending-import> <synchronized-hologram> <entry dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch"> <anchor encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</anchor> <parent-anchor encoding="base64">ruHSYghCO0mU9mIzyjCOXg==</parent-anchor> <primary-objectclass>group</primary-objectclass> <objectclass> <oc-value>top</oc-value> <oc-value>group</oc-value> </objectclass> <dn-attr name="member" multivalued="true"> <dn-value> <dn>CN=...</dn> <anchor encoding="base64">0MUruPhPA0uvOJ750g0cRA==</anchor> </dn-value>

    ... a lot more ... <dn-value> <dn>CN=...</dn> <anchor encoding="base64">44q2hrCgYEay3Ur1hudxTg==</anchor> </dn-value> </dn-attr> <dn-attr name="objectCategory" multivalued="false"> <dn-value> <dn>CN=Group,CN=Schema,CN=Configuration,DC=cern,DC=ch</dn> <anchor encoding="base64">/eOExunBI0q4vg1rERsTDg==</anchor> </dn-value> </dn-attr> <attr name="cn" type="string" multivalued="false"> <value>CMF_NSC_1198</value> </attr> <attr name="description" type="string" multivalued="true"> <value>f patching step 5 - NO JAva Update -startup</value> </attr> <attr name="instanceType" type="integer" multivalued="false"> <value>0x4</value> </attr> <attr name="name" type="string" multivalued="false"> <value>CMF_NSC_1198</value> </attr> <attr name="objectGUID" type="binary" multivalued="false"> <value encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</value> </attr> <attr name="objectSid" type="binary" multivalued="false"> <value encoding="base64">AQUAAAAAAAUVAAAA6lf4WhIL1VvERiZRJw4QAA==</value> </attr> <attr name="sAMAccountName" type="string" multivalued="false"> <value>CMF_NSC_1198</value> </attr> <attr name="sAMAccountType" type="integer" multivalued="false"> <value>0x10000000</value> </attr> <attr name="whenCreated" type="string" multivalued="false"> <value>20110428065913.0Z</value> </attr> </entry> </synchronized-hologram> <anchor encoding="base64">lPUG3WLB3k+IgvR3c4/VNg==</anchor> <connector>1</connector> <connector-state>normal</connector-state> <seen-by-import>1</seen-by-import> <rebuild-in-progress>0</rebuild-in-progress> <obsoletion>0</obsoletion> <need-full-sync>0</need-full-sync> <placeholder-parent>0</placeholder-parent> <placeholder-link>0</placeholder-link> <placeholder-delete>0</placeholder-delete> <pending>0</pending> <ref-retry>0</ref-retry> <rename-retry>0</rename-retry> <sequencers> <current> <batch-number>0</batch-number> <sequence-number>0</sequence-number> </current> <unapplied> <batch-number>0</batch-number> <sequence-number>0</sequence-number> </unapplied> <original> <batch-number>0</batch-number> <sequence-number>0</sequence-number> </original> </sequencers> <import-delta-operation>none</import-delta-operation> <export-delta-operation>none</export-delta-operation> <pending-ref-delete>0</pending-ref-delete> <ma-id>{56EEAD11-AC02-4D64-ADBB-F0D28C77009C}</ma-id> <ma-name>AD</ma-name> <partition-id>{4C05E255-1357-4C1A-9031-3EB2FF45A03B}</partition-id> <import-errordetail first-occurred="2012-06-13 06:20:52.970" date-occurred="2012-06-18 10:43:39.307" retry-count="2586" error-type="unexpected-error"> <import-status> <algorithm-step ma-id="{DA49FBE6-EF50-4B9B-9372-6B7B9276D556}" dn="CN=CMF_NSC_1198,OU=NSC,OU=CMF,DC=cern,DC=ch">export-flow</algorithm-step> <rules-error-info> <context> <attribute-mapping dest-attr="member" context-id="{75EEE621-2A44-45EA-85D4-96DC7C2AC878}"> <direct-mapping> <src-attribute>member</src-attribute> </direct-mapping> </attribute-mapping> </context> </rules-error-info> </import-status> </import-errordetail> <mv-link lineage-id="{09D3265A-8018-4DA8-898B-5D49D3B0E434}" lineage-type="projection-rules" lineage-time="2011-04-28 07:00:23.430">{0FD65EE2-8880-45A3-AEBF-E5949F07DD4A}</mv-link> <last-import-delta-time>2012-06-14 19:44:29.147</last-import-delta-time> </cs-object> MMS(3136): SE: CS image end Microsoft Identity Integration Server 3.2.0559.0" For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.



    Paolo Tedesco - http://cern.ch/idm



    Monday, June 18, 2012 11:46 AM

Answers

  • Could you remove all the failing members of the group to be sure that's the issue? If so, then you could add them back in small handfuls to narrow down the hunt.
    • Marked as answer by Paolo Tedesco Thursday, June 28, 2012 9:17 AM
    Tuesday, June 19, 2012 4:33 PM
  • Along with SamiVV's idea of removing members, you could also temporarily remove the member export rule from your ADAM MA and retry the synchronization (a preview full sync on the AD MA connector would be enough).  That would let you isolate whether the problem is on the AD side or the ADAM side.

    What does the member attribute for the group look like on the metaverse object?  If you look at that, it should show you the associated metaverse objects that are members, which should include clickable links to those objects...unless something significant changed between MIIS 2003 SP2 and ILM 2007 FP1.

    What kind of synchronizations are you running?  Delta or full?  A full sync on both MAs (ADAM and then AD) might redo the references existing between objects.

    Something else to try might be to delete the group from the metaverse (i.e. remove all the connectors, unless you have a simpler way with a non-default metaverse object deletion rule).  Then you could re-project from one MA or the other manually using the Joiner and preview another sync to see what happens.

    More drastic steps would include running full imports on one or both MAs, possibly deleting the connector space(s) first.  If a reference was somehow corrupted in the MIIS database this might fix it, though if you start to suspect database corruption that's really more of a delete-database-and-reinstall situation.  I once had some kind of hiccup during an AD MA export/import run, and it seemed like whenever a particular object was "touched" the whole system would just die.  After the next full import on that MA, I never had another problem like that.

    Chris

    • Marked as answer by Paolo Tedesco Thursday, June 28, 2012 9:17 AM
    Tuesday, June 19, 2012 5:51 PM

All replies

  • I don't have a magic bullet for you, but I would also verify that all the members of the group are in the source MA connector space, and are connected to metaverse objects (not filtered or failed to join/project).  Also, the member objects in the target MA also all need to be connected to those same metaverse objects for the references all to be mapped correctly.

    Chris

    Monday, June 18, 2012 7:18 PM
  • Hi Chris,

    Thank you very much for your help. I checked all the new members, and they all seem to be valid connectors in both connector spaces, and be connected to the same metaverse object.

    I tried to delete the object in the target system, and it was recreated exactly as before, i.e. with 6 members ok and 41 that fail to be added. Is there a way I could understand which object is giving the error, or should I assume it's all 41 of them?

    Thanks,
    Paolo


    Paolo Tedesco - http://cern.ch/idm

    Tuesday, June 19, 2012 9:47 AM
  • Could you remove all the failing members of the group to be sure that's the issue? If so, then you could add them back in small handfuls to narrow down the hunt.
    • Marked as answer by Paolo Tedesco Thursday, June 28, 2012 9:17 AM
    Tuesday, June 19, 2012 4:33 PM
  • Along with SamiVV's idea of removing members, you could also temporarily remove the member export rule from your ADAM MA and retry the synchronization (a preview full sync on the AD MA connector would be enough).  That would let you isolate whether the problem is on the AD side or the ADAM side.

    What does the member attribute for the group look like on the metaverse object?  If you look at that, it should show you the associated metaverse objects that are members, which should include clickable links to those objects...unless something significant changed between MIIS 2003 SP2 and ILM 2007 FP1.

    What kind of synchronizations are you running?  Delta or full?  A full sync on both MAs (ADAM and then AD) might redo the references existing between objects.

    Something else to try might be to delete the group from the metaverse (i.e. remove all the connectors, unless you have a simpler way with a non-default metaverse object deletion rule).  Then you could re-project from one MA or the other manually using the Joiner and preview another sync to see what happens.

    More drastic steps would include running full imports on one or both MAs, possibly deleting the connector space(s) first.  If a reference was somehow corrupted in the MIIS database this might fix it, though if you start to suspect database corruption that's really more of a delete-database-and-reinstall situation.  I once had some kind of hiccup during an AD MA export/import run, and it seemed like whenever a particular object was "touched" the whole system would just die.  After the next full import on that MA, I never had another problem like that.

    Chris

    • Marked as answer by Paolo Tedesco Thursday, June 28, 2012 9:17 AM
    Tuesday, June 19, 2012 5:51 PM
  • Hi SamiVV and Chris,

    Thanks for your suggestions!

    I had already tried deleting the group from the MV and re-importing, but at that point the whole group fails being created in the metaverse.

    I created a new test group, adding the same members of the faulty one in chunks, and I discovered that there are 3 computer objects that cause this problem.

    The strange thing is that if I check the properties of these computers, they exist in the metaverse and they seem to be correctly connected in both connector spaces, so I really have no idea about what could be causing this problem.

    Paolo


    Paolo Tedesco - http://cern.ch/idm

    Thursday, June 21, 2012 3:16 PM
  • I couldn't really solve this problem, I'll try a CS cleanup + FI when possible.

    Thanks for your help.


    Paolo Tedesco - http://cern.ch/idm

    Thursday, June 28, 2012 9:17 AM
  • I couldn't really solve this problem, I'll try a CS cleanup + FI when possible.

    Paolo - did you end up solving this problem?  I have something very similar right now in my lab with 65 "orphaned" CS objects in my FIM Service MA throwing the same error when I click on the Metaverse Object Properties... button (The requested metaverse object does not exist.).

    Unlike your scenario these are not group member references - but Person objects which show up as Connectors which point to nowhere.  If I search for the CS object by GUID it shows up with Connector=True ... yet there seems to be a broken link to a non-existent MV object.  On the joiner page I can also find a corresponding number of "normal" disconnectors (I manually changed these from explicit disconnectors in the hope that this would help - but it didn't).

    My CS certainly seems corrupted but I was hoping I could work out a nicer way of recovering short of deleting the CS ... if you have any pearls of wisdom that would be grand :).


    Bob Bradley (FIMBob @ TheMIMTeam.com) ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    Friday, April 1, 2016 12:47 AM