One of the niceties (at least for us implementer-folk) of SharePoint’s search is that both the content and display of the result page can be changed with a few tweaks to some the profile sync process, managed properties, search query result web part properties, and the result XSLT. Okay, so I’ll admit, it isn’t the most straightforward process, but it’s still pretty cool that this can all be accomplished without any custom code! If you have liberal definitions of “out of the box SharePoint functionality” like I do, then you’re in luck. Everything we’ll be going through here can be considered Out of Box!
Alright, so this post-series will be fairly detailed, therefore it will be broken up (for both author and reader sanity) into three parts:
For those of you that have done any searching on the subject, you will find a decent amount of custom people search XSLT result sets out there. However, what you’ll struggle to find is an end-to-end instruction set to fully implement a customized people search experience. I know it’s a lofty goal, but I hope this series of posts can help you get from zero to your custom people search experience. At the very least, it should get you pretty close!
So here’s the process that we’ll be going through:
If you are only going to use the 21 or so default mapped properties, feel free to skip ahead to the second post. Again, this first part is only required if you have non-standard user properties that you would like to display in People Results. My favorite example of a non-standard attribute is the ‘Mobile Phone’ value. In most AD implementations, a standard user account will not be able to ‘read’ this attribute into SharePoint’s user profiles. In order to properly access these properties, work with your AD administrator to secure a Profile Import Account with the correct level of access. Basically, the account will need the ability to read each of the fields that you’re working to import. I’m not going to dive into the details of setting up the correct permissions in this series, perhaps in the future I’ll tackle that subject. In the meantime, if (and only if) you’re in a test environment, the easy solution is to use a Domain Administrator account; please do not do this in your production environment.
To change this account, navigate to the Shared Services Provider (SSP) that you’ll be working on (you may have a direct link and/or it’s accessible from Central Administration). Once on the SSP homepage, click the ‘User Profiles and Properties’ link. From the next page, you will want to click on the ‘Configure Profile Import’ link. From the following page, select the ‘Specify Account’ radio button in the ‘Default Access Account’ heading and enter in the credentials for your elevated account.
The next step in the process is to add whatever additional fields you need to the ‘User Profiles and Properties’ area. To do this, navigate to SSP homepage, and click on the ‘User Profile Properties’ link. Near the bottom of this window, you will see a heading called ‘User Profile Properties’; click on the ‘Add profile property’ link. This will bring you to the form shown below. If you’re looking to display the ‘mobile’ attribute (or whatever value you’re adding here) to all employees, feel free to mirror the settings in the screenshot below. If not, tweak the settings to your liking.
The hardest part of this form is the dropdown near the end where you actually select what Active Directory field you will be mapping to. These field names are not necessarily intuitively named. For example, city is called ‘l’. To get an idea of what field you’re looking for, go ahead and and fire up ADSI Edit and connect to your favorite domain controller. From here, you’ll want to navigate to an OU that contains a User Account with the property that you’re looking for. Once you find the user account, go ahead and right click on it, and select properties. This will bring you an exhaustive list of that object’s AD attributes. Go ahead and find the property you’re looking for and then select that property in SharePoint’s Add User Profile Form. Be sure to note the AD-names of all properties that you add as you’ll need this list later.
After clicking OK and repeating this process for all of the non-standard fields you want to import you should be ready to move on to the next post, which I’ll finish up in the next couple of days.