SharePoint Config

I’ve had a couple of requests to extend the people directory I covered in a previous article on How to: Create a Simple SharePoint 2010 People Directory. One request was to show how to display the results in a table based layout. Displaying a basic table like the one shown below is really straightforward and simply involves some modifications to the XSL property of the search results web part.

I’ve had a few clients ask for a page on their intranet that allows users to browse a list of people within the organisation without having to enter a search query. They then want to see a list of filters such as Department or Job Title to allow them to filter the results. This is really easy to set up using the default SharePoint 2010 search web parts and doesn’t require writing a single line of code. An example of what this can look like is shown below (note no query is specified, we have just clicked on the ‘people directory’ link in the top nav):

On the 13th of April I presented at the European SharePoint Best Practices conference 2011. The session was titled Search Driven Knowledge Management and in the session we covered some of the SharePoint features available for structuring information so content is easy to find. As this was a community track session we looked at some real world projects that had information architecture requirements that didn’t line up with the out-of-the box SharePoint features. We looked at the requirements for these projects and I showed how solutions were built using a combination of the SharePoint features and customisations built on top of the SharePoint platform. This included using a search driven architecture and automating the tagging of content using the new content management features of SharePoint 2010.

Search scopes improve the SharePoint search experience by letting users search over a subset of information within an organisation. For example you can create a search scope for a specific project or a group such as Legal or Marketing. Search scopes can either be created at the search service application level and ‘shared’ by all site collections, or defined within a specific site collection.

Shared search scopes in SharePoint 2010 can easily be created using PowerShell commands such as New-SPEnterpriseSearchQueryScope. Corey Roth covers this in his article on Creating Enterprise Search Scopes with PowerShell. While the PowerShell method can also be used to create site collection related search scopes you might also want to do this programmatically in a feature receiver when the site collection is created. Another thing you might want to do programmatically is to associate a search scope with a display group such as the ‘Search Dropdown’ so it appears in options next to the search box. I’ll cover both these scenarios in this article.

The SharePoint 2010 object model has several classes that can be used to create search scopes and display groups. These can be useful if you want to create search scopes in a feature receiver when a site collection is created. There are several things to watch out for, however, as you can run into problems if you use the SearchContext, SearchServiceApplication and SearchServiceApplicationProxy classes. This article describes these problems so you can avoid them in your code.

I’ve been working with the managed metadata functionality provided in SharePoint 2010 fairly extensively over the past few months. While it is a great feature and works well when used through the UI it has several rough edges that can cause problems when you are deploying features that use managed metadata fields. Some of these have been documented elsewhere but some of these haven’t so this will be the first of two posts covering (1) some of the potential problems using managed metadata (this post), and (2) a robust way of provisioning SharePoint 2010 managed metadata fields.