I have been focusing my efforts recently on client projects around SharePoint User Profiles which are part of Microsoft Office SharePoint Server (MOSS) 2007 Editions (Standard and Enterprise). The User Profiles are one of numerous components making up Shared Service Providers (SSP’s) which also include Excel Services, InfoPath Forms Services, Business Data Catalogue and Enterprise Search.

User Profiles

The role of User Profiles is to store information about Users. The information out of the box is crawled from the Active Directory (AD) source from the Domain Controller (DC) that SharePoint is connected to. Each User Profile is built up of a number of out of the box User Profile Properties. Each property can be mapped to a particular piece of data from the import content source. So out of the box there are various properties that are imported from Active Directory.

Company Phonebooks

In most Organisations that I have installed Active Directory and most others I have heard about are not in “ship shape”. This may have gone unnoticed because typically Active Directory is only exposed in the Enterprise in the Outlook Global Address Lookup (GAL), which is usually not promoted if the data is incorrect. Often you walk into an Organisation to deploy SharePoint and they have a ‘Company Phonebook’ which has been custom written by the Development Team over the lifetime of the IT Department.

Enter People Search

Enter SharePoint, and the wonderful User Profiles that are then populated with all the inaccurate or unpopulated data from AD! It doesn’t stop there…because the Organisation’s CEO and CIO have been mightily impressed by the Microsoft Pre-Sales team who demoed “People Search” and want this to be the “first cab of the rank” (god I hate those over-used terms!).

People Search exposes all this data from AD directly in SharePoint in the results page and in even more detail on the individual User Profile Pages.

Clean Up!

So as soon as the inaccurate data is exposed, or sometimes even before go-live as it becomes a show-stopper, the data has to be cleaned up. Immediately debate rises on where the accurate information is stored, if it is at all! Typically it’s within the HR system. But it also usually also brings up issues that the data is often stored in multiple locations and owned by different parts of the business.So a mad panic occurs to export this data and import it into AD!

Synchronisation

Once the data is in AD, or as it is discussed if there are cluey “Enterprise Architects” around, the issue of how this is going to be kept up to date is raised. Enter Identity Life Cycle Management (ILM) to the table! Yes yet another product Microsoft can sell you on top of Windows Server 2008, Exchange Server, SQL Server 2008, SharePoint Server 2007, ISA Server, ForeFront, …to get your company up running.
Realistically this doesn’t get made a priority project and an “interim” solution is devised by the development team.

“What do you mean it won’t update AD?”

So SharePoint has the great ability to let Users update their own User Profile Property data if the Organisation choses to allow it on a property by property basis. This is great, but the big clanger is that when you update this…it only updates the User Profile and does not go and update AD! This means that your overnight AD crawl will overwrite User changes made during the day! To me, this is one of the single most annoying parts of the Platform.

Solution 1: The SharePoint Timer Job

So there are various ways that this can be resolved. You can have a SharePoint Timer Job that before the SSP User Profile crawl occurs on AD, it spins through all of the User Profile Properties of each User Profile and updates AD if they are mapped. It could also potentially update other repositories that are crawled via the BDC too.

“What do you mean my PA can’t update my details while I’m playing golf?”

This is a great solution, but most Organisations have one other big clanger of a requirement. They wish to delegate the updating of User Profiles to secretaries and personal assistants (must get myself one of these).

Solution2 : The Custom Update Form

In this solution, a custom aspx page is deployed to the SharePoint Farm. This has a series of user controls on it that bind directly to the User Profile Properties. The page can be accessed not only directly, pulling the authentication details of the log in user to get the context of User Profile for the form….but also using a query string to pass through the Guid of the User Profile to grab context also.

In addition to this, if there is a query string present, there is a check to see that the authenticated user is part of a specific AD group to allow them to update other User Profiles. You could get very clever and check the AD property to see that the logged in User is the PA/Secretary of the User Profile being edited.

On submitting the changes for this form, the User Profile Web Service is called to update the details. One caveat here is that the Web Service is instantiated with credentials of someone with high enough credentials to update anyone's User Profile, because out of the box you can only update your own User Profile. Secondly, the AD entry is updated for those properties that are mapped to User Profile Properties.

“What do you mean you can’t get rid of all those Director entries?”

How many times have you done a People Search in a SharePoint Farm and seen on the left hand side…narrow your search: “Director”, “DIRECTOR”, “King Director”? I’ve seen lots! SharePoint does not allow for data cleansing via validation or formatting.

Data Entry Validation and Formatting

One great thing about having a custom form is that you can get some extra sugar coating on your solution to enforce validation and formatting - not only in terms of manual data entry of fields but also giving the ability to have lookup lists for properties.

 

“The CIO wants his picture on his profile!”

So the demos look slick with all the fancy pants profile pictures of the CEO’s and CIO’s staring 36.5 degrees to the left with their hand on their chin. But User Profile Pictures aren’t that easy either…you can’t update these pictures in the out of the box Edit Profile form! The Picture Url used is a User Profile Property instead.
Solution

The neat solution I came up with was to have a Picture Library at the root Site Collection for the SharePoint Web Application. On adding/updating a picture in the library an Event Receiver is fired that grabs the filename of the glorious photo that maps directly to the AD user name of the User. This then calls the User Profile Web Service to update the Picture URL property to the location of the new uploaded file. This can then be delegated off to Security Personnel who take the pictures for the Security Swipe cards. Neat huh?

“I want mobile numbers on the results page!”

One of the most common requirements I get is to add various User Profile Properties to the People Search Results page, because…lets face it…the ones they show require you to click through the User Profile Page…and lets face it..who wants the extra click? This is another area that annoys me! How hard would it have been for the team to put the XSL that transform the results in the Site Definition to be deployed to the Style Library like everything else rather than hard coding it into the CDATA of the web part?!? Dog food anyone?

Solution

The solution here is a simple one and available on the SharePointDevWiki.com as a PowerShell script. It simply changes the Web Part to work how it should by setting the XSL location for the transform to a Style Sheet of your naming in the Style Sheets Library…which you can then deploy using a Solution Package. Sweet huh?
To be honest, you could go one further and have the Feature Receiver tweak the web part, but it’d need some smarts to know where the peopleresults.aspx instance is…although it could get it from the default Search Centre of the Site Collection…I decided to make this manual ;-)

“I changed my info and it’s not updating!”

Another great example is that if you look at the top diagram, you’ll notice theirs a search index in between the People Search Results page and the User Profiles. This highlights the issue, that if the User Profile is updated, it will not be shown on the People Search Results UNTIL the next crawl of the User Profiles (1).

In a larger example, you may have multiple SSPs which are all configured to crawl the same AD data…so the Form can also update more than one SSP. Otherwise, you’d be waiting for that User Profile to crawl AD (1), then the Index Server to crawl the User Profile (2) for the changes to show!

The Solution is here

So why am I telling you all this? Well I’ve written this solution already. Albeit each implementation requires configuring for various options and specific scenarios required by the Organisation. I just figured I’d share my findings about People Search with everybody :-)

The Future is ILM

So, based on these issues I was kind of hoping that SharePoint 2010 would address this. My gut feel is that Microsoft simply won’t…”why?” you ask…well because of the ILM product. They want Organisations to spend more pennies!

Notes

There are some great scripts on the SharePointDevWiki.com that help you import data from CSV’s into User Profile Properties.