User Profile connector must prevent attempts to migrate a user to itself

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: A profile migration attempt was made where target and source account names are the same. This would result in the deletion of the account. Please ensure that the account name is correctly populated, and that casing is consistent. 
Source account name: UNIFYDEMO\2222
Target account name: UNIFYDemo\2222 (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.Exception: A profile migration attempt was made where target and source account names are the same. This would result in the deletion of the account. Please ensure that the account name is correctly populated, and that casing is consistent. 
Source account name: UNIFYDEMO\2222
Target account name: UNIFYDemo\2222
   at Unify.Connectors.MossUserProfileConnector.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey) in C:\Hg\Connectors\Microsoft.SharePoint\Master\Source\Unify.Connectors.Microsoft.SharePoint\MossUserProfileConnector.cs:line 78
   at Unify.Framework.ConnectorToModifyAnchorConnectorBridge.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey)
   at Unify.Framework.EventNotifierModifyAnchorConnectorDecorator.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey)
   at Unify.Framework.Adapter.<>c__DisplayClass34.<CheckAnchorChangeOnSave>b__2f(KeyValuePair`2 keyValue)
   at Unify.Framework.Visitor....).

Matt,

I understand. Actually - the resolution for this is something I wanted to talk to you about - i.e. talking about the behaviour. I understand it will throw an error if you attempt to do the rename. However, I am a little concerned about the behaviour of the over-all lifecycle. i.e. will it throw an error and then continue to error? Will it stay as a pending change in ILM / FIM and retry? It is one thing to stop the error (which is critical), but how will it play out over a general lifecycle?

I would have thought that an alternative would be to notice that the accounts are actually the same and then simply not invoke the migration process. This way, no errors and the lifecycle of the over-all solution works out. It is easy to say that you should be careful to make sure the code is entering the correct case. However, in the situation at DET it was correct case. The Connector Space had strange case (refer to recent question I raised https://unifysolutions.jira.com/browse/QDET-96) or between the connector space and IdB generated mismatches. The entry listed below is what was presented to sharepoint in the error:

Modify anchor for entity CN=E00001254260,DC=CAD to CN=E00001254260,DC=cad

As you know from the code snipit, the flow rule had uppercase "CAD", so something within or around IdB decided that it needed to lower case the entry. If, instead of flowing an error, it simply just checked the case and flowed the other attributes that were queued for update I would consider this an ideal behaviour.

This continues the theme of case sensitivity issues throughout Identity Broker and I believe is a major area that needs to be addressed.

regards,
Craig Gilmour

Craig,

The issue with ignoring the migration would be that you would get exported change not reimported errors – ILM would be expecting the account name to have changed.

The issue happening is that the data source and the solution are inconsistent, and due to this behaviour of SharePoint, the result is quite destructive. The Account Name that is sent/provisioned to SharePoint will need to match the account name on the SharePoint side.

Another “gotcha” we have recently encountered is the impact of the container on the resolution and casing of the distinguished name – see https://unifysolutions.jira.com/browse/IDBSP-29, and https://unifysolutions.jira.com/wiki/display/IDBFIM300/An+export+to+Identity+Broker+fails+with+an+ma-extension-error+and+the+Windows+Application+Event+Log+cites+an+InvalidOperationException+as+the+reason. It has seemed that if a container from SharePoint does not match the casing on the solution side, ILM can resolve and create distinguished names differently. In fact, quite recently I saw that the deletion of the only “lower case” account in SharePoint resulted in 15 renames on the ILM side, which were upper case. Perhaps this is a difference between the mirror production and production environments?

At any rate, I believe throwing an error to prevent this behaviour is the most appropriate path that can be taken, without “squashing” FIM’s need to confirm changes. Let us know if you have any other thoughts on the matter.

Regards,

Matt