All posts tagged SharePoint 2007

SharePoint Crawl - Content Processing - Indexing

SharePoint crawl types: Full, Incremental, Continuous

Crawling is the process of gathering the content for search. To retrieve information, the crawl component connects to the content sources by using the proper out-of-the-box or custom connectors. After retrieving the content, the Crawl Component passes crawled items to the Content Processing Component.
There are three main types of SharePoint crawl: Full Crawl, Incremental Crawl and Continuous Crawl. Read more…

Just published: Integrating document management systems into Microsoft SharePoint 2007

When choosing integration, first ask yourself what you’ll need to integrate. Documents are more than simple files. Their file format (.doxc, .txt, .pdf, etc.), content and metadata are also important. Decent DMS software handles those parts and makes them available to end users. Also determine what type of integration will best meet your business needs.
The full article can be found here.

Searching your SharePoint sites with Internet Explorer 8

IE8 has a very customizable Search Toolbar. Of course, the default search engine used by it is the Live Search, but you can manage the search providers in a very easy way. Just click on the Find More Providers menu:
On that page you can find the most popular search providers like Google, Live Search, AOL, Yahoo!, etc. You can add them to your search toolbar with a simple click:
Moreover, on the right side of the screen you can find a very interesting section: Create Your Own. Here you are, that’s your friend if you want to add your SharePoint search page to the IE toolbar! For example, if your SharePoint search’s result URL is http://intranet/search/Pages/results.aspx, you have to enter this to the first text box: http://intranet/search/Pages/results.aspx?k=TEST (the ‘k’ parameter passes the search expression to the results page). The second text box have to be filled with the name of this search provider as you want to see in IE8:
Here you are, now you’re able to use your SharePoint search site directly from your browser!


MOSS Search: Custom Search pages and Property mappings

After a basic introduction let’s see, how you can build a custom search page, and Property mappings. This post will built on traditional method without Infrastructure Updates, but in the next part we’ll see the Updates details as well.

Step 0: Set the basic search

See my previous post and practice the details described there.

Step 1: Create lists and libraries

In my example, we’ll use the following scenario: the site collection contains several lists and document libraries, that are responsibe for question-type items, and answer-type items. Of course, these items are connected into question-answers pairs. The main goal is to build a custom “Search for Questions and Answers” (“Kérdések és Válaszok keresése”) page.
So, what do we have to do being able to build this page? First of all, the “backend”-structure: content types and lists, with indexed columns. After that we nees property mappings. Finally: build this Search page and customize some XSLTs. Let’s see what does it mean.

Step 2: Search scope settings

Basically we need the basic content types: Question and Answers. In the lists we use them instead of Item, so we can define custom search scopes based on them: One scope is for Questions, and the other is for Answers. Oops, but by default we cannot use Content Type in the scopes. Don’t worry, just go to the Search settings on Shared Services Administration page, and open Metadata Property Mappings. Here you can find the “Content Type” property – open it, and check the “Allow this property to be used in scopes” box in. Then you can use it in your scopes:
Well, currently we have lists with our content types, and scopes that can be used for searching Questions and Answers. So we can use them on my custom search page as well (see Step 4).

Step 3: Set the Property mapping

Of course, our content types contains custom fields as well. For example Program, Document Type, Construction, Keyword, etc. These fields have to be able to search on our custom page, so we should set them as indexed columns in every related list.
After that, we have to set these fields as searchable properties. Go to the Metadata Propery Mappings page again, and choose New Managed Property option. Add a name to this mapped property (for example, Program), and optionally a description. Select the type (Text), and click Add Mappings button – here you can search for the required field, in this example Program:
OK, let’s map it! We’re ready to build the full Search page now.

Step 4: Create custom Search page

First of all, create a custom advanced search page: content type choosing and property searching.
For using Question and Answer content types, you have to define a new scope display group. Go to your site collection’s administration page, and shoose Search Scopes option. Here you can define a new Display Group (Questions and Answers – Kérdések és Válaszok), and add your content types to it.
After that, go back to your custom search page, and modify the properties of the Advanced Search Box, and change the Display Group to Questions and Answers:
The result: on your page you can choose your content types instead of the default ones.
OK, we’re almost ready. Almost. We have to set the property search as well. We have indexed fields and mapped properties, so let’s edit the Properties’ XSLT. Search the PropertyDefs tag, and add your properties one by one as PropertyDef nodes:
    <PropertyDef Name="Program" DataType="text" DisplayName="Program" />
    <PropertyDef Name="DocumentType" DataType="text" DisplayName="Dokumentumtípus" />
    <PropertyDef Name="Construction" DataType="text" DisplayName="Konstrukció" />
After PropertyDefs, you can find a node named ResultTypes. In this you can define what kind of properties do you want to use on your search page:
    <ResultType DisplayName="Minden eredmény" Name="default">
        <PropertyRef Name="Program" />
        <PropertyRef Name="Dokumentumtípus"/>
        <PropertyRef Name="Konstrukció" />
Finally save the Advanced Search Box web part, and let’s try your brand new Search Page. Persuasive, isn’t it?…


MOSS Search – Base search functions

The MOSS Search Engine gives a lot of really powerful features for us. Let’s see a few options, how can we set very useful search pages. First of all, we can define several types of content sources:
  • SharePoint site
  • web site (everywhere in the world)
  • File Share
  • Exchange Public Folder
  • Business Data
For example, if you want to index my blog site in SharePoint, just define a Web site type content source, with URL of For example, with a hourly update scheduling you’ll be notified about recent changes in every hour.
After that, we have to set the search scopes, to make usable this content source. This scope can be based several rules: the most important ones are Property Query (see below), and the Content Source. In this case, we’ll use Content Source option, and select the web site just created (AghyBlog).
After that, we can start to use this scope on our sites. Let’s go!
First of all, we can add it to the Search box. Just go to the Site Collection administration, select “Search Scopes”. Here you can find the Search box settings, and can add the new scope. The result is the following:
After that you’re able to use the new scope on your sites.


Build fix queries in a dynamic way

By default, we are able to display query results in our own page with the Search Core Results web part .  Basically the search query can be built in two ways:
  • UserQuery: to get a query from current user we need a Search Box or Advanced Search Box web part. After typing the query, both of these webparts give the query to the URL QueryString, and the Search Core Results webpart show the results according to these parameters. For example: http://mymoss/sites/customsearch/default.aspx?k=42 means the user typed the query “42”.
  • FixedQuery: If we want to display results from a fix query, without user interaction, we can set the webpart parameter “FixedQuery” of Search Core Results. For exaple we can display all of presentations with extension ppt or pptx.
Unfortunately we don’t have possibilities to build FIxedQuery dinamically, without programming. We can create a new webpart which inherits from Search Core Results, and override the FixedQuery, but it needs development efforts.
It would be nice to do this when e.g. we want to know who has birthday today, or what documents are checked out to the current user. These are very simple questions, can be typical queries with other scenarios as well.
Dynamic query
In my example I will build the query by the current URL. I’d like to know what contents link this URL in an other site collection.
Our search settings are scopes are ready to use, we need just build the query and display the results.
Let’s go! On your current site create a Search Core Results webpart, but DON’T set it to FixedQuery! Here is the surprise: I’m going to use the UserQuery mode, without search boksz or any input field. If we can set the query string parameters in the URL (see above), the results are shown in the Results webpart (42). OK, but how can we set this “k” parameter automatically, without user input and programming?
The first thing we can imagine: insert the parameter into the links referred to this site. The idea is good, but we have two problems with it:
  • It’s definitely not too nice if we create URL with long parameters, that could be calculated automatically.
  • We can insert the parameter into our own links, but inside the SharePoint it won’be work. For example we use the breadcrumb navigation, the parameters won’t be inserted to end of our site’s URL.
Well, what can we do? We could insert the parameter’s creation into the given site, but without user input. The most optimal solution would be if we can build the creation into the Search Core Results itself.
The solution: edit the XSL behind the Search Core Result webpart! In this XSL, we can find the parameters of displaying, and the text rendered if the results set is empty (“No results matching your search were found.”), or if the parameter is empty or missing. We can profit from it!
Look for the following part of the XSL:
<xsl:template name="dvt_1.noKeyword">   <span class="srch-description">      <xsl:choose>         <xsl:when test="$IsFixedQuery">Please set the 'Fixed Query' property for the webpart.</xsl:when>         <xsl:otherwise>Enter one or more words to search for in the search box.</xsl:otherwise>      </xsl:choose>   </span></xsl:template>
This part of XSL is responsible for handling empty parameters. The ‘otherwise’ tag handles FixedQuery – but it doesn’t fit to our needs, so let’s see the first, xsl:when branch. If we don’t have any query (yet), so the parameter ‘k’ is missing from the Query String, the following tag will be active:
<xsl:otherwise>Enter one or more words to search for in the search box.</xsl:otherwise>
Well, how can we persuade the WebPart to fill in parameter ‘k’ automatically instead of display this message? Tadadaaa! Javascript! We’re building the query in Javascript, build the full URL with requeires QueryString, and redirect the current page to this one. After redirection the XSL will go to an other tag, because the parameter ‘k’ won’t be empty!
<xsl:otherwise>    <script type="text/javascript">       var kparam = location.pathname.substring(location.pathname.indexOf("site_"), location.pathname.indexOf("/Default.aspx"));       window.navigate(location.pathname + "?k=" + kparam);    </script> </xsl:otherwise>
Fortunately, we can do almost everything on client side by Javascript, so we can build our query by many other parameters. Very nice, isn’t it?