Top 10 tips list for SharePoint 2010 Search Success

Update 4-20-2011

1. Never ever use spaces in columns that contain managed metadata values. Those items will become unsearchable.

http://www.bpostutor.com/post/SharePoint-2010-Crawler-Error-Index-Was-Outside-the-Bounds-of-the-Array.aspx  

2. Search results titles do not match document titles in SharePoint 2010. How to fix.

http://www.bpostutor.com/post/Hidden-SharePoint-2010-Feature-Changes-Document-Titles-in-Search-Results.aspx

I recently was discussing an issue with a SharePoint user regarding SharePoint search which I thought I’d share.  It’s an issue of perception or how SharePoint is sold and the anticipation which is built up around the search feature set in particular.  As with all things SharePoint search takes time to not only uncover the out of the box capabilities, but also what is beneath the surface and how that capability translates into a workable solution for each customer situation.  Let me quote him now -

We are struggling with the search feature in SharePoint 2007. Too many results, end-users are getting frustrated.  We are still new to SharePoint - about seven months new. We thought the search feature would be our end-all be-all, however, it has turned into a frustration point for many of our end users and is quickly diminishing in value. Are others struggling with this? I've read some other posts regarding searches and ranking, etc. It all seems very "out there". Are there any out of the box features I can use to help our end users find the information they are looking for a bit easier? We are using best bets, although, I'm finding that unless I know what people are searching for and cannot find, a best bet may be too late. An example is a quick search for action plan - it returned 180 results, when all I needed was the action plan document. When our front line employees see this and have a customer in front of them panic begins to hit and SharePoint becomes a "monster". :) Any help is appreciated!

Well all these pain points with SharePoint search led me to think up a few suggestions and helpful tips that are easy (almost no code to implement!).  I ended up making my top 10 tips for SharePoint search success - more relevant to SP 2010, right now but many can be applied to SharePoint 2007. He already covered best bets – these are really useful when you want to create a static mapping between a phrase, word, etc and some specific content.  The best example of this is a product support portal where we’re offering drivers for download. If I search for the term “WRT-150n” we can create a best bet match right to the support page for that product…and align a bunch of terms we want to match up as well.  Everyone understands this and its obvious and easy to pass around that common term or terms that make sure the customer winds up on the right page.  Second example on a public facing site is “Contact info” or “address” …. we’d want to send to the most relevant result without having to rely on SharePoint ranking algorithms which out of the box will provide a difference relevancy than we may want.

Ok, on to my list minus best bet.  I must add that many folks do not realize that search is not configured out of the box. It requires tuning to your specific business case and document types.  This also means you need to create your taxonomy, columns and bundle them up into SharePoint content types. Isn't too hard which is great, but it does require planning and the knowledge to know how to execute and create a usable solution. Here's the basic process you want to go through.

1. Invest time in creating a taxonomy which is realized in SharePoint via Columns and Content Types with some mandatory metadata (column values) across all documents. There should be significant differences between the nodes in your taxonomy so that search can help you locate this data.  The other part of the taxonomy between very content oriented organization tools are the hierarchy of site(s) across your farm.

2. Build your custom columns for your SharePoint content types. Let me provide some examples:

CorpDepartment = constrained list if your departments

CorpDocType = constrained lists of the document types in your taxonomy which you wish to track

CorpStatus = constrained list of status (example: final, archive, etc)

CorpTags = user specified tags.

The first three columns are standardized values that should be very meaningful to your organization.  CorpDepartment might be HR, Finance, Legal, Sales, Marketing, R&D, Safety, etc.  CorpDocType might be agreement, financial documents, policies and procedures, lab notes.  CorpStatus might be final, draft, WIP, submitted, reviewed, pending submissions, won, lost, deferred, received, etc.

But here’s where the other dimension of these content types ( a grouping of SharePoint columns) – the CorpTags columns is user specified. This provides more of a “folksonomy” – basically values or tags end users add to allow them to categorize items (and search upon those terms) if they can more easily find content in that manner. 

