Recently I received a question, how we could alter the pattern of the user display names in SharePoint, for example, use FirstName LastName instead of LastName, FirstName. A few weeks ago I read a similar discussion somewhere on the web, where the participants had very strange proposals for the problem, ranging from event receivers on the SharePoint user information list to SQL triggers (!) on the SharePoint content database tables.
My first idea was to alter the user profile import process to get the display name dynamically through a BCS .NET connectivity assembly based of values stored in Active Directory. Unfortunately, all of the user profile synchronization samples I found that involve BCS connections (like this or this) illustrate only static values based on SQL databases, but no .NET connectivity assembly.
I’ve started Visual Studio 2010 with a new Empty SharePoint Project, and added a new Business Data Connectivity Model item.
I’ve altered the .bdcm file as illustrated by the XML below.
Note: Most articles mention that one should implement a SpecificFinder method as well as a Finder method in the BCS model, however based on my experiments it is enough to implement only the SpecificFinder method.
The ADEntity class holds the information on the AccountName – DisplayName values.
The ReadItem method of the ADEntityService class receives the account name as parameter, and gets the corresponding display name from the Active Directory using the custom pattern.
Note, that since the original format of the display name was already FirstName LastName in my case, I chose the FirstName LastName (Department) pattern as my custom display name format.
For the AD connection I used my custom ADUtils class.
Having my BCS model deployed, I’ve created a new user profile synchronization connection as illustrated below:
Next, I’ve removed the default property mapping of the Name user profile property…
… and created a new import mapping from our BCS connection:
Finally, I’ve started a full user profile synchronization. After a while (near to the end of the process) the synchronization process accessed our custom connection:
Debugging the import process
If you try to debug the synchronization process, you find, that attaching the debugger to the SharePoint Timer Service (owstimer.exe) or to the SharePoint web application processes does not help.
So which process is responsible for calling our custom assembly? To answer the question, I used the trace messages from my ADUtils class, and the DebugView application.
From the trace it is clear, that the process is the miiserver.exe (process ID 3740 in my case). In Task Manager this process is identified as Forefront Identity Manager Synchronization Service.
Attaching our debugger (for example, Visual Studio) to this process, we can debug our custom BCS connectivity assembly.
Results of the synchronization
After the synchronization process finished, the changes are immediately visible in the user profiles:
As a next step, we should propagate the changes from the user profile to the SharePoint sites. To achieve that, I’ve started the User Profile Service Application – User Profile to SharePoint Full Synchronization job:
After the job is executed, the new display name format should be visible in the SharePoint user information list:
in SharePoint items:
as well as in the People Picker:
You can download the sample project for this post from here.