The image or delta doesn't have an anchor
I would appreciate an explanation of the synchronization error "The image or delta doesn't have an anchor". I'm running FIM 2010 RC1 with Update 3 applied. The object causing the error appears to have an anchor. And the relevant MA has that same anchor defined. There are two MA's that deal with the problem object. One is a SQL MA that imports the object. The other is an Extensible Connector that exports the object. It appears that the exporting MA is causing the problem. The Importing SQL MA has the following run profiles... a) Full Import (Stage Only) b) Full Import and Delta Synchronization c) Full Synchronization ...during run profile 'b', I receive a synchronization error. I can view the items in the Importing MA's connector space. But the anchor error (pasted below) is logged to the event viewer whenever I run the "Full Import and Delta Synchronization", or when I try to view the item by selecting "Search Connector Space" from the exporting MA. Any information on this would be very much appreciated. The server encountered an unexpected error in the synchronization engine: "BAIL: MMS(4492): tower.cpp(266): 0x80230302 (The image or delta doesn't have an anchor.) Loading CS object with DN='51807f1d-2302-4258-ab3c-950d5e51e277', modt='MODT_ATTRIB_UPDATE' (0x3) *Hologram: <entry dn="51807f1d-2302-4258-ab3c-950d5e51e277"> <primary-objectclass>TestUser</primary-objectclass> <objectclass> <oc-value>TestUser</oc-value> </objectclass> <attr name="email" type="string" multivalued="false"> <value>t@t.com</value> </attr> <attr name="firstName" type="string" multivalued="false"> <value>Bob</value> </attr> <attr name="lastName" type="string" multivalued="false"> <value>smith</value> </attr> <attr name="localId" type="string" multivalued="false"> <value>51807f1d-2302-4258-ab3c-950d5e51e277</value> </attr> <attr name="loginName" type="string" multivalued="false"> <value>bob.smith</value> </attr> <attr name="middleName" type="string" multivalued="false"> <value>test</value> </attr> <attr name="preferredName" type="string" multivalued="false"> <value>Bob</value> </attr> <attr name="refId" type="string" multivalued="false"> <value>{2A5E9013-4B3C-4790-A6B9-CC2ADC0CBF60}</value> </attr> <attr name="stateProvinceId" type="string" multivalued="false"> <value>31005001478</value> </attr> </entry> fFullSync = 0 is_connector = 1 connection_state = 0 is_rebuild_in_progress = 0 is_seen_by_import = 0 is_phantom_parent = 0 is_phantom_link = 0 is_phantom_delete = 0 is_pending = 0 is_reference_retry = 0 is_rename_retry = 0 <current> <batch-number>2</batch-number> <sequence-number>107</sequence-number> </current> <unapplied> <batch-number>2</batch-number> <sequence-number>107</sequence-number> </unapplied> <original> <batch-number>2</batch-number> <sequence-number>107</sequence-number> </original> BAIL: MMS(4492): tower.cpp(123): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): csobj.cpp(7040): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): csobj.cpp(1413): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): nscsimp.cpp(5017): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): mvobj.cpp(1875): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): synccoreimp.cpp(7849): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): synccoreimp.cpp(2426): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): synccoreimp.cpp(4336): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): synccoreimp.cpp(8517): 0x80230302 (The image or delta doesn't have an anchor.) BAIL: MMS(4492): synccoreimp.cpp(3805): 0x80230302 (The image or delta doesn't have an anchor.) ERR: MMS(4492): synccoreimp.cpp(3821): 0x80230302 - CS to MV to CS synchronization failed 0x80230302: [51807f1d-2302-4258-ab3c-950d5e51e277] BAIL: MMS(4492): synccoreimp.cpp(3628): 0x80230302 (The image or delta doesn't have an anchor.) ERR: MMS(4492): syncmonitor.cpp(2515): SE: Rollback SQL transaction for: 0x80230302 MMS(4492): SE: CS image begin MMS(4492): <cs-object cs-dn="51807f1d-2302-4258-ab3c-950d5e51e277" id="{C842C0C0-AE2C-4EBE-9C08-2212D48C8F77}" object-type="TestUser"> <unapplied-export> <delta operation="none" dn="51807f1d-2302-4258-ab3c-950d5e51e277"> <anchor encoding="base64">SAAAADUAMQA4ADAANwBmADEAZAAtADIAMwAwADIALQA0ADIANQA4AC0AYQBiADMAYwAtADkANQAwAGQANQBlADUAMQBlADIANwA3AA==</anchor> </delta> </unapplied-export> <escrowed-export> <delta operation="none" dn="51807f1d-2302-4258-ab3c-950d5e51e277"> <anchor encoding="base64">SAAAADUAMQA4ADAANwBmADEAZAAtADIAMwAwADIALQA0ADIANQA4AC0AYQBiADMAYwAtADkANQAwAGQANQBlADUAMQBlADIANwA3AA==</anchor> </delta> </escrowed-export> <unconfirmed-export> <delta operation="none" dn="51807f1d-2302-4258-ab3c-950d5e51e277"> <anchor encoding="base64">SAAAADUAMQA4ADAANwBmADEAZAAtADIAMwAwADIALQA0ADIANQA4AC0AYQBiADMAYwAtADkANQAwAGQANQBlADUAMQBlADIANwA3AA==</anchor> </delta> </unconfirmed-export> <pending-import> <delta operation="none" dn="51807f1d-2302-4258-ab3c-950d5e51e277"> <anchor encoding="base64">SAAAADUAMQA4ADAANwBmADEAZAAtADIAMwAwADIALQA0ADIANQA4AC0AYQBiADMAYwAtADkANQAwAGQANQBlADUAMQBlADIANwA3AA==</anchor> </delta> </pending-import> <synchronized-hologram> <entry dn="51807f1d-2302-4258-ab3c-950d5e51e277"> <anchor encoding="base64">SAAAADUAMQA4ADAANwBmADEAZAAtADIAMwAwADIALQA0ADIANQA4AC0AYQBiADMAYwAtADkANQAwAGQANQBlADUAMQBlADIANwA3AA==</anchor> <primary-objectclass>TestUser</primary-objectclass> <objectclass> <oc-value>TestUser</oc-value> </objectclass> <attr name="InternalID" type="string" multivalued="false"> <value>31005001478</value> </attr> <attr name="Email" type="string" multivalued="false"> <value>t@t.com</value> </attr> <attr name="GivenName" type="string" multivalued="false"> <value>Bob</value> </attr> <attr name="LocalId" type="string" multivalued="false"> <value>51807f1d-2302-4258-ab3c-950d5e51e277</value> </attr> <attr name="MiddleName" type="string" multivalued="false"> <value>test</value> </attr> <attr name="PreferredName" type="string" multivalued="false"> <value>Bob</value> </attr> <attr name="Surname" type="string" multivalued="false"> <value>smith</value> </attr> <attr name="Username" type="string" multivalued="false"> <value>bob.smith</value> </attr> </entry> </synchronized-hologram> <anchor encoding="base64">SAAAADUAMQA4ADAANwBmADEAZAAtADIAMwAwADIALQA0ADIANQA4AC0AYQBiADMAYwAtADkANQAwAGQANQBlADUAMQBlADIANwA3AA==</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>{0377083A-DB14-4146-8BC8-054CB504173E}</ma-id> <ma-name>Import_Users</ma-name> <partition-id>{0537471F-637C-4E80-940A-BA1CFA037B2A}</partition-id> <import-errordetail first-occurred="2010-02-10 00:02:37.070" date-occurred="2010-02-10 01:14:58.013" retry-count="4" error-type="unexpected-error"> <import-status> </import-status> </import-errordetail> <mv-link lineage-id="{B2F98319-827F-4EE7-A42B-B13E03392628}" lineage-type="projection-rules" lineage-time="2010-02-03 23:53:38.833">{2A5E9013-4B3C-4790-A6B9-CC2ADC0CBF60}</mv-link> <last-import-delta-time>2010-02-10 01:14:58.013</last-import-delta-time> </cs-object> MMS(4492): SE: CS image end Forefront Identity Manager 4.0.2587.0"
February 10th, 2010 4:42am

We have to be careful with the semantics.First, these bail errors represent in many cases PSS issues.If this is important to, you should better open a PSS case!It is possible, that you are dealing with bad memory or some other issue for which the error is not the cause but an instance...b) - is a bad case, because it combines two totally different operations.It would help to split them into separate operations to see if we are dealing with a staging or a sync issue.The anchor is the attribute used to link the CSD object to a CS object.You have two separate objects that are united by using a virtual link - the anchor value.This is a lose link - "if you have the same value as I have, then you are my partner".So, "The object causing the error appears to have an anchor" is as such technically incorrect :-) - because there are two objects involved...Accordind to your post, there is a value for the anchor in the hologram."The image or delta doesn't have an anchor" - the image is the inported information from the CS and the delta is the difference between image and the synchronization hologram. Since there is an anchor value in the image and in the hologram, I would guess that you are running into a non FIM related issue.I think, your best bet is to contact PSS with this.Cheers,Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
Free Windows Admin Tool Kit Click here and download it now
February 10th, 2010 5:46am

