A user at one of my clients had two active accounts being synced in the User Profile Service with the same Display Name. This was causing problems when using the People Picker option as there was no way for a user to distinguish between the two accounts. If the wrong account was selected the 3rd party solution that is deployed in their SharePoint 2013 environment (not ours) fails to execute all processes but does so “silently”.
When the organization brings contractors or temporary employees in they give them a different identifier than full time employees. For the sake of clarity let us say that a contract/temp employee gets an account like JK111234 and a when brought on as a full-time a new account is created for the user that looks something like FT888111. The User Profile Service did have the filter in place to restrict the import of disabled accounts but the crux of the issue was that the contract/temp account was not being disabled when the user was given full time status and received their new account.
As we don’t have much say in how things are handled in Active Directory within the organization we removed the user that was presenting the issue from the User Profile Service and Site Collection User Information Lists. This temporarily resolved the issue but knowing the profile would be imported again and this was likely to occur with other users in the future we needed to find a better solution. This solution needed to allow both the contractor/temp and full-time employees to access the site and be available in the People Picker but prevent the duplicated Display Names from appearing.
We went back into the User Information List and changed the settings to display the User name and Work email field and noted that every active user had their work email populated which was not the case with the user we removed previously. At this point the proverbial light bulb went off and we realized that even though the organization wasn’t disabling their contractor/temp account the were removing their email address from that account and adding it to their full-time account. We then jumped on Central Administration and verified this theory by looking up accounts that began with the contractor/temp account identifier and sure enough we had a viable workaround to the issue.
The other “aha” moment came when we realized the customized solution was failing to execute a workflow process which was a result of the contractor/temp account no longer having a valid email address. We were then able to create a Connection filter in the User Profile Service where the mail attribute contained nothing. We could use this filter as the SharePoint 2013 environment was specifically created for this 3rd party solution there was no reason to include any accounts that didn’t have email addresses as it would raise other issues in this particular environment as well.
In the end, we came up with a clean way of resolving the issue without having to dig too far down the IT/AD rabbit hole. Of course, if the organization disabled the contractor/temp accounts in AD none of this would be necessary, but as consultants we don’t always have control over those things.