3. Configure a content type publishing hub and the managed metadata service. Use these features to push and keep updates current with your taxonomy on all subscribing sites across your farm. This is a very SharePoint 2010 centric feature.  In SharePoint 2007 we had the concept applied of inherited content types and columns.  We have the same concept of inheritance in SharePoint 2010 columns and content types.  The managed metadata service extends this concept across farm(s) to provide very standardized set of terms (a term set) and there’s a nice user interface in both SharePoint Central Administration and on each site collection where the feature is activated.  This allows both centralized and distributed maintenance of the term set.  You may also enable user free text term store updates.  This extends the tip #2 of having a “tags” column and setting these up as enterprise-wide user specified terms.  Now that’s a powerful taxonomy.

4. Add sample documents for each major content type. Complete metadata on each documents properties. Kick off a full index. Verify that your new items were index.  That’s right folks we’re dealing with a chicken and egg situation.  You need your columns first, then your content types, then content associated with the first two…and then a FULL INDEX. After that then you can go back into your Search SSP in SharePoint 2007 or the Search Service Application in SharePoint 2010 and define your metadata settings by clicking the Managed Properties link.

5. Configure your managed properties based on what was just indexed. The end state would be this example search query "CorpDocType:Contract" – the start of this configuration is done in central administration in the Search Service Application (SSP in 2007).  Go into the service application or SSP – then create your property mappings. See tip number 4 if you don’t see your custom columns.

6. Configure search scopes that make sense to you, IE "HR Departments" "Contracts" "Legal Department".  Out of the box SharePoint won’t pick up your scopes until you define them and add them into your search configuration for your search boxes on your sites.  Once they’re set up then the corresponding features get lit up and users can accurately scope their search results by these parameters.  I once was in a situation where we built a knowledge base on top of SharePoint.  We had scopes set up for page libraries that content knowledge base articles on particular products.  The scopes were “Exchange” “SharePoint”  “C#”  “BizTalk” etc.  You get the point.  Now apply that to your situation. 

7. Configure advanced search to properly pick up all your properties (edit the advanced search webpart - add entries into the Properties REF and Properties DEF sections. Also bring this XML file into Visual Studio. Check out the other nodes for document types. You may want to add some other entries.  This brings all the previous tips to life. 

8. Train your users to accurately use the content types you have created. Yes this really important.  If users don’t put in the small, but crucially significant, effort to properly tag or enter document metadata then none of SharePoint’s search capabilities except for full text search will work. 

9. Train your users to accurately use SharePoint Search query formats. (really key).  Yes you must tell people how to properly form their queries! It is not obvious.  This is a perfect opportunity to create a back and front job aide of training slick.

10. Also use AD groups on your site collections instead of SharePoint groups. This will allow for much better search performance and scalability over time especially if you have a TON of sites and content stratified across many, many departments or functional groups of users.

This is important but not daunting work.  And remember you’ll get that awesome SharePoint faceted search functionality out of SharePoint 2010’s basic search feature set.  This means you can easily pivot on metadata values to get another dimension of the content and results.  Also, the work with the content types driven by the managed metadata service provided columns will allow you to use metadata explorer and metadata navigation. If you’re a developer you can leverage this functionality in many ways downstream and further the maturity of your content organization or visual/UI/UX interactivity.

If you're a big company you want to get your ECM committee or records management folks involved in your taxonomy creation. You also want to spend time researching the managed metadata service application and content type publishing hub feature. In larger deployments this is really important to standardization and maintaining that standard across all SharePoint sites in your farm(s).

You could also attach some ILM policies (retention) to your content types once created - this is only a bit more work (couple of hours of planning and configuration for a very basic set up). This will allow you to remove old version after a period of time... or in fact go ahead and delete content you don't need or perhaps kick off a workflow to notify users that there's old or archive content they can get rid of. This helps prevent the digital landfill situation all content management and document management platforms suffer from.  You should ONLY do this after speaking with your legal department or records management folks.  In some cases documents in SharePoint might only be working drafts and are not “records” or the system is not considered the system of record of that content.  While creating the policies in SharePoint is relatively easy there’s a lot of room for improvement (which I’ll get into the future with metadata based retention).

Isaiah Campbell is a SharePoint Solutions Architect and has worked with SharePoint since the first release of the product (almost 10 years ago this month!)