Chris’s SharePoint Reflections

Just another weblog

  • Chris Zhong

    IT consultant Australia

  • Advertisements

Archive for February, 2009

Managed Property in SharePoint Search

Posted by chrissyz on February 17, 2009

Managed Property plays a very important role in MOSS 2007 Search. If used properly, you can greatly enrich the user search experience without spending a lot of effort. Before we go in the topic, let’s look at what is managed property.

The SharePoint search engine index both unstructured information, like text in word documents, http pages ectc and structured information (metadata), such as file size, file extension, title, author etc. We call this piece of metadataproperty. SharePoint operates with two kinds of properties: crawled property and managed property. Crawled properties are discovered by the crawler. Each SSP has a list of crawled properties in the metadata store in its SQL database. Properties are automatically added into the metadata store when the crawler crawling content. Thus, the number of crawled properties can be added up quickly. This crawled property list is shared across all content sources in SSP.

 Before MOSS 2007, SharePoint only operates with Crawled property. However, in reality, only a small subset of the crawled property is needed for searching and for displaying the search results. And you don’t have control of the name of the crawled properties. Crawler will name them itself by some internal naming rules. Thus, they can have lengthy names that would make them hard to reference in code or other places.

Managed property is a new concept introduced in MOSS 2007. They are created by SSP administrators and provide an easier and more consistent experience for managing and using the subset of crawled properties that matters to the business. And you can also map several crawled properties to the same managed property. This makes it possible to join different crawled properties that are semantically the same to a single managed property.

 Here are some examples of managed properties that are available in MOSS 2007,

  • AssignedTo
  • Author
  • ContentType
  • FileExtension
  • SiteTitle
  • etc..

Check the blog to see how you can create your own managed property. 

The use cases for managed properties:

  • Construct Search Query : The most straight forward way is to execute searches from the search box using managed properties. We can enter them directly into the search box. For example, I want to find all the documents written by me, I would execute a search in my MOSS site using the following text:”Author:Chris”
  • Customize Search Results: We are all familiar with OOTB search results that displaying the metadata, like title, author, URL etc. Actually, we can customized the search results to display any available metadata as long as the metadata is a managed property in the index
  • Expose for advanced search: The Advanced search page has property picker that can be populated managed properties. You can add managed properties to the property picker in the advanced search page by modifying the XML attaché to the Advanced Search Box for the properties. Here is a MSDN Visual How-to shows you step by step how to do that. Check it out!
  • Use in Search scope: You can use managed property to configure search scope. Here is a good blog of how to do it. 
  •  Custom relevancy ranking: Managed properties play a role within the ranking of the results.The managedproperty class exposes the Weight property which can be changed programmatically to influence the relevance ranking

Posted in Search | Tagged: | 3 Comments »

Search Query TotalRowsExactMinimum property

Posted by chrissyz on February 13, 2009

When we are coding against MOSS Search API, we use totalRows property to get the total search results from the search engine. However, why sometimes we found the totalRows number returned is not accurate. Why did that happen? And how could we fix that?

The reason for that is totalRows only give you an estimate result. It is very expensive to get a specific number due to the security trimming and search algorithms logic in SharePoint search. The trick is this property ‘TotalRowsExactMinimum’. It instructs the SharePoint search engine as to how accurate the TotalRows should be. It tells SharePoint the number of minimum hits that must be included in the result. The default value of it is 50. It is used in conjunction with totalRows. If you have more than 50 search results and you use TotalRows property with no modification of TotalRowsExactMinimum property, it will stop displaying further pages in the search results even though there are more records. Once you set the ‘TotalRowsExactMinimum’ more than the total results you estimated to return, Search engine will return the accurate total number. However, the higher you set ‘TotalRowsExactMinimum’, the more negative impact you will have on performance. Here is a very good blog gives you details explanation of how ‘TotalRowsExactMinimum” works.

Posted in Search | Tagged: | Leave a Comment »

Ghosted and unghosted in SharePoint

Posted by chrissyz on February 9, 2009

One of the most common problems we encountered in SharePoint solution deployment is: after we deployed the wsp file successfully to the farm, we found some pages got 404 page not found error, or they didn’t reflect the latest change or fix we put in our .wsp file. Why?

 OK, the most possible reason for that is the good old ghosting issue. Before we dive any further, let’s explain some fundamental concepts here.

Unghosted == customized. It happens when you customized a WSS/MOSS2007 site in SharePoint designer, or you add custom field to Doc Library or you customized a site through UI and save it as a site template and then create sites using that template. When you unghost a page, a customized version of it was saved in the content database. So next time when you request for the page, SPVirtualPathProvide will tell SharePoint that the page has been customized. Then SharePoint will retrieve the customized version of the page from the content database.

Ghosted= uncustomized. It means the site definition pages have not been customized and the pages in your site definition run directly from the file systems on your web server. When a page instance is initially provisioned from a page template, WSS doesn’t need to store a copy of it in the content database because WSS can load the page template from the file system of the web server and use it to progress any request for an uncustomized page instance. Therefore, when you request for a ghosted page, SharePoint uses a page template loaded into memory from the file system of the WFE. It eliminated the need to transfer the content of a page definition file from the SQL server computer with content database to the WFE.

Now, come to our initial problem. Woops, before that, I just need to make sure everyone understand the concept of solution deployment as well. What is solution deployment? Ok, you packaged the whole solution from Visual studio and produce a .wsp file. Then you deploy the .wsp file to your farm using STSADM command. A .wsp file is actually a .cab file. It contains all your files (master pages, page layouts, css, images, features, etc), your assemblies (web parts, web controls, event handlers, etc) and xml files that tell where to drop these things in the WFE. Will it drop anything into the content database? Absolute not. We should all bear in mind that SharePoint solution deployment only have impact on File Systems in WFE. It won’t touch SharePoint content database and configuration database. OK now we can finally go back to our original question. When you perform another solution deployment after your initial deployment (doesn’t matter it is re-tract and re-deployment or upgrade), you put all your new files/ fix into the file system. But if you have any unghosted (customized) Page, they still go through the content database to grab the customized version instead of going to the file system to grab the new version your just deployed.

So aha, now we know the problem. How we gonna fix it? The answer is simple, re-ghost it, changing the page from customized to un-customized.

There are two ways of doing it. One is through SharePoint UI

1. Go to Site Actions ->Site Settings ->Reset to Site definition


2. Click Reset to site definition, and enter the page URL. Or you can choose to reset all the pages in the particular site to site definition.


The other way is through SharePoint Designer 2007. It will also help you to track all the unghosted pages before and after deployment. Microsoft has two articles explaining how to track the unghosted pages and how to reset them from SharePoint designer I recommend checking if you have any unghosted pages in your current site before and after you deploy your new solution.

Posted in Deployment | Tagged: | 2 Comments »