Thanks very much for the response Markus. I've split the run profile into separate steps and can confirm that the error is happening during the synchronization (either full or delta will trigger the error). Can we determine the area in which the sync failed from the XML elements listed in the error message under "CS image begin"?... <unapplied-export> <escrowed-export> <unconfirmed-export> <pending-import> Some further information...I have a Metaverse Rules Extension enabled. I can confirm that the MVExtensionObject() constructor inside the rules DLL is being triggered during the sync. Yet the IMVSynchronization.Provision method is not being called. Not sure whether this gives us any more info on the point of failure. Within the Provision method, the anchor attribute (localId) is explicitly assigned to the new connector object... CSEntry cs = ma.Connectors.StartNewConnector(mventry.ObjectType); cs["localId"].Value = mventry["localId"].Value; ...this is presumably necessary because the anchor (localId) cannot be included in the export MA's attribute flow as it is read-only. Possibly because it's used as a direct join. It seems a bit counter-intuitive that the anchor (localId) should be assigned by the metaverse rules extension when it's disallowed in the MA's attribute flow. But the same MA configuration and rules extension DLL is currently working on an ILM2 environment. Any further clues would be much appreciated.
February 10th, 2010 8:34am

Regarding the code extract from my Provision method posted above... I've found that if I assign a value to "cs.DN" then I can provision new records. However, existing records continue to appear as Metaverse Retry Errors with the message "The image or delta doesn't have an anchor". I'm not sure whether this is because I've "damaged" these connector space objects by provisioning without a DN the first time round. I'd like to either clear the retries, or clear the connector space objects through the UI. I can delete the connector space objects in my SQL MA (import only). But my Extensible Connectivity MA (export only) reports the same error message and won't let me delete the object. The puzzling thing about cs.DN is that the documentation/blogs suggest you only need to assign a DN if the target data source (ie. LDAP) needs one. And I'm sure my code has run successfully before without setting the DN. So perhaps I've misconfigured the MAs such that the DN is now necessary. RE The DN, I'm currently generating a new GUID for this. But I wonder why I shouldn't just use the attribute used for the anchor, which is also a GUID ? I'd be interested to hear any suggestions on the best way to clear connector space data (or even the metaverse data if that's what it takes to get rid of the "image or delta doesn't have an anchor messages). I've tried the suggestions made elsewhere about importing just one record from the import source. This works for the new single record, but I still get the Metaverse Retry Errors.
Free Windows Admin Tool Kit Click here and download it now
February 16th, 2010 8:52am

