SharePoint Search Deployment Guidance - Part 2
In my last post titled “SharePoint Search Deployment Guidance” I highlighted some points on which you will need to start planning for. In this post I will showcase some steps on how to provision a Search center for an Intranet deployment.
The scenario that I am hoping to showcase is how you can identify specific requirements for Search in an Intranet deployment. Usually Intranets are used to provide a specific solution to a business requirement. Depending on the business your Intranet can be used for a specific role or roles. Some questions you can ask to identify the objective of your Intranet are: Is it to provide information about new policies and procedures? Is it to provide sales and marketing information to sales staff? Is it to provide information to your help desk? Or, all of the above? Depending on this context your Search deployment will need to have specific requirements to match these objectives. If we take the example of the intranet being used by your general staff to search for new policies then you will need to ensure that when users Search the most relevant and contextual information regarding these are available. Furthermore Intranet result sets can be controlled to provide better accuracy since you control how and what is being searched by your users. The challenge is identifying these in context.
No matter how you look at it there are three key steps in the search process. These are,
Search in Microsoft Office SharePoint Server 2007 Evaluation Guide (MS Word Document) This evaluation guide is designed to present a solid understanding of the search capabilities in Microsoft Office SharePoint Server 2007. It provides an overview of Enterprise Search solutions from Microsoft, gives a hands-on tour of the product, and concludes with useful information for administrators and developers. IT professionals should use this guide to perform a thorough and effective evaluation of Enterprise Search functionality in Office SharePoint Server 2007.
Depending on what version of SharePoint you are using you have plenty of options. If you want to see what version of SharePoint version is best for your requirements you can follow this guide titled “Microsoft Office SharePoint Search feature comparison” . For simplicity assuming that you have the enterprise version of SharePoint you are able to index and search various electronic file types and content sources.
(*) For indexing third party document stores you will require to obtain third party protocol handlers or develop your own. Some vendors provide this functionality via API integration with SharePoint. Some examples are available on the Enterprise Search connectors page.
Note down and identify all the content sources that you want indexed. As a rule of thumb I always follow the principal of “Information or data that is hard to obtain may not be used as much as you think it is”. From a practical stand point you would want to make sure that most recent information sources are treated as priority before going on an indexing a content source that is mainly historical such as an archived file share. You may argue that it is important but usually if you couldn’t find it in the first place usually means that your users may not necessarily need it from day one. Things to look out for when indexing such old sources of information is that they may not provide you with the relevant results your users need. If you are doing a pilot for Search target a new or a recent file share so that users can actually relate to some of the information that is being retrieved. If you get a reaction of “Hey, I wrote that document 4 weeks ago!” when a result set is displayed, you know that you are on the right track.
Content Sources are defined in the Search Settings configuration page in SharePoint. In typical deployments this is found in the Central Administration web application. If your deployment is specific to Search and you have a role defined for “Search Administration” then you will need to give access to the Search Settings page via Central Administration and the Shared Services Provider. You can also access the Search usage reports from this screen.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/ConfigureSearch_2.png)
In this lab example I am using two content sources which represent the local SharePoint sites and a File Share. Content sources configured via this page is available for Search from your SharePoint sites. You can create new content sources by selecting Content Sources and crawl schedules link. Depending on what your source is you will have different settings to configure for your source.
Once you have created your content sources and indexed your content you can specify how your users can define their queries. In SharePoint, search scopes are expanded to represent a collection of items based on a common element among the items within that scope. For example, in addition to a search scope that represents content from a particular content source (“File Share”), it is now possible to define search scopes such as “All documents authored by [Name]” or “All documents related to Policy”.
You specify the scopes in the Search Settings as Shared Scopes and then assign these to a display group which will display on your portal. It is a good idea to define these at the global level rather than your individual site collection level. You will see a warning message when you select a scope at a Site Collection level.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/SiteLevelScope_2.png)
The shared scopes screen is available on the Shared Services Provider of your SharePoint deployment.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/Scopes_2.png)
Each Scope can have it’s own rules defined. In the below example The scope named “File Share” contains a rule to limit it only providing results from a specific content source. In this case the Content Source of “Local Files”.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/ScopeRules_2.png)
You can add further rules to be build more definitive results. Example include all Content from the File Share as well as Where the Author = “Chandima Kulathilake”. This is called a Property Query. You can add extra properties to the “Add property restrictions” page via the “Managed Properties” screen and selecting the property you want and checking this to be available as to the property query.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/ScopeRule2_2.png)
The Managed Properties screen provides the ability to see which properties are used in scopes. The most common properties available by default on the Property Query drop down selector are; “author”, “contentclass”, “contentype”, “site” and “sitename”.
Once you have configured your scope settings you can go to your Site Collection and chose to display the Search scopes in the scope drop down. Display groups provide a way to assign scopes to a particular search box. Site collection administrators have several options for configuring the existing display groups or they can choose to create one or more new display groups. For example in this Intranet Site Collection I have chosen the 3 scopes to be available via the Search drop down display group.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/SiteScopes_2.png)
Scopes displayed on the “Search Dropdown” display group to the end user.
](https://www.chandima.net/Blog/Lists/Posts/Attachments/146/NewScopes_2.png)
As you can see you can easily cater for various business requirements with the OOTB Search functionality of SharePoint. In my next post I will talk about Tuning your results by using relevancy and also about how the indexer works in general. If there are any specifics you need answered leave a comment and I’ll incorporate that to my next post.
Plan your Search Team (From TechNet) Programmatically Administering your Search (From MSDN)