harbar.net component based software & platform hygiene

It’s all about relevance. The *-SPProfileLeader Windows PowerShell cmdlets in SharePoint Server 2010 SP1

Print | posted on Wednesday, July 06, 2011 12:03 PM

You may have noticed a few new Windows PowerShell cmdlets included with SharePoint Server 2010 Service Pack 1 (SP1), Get-SPProfileLeader, Add-SPProfileLeader & Remove-SPProfileLeader. These cmdlets are causing a little bit of confusion, so this short post explains them and the problem they are intended to address.

First up, they have absolutely nothing whatsoever to do with Organizational Profiles. The term “leader” here is somewhat misleading (no pun intended!).

What this is all about is User Profiles and People Search Relevance.

One of the key pieces of data that SharePoint Server Search uses to drive relevance in people search results is the user profile property Manager. This is sensible, social distance etc are great ways to deliver highly relevant search results. However, it all relies upon the quality of data. The old adage, “rubbish in, rubbish out”, was never more relevant.

The problem with the Manager property is that in most cases it will be coming from Active Directory via the User Profile Synchronization service. And this is where the problem lies. In most organizations, the Manager attribute in AD exhibits very poor data quality. It’s either out of date, or wrong. But more often than not it’s empty. If all your users have no manager, there is no way for people search to distinguish between company leaders, and everyone else.

The ideal implementation is that only the company leaders would have an empty (null) Manager attribute and therefore Manager user profile property, and everyone else would have correct and up to date managers. Telling customers that in order to improve people search relevancy there needs to be an exercise to fix up AD after the deployment of SharePoint is, as one of my good buddies says, a dog that won’t hunt.

And this is where these two new cmdlets come into play. In SP1 we can now specify the actual leaders of the company directly, regardless of the state of the AD attribute. This corrects the relevancy problem.



Unsurprisingly, this bad boy adds a leader. It checks to see if the account name specified exists (in the profile db). Then it checks the Manager profile property. If there is a manager, it will bail with an error. If there is no manager, it will write a row to a table someplace which identifies that user as a company leader.

$upaProxy = Get-SPServiceApplicationProxy 7643a5c2-a6ae-49eb-8ba0-de2f32a890ba

Add-SPProfileLeader -ProfileServiceApplicationProxy $upaProxy -Name "contoso\davism"
Add-SPProfileLeader -ProfileServiceApplicationProxy $upaProxy -Name "contoso\jonesq"

Get-SPProfileLeader -ProfileServiceApplicationProxy $upaProxy
Failed. User 'contoso\davism' has a manager.
User 'contoso\jonesq' added as a leader.

Once you’ve added a leader with Add-SPProfileLeader, you will need to perform a full crawl of your content sources for the changes to take effect.



Yup, you’ve guessed it. This guy returns the current leaders so you can verify it worked or see who they are.

Get-SPProfileLeader -ProfileServiceApplicationProxy $upaProxy

AccountName                                                   Valid ManagerAccountName                                      ReportCount
-----------                                                   ----- ------------------                                      -----------
contoso\jonesq                                                 True                                                                   0



Removes (or RIFs if you will :)) a leader.

Remove-SPProfileLeader -ProfileServiceApplicationProxy $upaProxy -Name "contoso\jonesq"
User 'contoso\jonesq' removed as a leader.


So there you go. A nice easy way to ensure that your CEO’s pages are high up the search results page in People Search.