I believe my treatment of the anchors and DNs is at the root of my inability to export objects with a reference-type attribute defined. I have 13 users in an ECMA, 3 of which do not have any roles defined. Roles are recorded in a multi-value reference attribute. Only the 3 users with no roles are exported. The ECMA connector space looks fine immediately before Export. The users and roles are all present and the references are visible. The objects in the ECMA connector space report ok with csexport.exe - although none of the objects have anchors. Is it expected that none of the objects have anchors before the Export? Maybe the lack of anchors for the role objects is what is preventing the export from processing the users with roles? Here's an extract of an unapplied-export-hologram for a user's roles attribute that will break with "Image or delta doesn't have an anchor" error upon export... <dn-attr name="roles" multivalued="true"> <dn-value> <dn>0b04ef9c-7d59-414c-a242-e516d9989725</dn> </dn-value> <dn-value> <dn>f53cdd7e-68f6-4651-b159-4620243ac6f9</dn> </dn-value> </dn-attr> ...should these values have anchors at this stage? For ECMAs, should DNs be unique across all connector spaces? I've tried both approaches - creating a unique DN during provisioning, and also using the DN of the importing SQL MA. My configured anchor attribute is being populated during provisioning yet the objects in mms_connectorspace show NULL in the anchorcolumn. Here's my provision code which sets the anchor attribute (localId is set as the anchor on the "Configure Attributes" MA page)... ConnectedMA ma = mventry.ConnectedMAs["Export"]; if (ma.Connectors.Count != 0) { //Connector object in Export MA already exists return; } cSEntry cs = ma.Connectors.StartNewConnector(mventry.ObjectType); cs["localId"].Value = mventry["localId"].Value; ReferenceValue DN = ma.EscapeDNComponent(mventry["localId"].Value); cs.DN = DN; cs.CommitNewConnector();

In further tests, it doesn't seem to matter what I set the DN to. If I don't set it at all I'm supposed to get an exception but that's not happening. It seems FIM will set the DN automatically if I don't provide it. Is there any reason why the DN shouldn't be set to the same value as the anchor attribute? I've reviewed my ECMA against the documentation. The document titled... "Developing a Call-Based Export Management Agent" (http://technet.microsoft.com/en-us/library/cc720605%28WS.10%29.aspx) ...doesn't even mention DN. The code sample for the Provision method doesn't assign a value for DN. During the review I noticed two discrepancies with my ECMA. Firstly, the documentation doesn't JOIN any objects in the ECMA, so I removed my joins. Secondly, the documentation imports an object type called "Person", projects to a MV object called "ECMAPerson" and then exports a "Person" object. What is the purpose of the ECMAPerson object type in the MV? Why does it need to be different to the CS object type? I've modified my ECMA to export the same type of object that as imported in the SQL MA connector space. Despite a raft of changes, I'm still getting "Image or delta doesn't have an anchor" errors when FIM tries to export a user that references a role.

Barry, the anchor is the attribute used to link an CS object with an object in an external system. The DN is the user-friendly string representation of this attribute. In many cases, the DN is the same as the anchor. During provisioning, the DN must be set. If the anchor is the same as the DN, it is sufficient to set the anchor because when you set in this case the anchor, you also set the DN. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation