Hi,
Version FIM2010R2SP1 with latest publicly available hotfix rollup applied.
Use case: Legacy enterprise directory (SUN iPlanet 5.2) has users in different (ou) branches under the same tree depending on their current job. If they are transferred to another part of the organisation in the HR system, the requirement is to move their user entry in this directory into a different ou.
MA/Connector: Out of the box Sun/Oracle directory MA
e.g. (dn) uid=hsmith001, ou=Sales,o=MyOrg.com
moved to:
(dn) uid=hsmith001, ou=Cleaners,o=MyOrg.com
When the export is run to the connected directory, the "move" does actually happen in the connected source (the SUN directory server). So far so good.
The connector space object is now marked as 'Awaiting exportconfirmation' (which is meant to occur on the next import).
When an import is run, FIM creates a new connector space object with the new (renamed) dn but retains the existing object . At the same time it reports an error "ambiguous-import-flow-from-multiple-connectors" because it is seeing two objects with the same RDN (uid=hsmith). It has marked the original CS object for deletion.
On the next synch, it says it has successfully deleted the original CS Object, however it is still there (and with the same anchor guid).
It appears that with this connector connected to Sun Directory v5.1 and newer , you don't get to choose which attribute(s) you use for the anchor - it chooses the dn.
It's puzzling why this issue exists in a technology set that has been around for years, so we are assuming that there is workaround or solution to this problem.
N.B. This problem has been replicated on two completely independent environments by different people in our organisation.
Any help/advice/suggestions would be most welcome.
David.