Questions
Improve handling of Root Organization behaviour
See APRA-38, IDBSP-47 and http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/e9c91765-4c35-424d-888d-58e993783855. SharePoint 2010 will become unresponsive if the root organization is set to be its own parent, even though SharePoint does not prevent you from doing so programmatically or via the UI. Both the UI and the object model are affected by this bug. SharePoint considers the root organization to be the first organization with a parent of -1 in its database (ie. how it determines its value of the RootOrganization property). It is operationally and functionally valid for multiple organizations to exist with a parent of -1, and also to be self-referential (ie. their own parent), but doing so on the profile SharePoint considers its root brings about this instability. The connector could account for this functional limitation by preventing the solution from modifying the parent of the root organization. It is then up to solution implementers to ensure the behaviour of their hierarchy is correct.
Estimate includes work initial research carried out already, as well as implementing and testing.
Customer support service by UserEcho
Also confirm at the time of implementation that this behaviour has not already been fixed by Microsoft in a rollup or service pack.
Adam,
As part of the SharePoint upgrade, if possible.
Because the connectors are now cached and cleared, the IdM reference to SharePoint RecordId dictionary needs to be stored in StoredValues, otherwise exports will constantly miss out on exporting the parent reference.
Adam,
The org profile connector now uses the stored values collection, not a dictionary, for its lookup of parent values. Imports, adds, and updates have all been confirmed to do this correctly, including during a multipass from FIM (add and update in the same call). Issue resolved, please confirm as appropriate.