The puzzling thing about cs.DN is that the documentation/blogs suggest you only need to assign a DN if the target data source (ie. LDAP) needs one. And I'm sure my code has run successfully before without setting the DN. So perhaps I've misconfigured the MAs such that the DN is now necessary. Where have you seen this? It is definetley wrong and should be updated.You must always specify a DN when provisioning new objects.The "special thing" regarding data sources such as Active Directory is that the DN is not the same as the anchor.See "Synchronizing Active Directory Objects to SQL Server" for more details. When you don't set a DN, you should get an exception in your provisioning code. I'd be interested to hear any suggestions on the best way to clear connector space data (or even the metaverse data if that's what it takes to get rid of the "image or delta doesn't have an anchor messages). Clearing a connector space is the same as processing imported deletions for the affected objects.One thing you can try is to disable provisioning when you delete a connector space.That should do the trick.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation
February 16th, 2010 9:43pm

Thanks for the response Markus. Regarding the DN, this article talks about the DN below the heading "Set the Appropriate Distinguished Name or Attribute Values"... http://msdn.microsoft.com/en-us/library/ms698375%28VS.85%29.aspx ...it doesn't explicitly say not to set the DN, and of course the code samples do set the DN and that's why I tried it. The heading could read "Set the Appropriate Distinguished Name *and any other* Attribute values".
Free Windows Admin Tool Kit Click here and download it now
February 17th, 2010 1:27am

Not sure I agree with you - all samples I've looked at do actually set the DN...Anyway, the bigger issue I see is that you didn't get an exception.If you don't set the DN during provisioning, you should run into one.I'll let the owner of these page know that there is a need to clarify this topic a bit.Cheers,Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
February 17th, 2010 2:02am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics