Many people dont know but in the advanced search box there is a couple more options than simply Equals or Does Not Equal.

Equals/Does not Equal option in advanced search box

Another option that you can specify is the Contains or Does Not Contain option which used to be there by default by for some reason is disabled with the infrastructure update.
With this option the user has the option of getting some more leverage in their results when using advanced search, always a good thing!

To do this simply go to the  Properties section of the Advanced Search Box configuration, click on the Builder dialog box as seen below and then in the Properties xml add the following:

<Option Name=”AllowOpContains” Value=”True”/>

See below for the builder area:

Advanced Search Box builder option

Click on OK and now you should see the advanced search box has the Contains and Does Not Contain option.

Contains

Sometimes TechNet can be a great source of information and they have done a particulary good job of the SharePoint search series.

Have a look at Plan Search Deployment on TechNet for some really useful information including how to crawl content, security configuration and security for Federation.

If you like videos (because you are kinda lazy like me!) then the Training Videos for Enterprise Search is an awesome resource for some videos from Microsoft.

Please see this post at my new blog located at: http://www.sharepointanalysthq.com/2010/06/06/sharepoint-federated-search-connector-examples/

Enjoy!

Below is the search presentation that  Matt and I did for the Vancouver SharePoint Users Group.

Although the presentation didn’t go quite as planned (no internet access could be established hence the main part of the presentation, a demonstration on search, didn’t happen:( ) I hope that people got some value out of it regardless.

It was a great experience and I really thank the organizers of the event of allowing Matt and I to do a presentation, hopefully they will have us back!

The main points that I wanted to get across in the presentation where as follows:

• If you are running WSS 3.0 then you should be upgrading to the free Search Server Express 2008
• Overview on some of the infrastructure elements of search including the index server, query server, databases and web front ends
• How search federation can be used
• Various out of the box configuration for search
• How the Federated Search Web Part can be easily turned into an RSS Web Part
• How the Search Core Results Web Part can be used as a Content Query Web Part for WSS
• Few other tips and tricks

The presentation can be found here: Search Presentation for Vancouver SharePoint Users Group

Overview

Creating managed properties (post to come, stay tuned) can be rather cumbersome work, especially if you are adding many of them.
There is, however, a way that you can by pass a lot of the work by getting SharePoint to create  a managed property each time it finds a new crawled property.

• Go to the Shared Services Provider that is hosting the search server (by default it will be called ‘SharedServices1′
• Then go to Search Settings and then Metadata Properties
• Click on Crawled Properties then the SharePoint category and finally Edit Category and you should be presented with the screen below.

Crawled Property Configuration Screen

In order to create Managed Properties automatically simply check the box “Automatically genereated a new managed property for each crawled property in this category” and away you go.

Caveat

Unfortunately the names that SharePoint creates for the managed properties are not all that friendly.
SharePoint crawled properties are prefixed with an “ows_” and the auto generated managed property is prefixed with “ows”. For example, if a user creates a new column in a document library called “OrderStatus” then the crawled property will be “ows_OrderStatus” and the managed property will be “owsOrderStatus”.

Things get even worse if the crawled property has a space in it. So if you have a column called “Order Status” (with a space), then the corressponding crawled property will be “ows_Order_x0020_Status” and the managed property will be assigned the name “owsOrderx0020Status” – not that great at all. But you can always change the name of the managed property so its not a complete waste of time…

Problem

When searching using SharePoint you get a bunch of results back when selecting the “All Sites” option which is all good.

All Sites scope

But then when you try to select a contextual search option, such as “This Site” or “This List” you don’t get any results.

Possible Solutions

So the reason that this occurs is that the contextual scopes don’t go a custom results page that you can define but rather to the OSSSearchResults.aspx page. Also these two scopes are actually serviced by the Windows SharePoint Services search engine.

So some possible solutions and causes are:

You have a host header defined to use http and https on the same web site

This usually occurs when people try to secure a site incorrectly. Instead of extending the web application out and then assigning a url and certificate they simply put a host header on and away they go.

Things work fine until you use these contextual search scopes.. then things go awry.
For more information please see kb927919

Portal Site Connection Property has been changed

In some occasions if you change the Portal Site Connection property then you stop being able to search SharePoint content, WSS content is still indexed.
For more information please see kb826797

If you have any other causes then please let me know but a good reference is the following thread on technet that has a load of information regarding this issue.

I had a situation where I couldn’t crawl a site at work. Everything seemed fine, all the permissions were there but still I could work it out and it was starting to drive me crazy.

There are a couple of things to check if you do find yourself in this situation:

Check Default Content Access Account

Default Content Access account

First thing would be to check that the default access account has access to the Site Collection or the Web Application that you are trying to index. The Default Content Access Account is in SSP->Search Administration->Default Content Access Account.

Give that a try, if no luck then continue on..

Check Crawl Rules

Crawl Rules options page

With the new infrastructure upgrade you can also now specify authentication within a crawl rule which can be really,really handy especially for different types of authentication such as Form Credentials, Cookies and Certificates as seen above, but it can also override your default content access account permissions so make sure that there isn’t a crawl rule that matches your URL and overrides the default content access account to something that doesn’t have permission to the site, site collection or web application.

Check Policy for Web Application

Policy for Web Application

Another thing to check might be the Policy for Web Application settings to ensure that the Search Crawling account has access to that as well, if not either add in the account that is the default access account or another account that you are using to crawl

If all else fails…

So if this is all set up and you still are getting an ‘Access Denied’ error which is driving you crazy try looking at KB896861 which is what I needed to do. Essentially the issue occurs because of the loopback settings on a server. I actually had to disable the loopback altogether (method 2 in the article) to get the damn thing to crawl.

Hopefully this helps you in your time of need!

Related Links

• http://sharepoint-sezai-moss-2007.blogspot.com/2009/04/cant-crawl-sites-cant-access-sites-on.html

• http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=107

• http://blogs.blackmarble.co.uk/blogs/adawson/archive/2009/03/26/access-is-denied-when-crawling-content-on-moss-2007-hosted-on-windows-server-2008.aspx

In order to play around with search results, for instance making changes to the XLS with SharePoint Designer, you need to have the raw search results XML available.

To get this its quite easy, simply paste the following into the XSL Editor property of a Search Core Results web part:

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” >
<xsl:output method=”xml” version=”1.0″ encoding=”UTF-8″ indent=”yes” />
<xsl:template match=”/”>
<xmp><xsl:copy-of select=”*”/></xmp>
</xsl:template>
</xsl:stylesheet>

Just follow the steps below to make it happen:

1. Edit search results page, modify “Search Core Results” webpart
2. Click on XSL Editor button under “Data View Properties”.
3. Replace the XSL with above XSL snippet.
4. Save the page.
5. Re-run the query
6. Copy the generated XML and paste into a file called SearchResults.xml which can then be imported into SharePoint through SharePoint Designer and then the resulting XLS altered.

One of the things that I always tell people when talking about search is to make sure that you expose your custom properties for search.
By custom properties I am referring to any of the following:

• Fields in lists (particularly fields that have been created specifically for the organization)
• Custom metadata attached to documents
• Custom content types

If you look in this blog you see the steps necessary to take crawled properties and map them to managed properties, thereby exposing them to be used in search.
What you can do by creating Managed Properties is:

• Expose them for advanced search: Allow users to specify these properties as parameters to searches.
• Create Scopes: Create scopes from these managed properties
• Display in Search Results: Display in results of searches
• Alter relevancy ranking: Change the weighting of how much the property influences end results.

Im going to be talking a lot about Managed Properties so stay tuned!