Christopher Even on SharePoint Search

I have used the MS Exchange content source to crawl both public folders and private mailboxes and folders.

Here is what I found out: It works great accept the search results are security constrained to the crawling account. Only the account that was used to crawl the folders has permissions to search for those items. This means that you have to make your public folders be truly public by allowing anonymous access which means a security hole on your exchange server to get this working. It also does not crawl more than one sub folder deep. So if you have a multilevel folder structure you will have to add them one by one to the sources. NOTE: there has been a patch released that you can get from MS Support which I didn't try and may address some of these issues.

But the Official MS solution for including emails in your searches is to run Windows Desktop search and use that as your search interface and can include in SharePoint Search results in the same interface.

Neither of these approaches were going to work in reality for our customers and instead of turning to external search engines like X1, Fast or Autonomy we chose to develop our own solution to the problem. I usually don't talk about my own products in my blog, but I think there is such a need for this that I will do this ahead of our formal announcement.

We are now in beta testing of a SharePoint search connector for exchange http://www.sharepointworks.com/pages/escexchange.aspx which basically allows the inclusion of all your private mailbox content into your SharePoint index ( up to the 50 Million item limit) and provides a true Enterprise Search experience. Security is fully adhered to and you can configure master accounts (for discovery purposes) that have search access to all mailboxes if you choose. Besides its use as a replacement for Desktop search, it also provides very useful help desk functionality to search history across multiple mailboxes (thanks Martin for the idea). We took a very unique approach to crawling the Exchange content that basically provides a buffer between SharePoint and the Exchange servers to minimize impact on production systems and to allow more frequent updates to the search index (even with 50 million emails, incremental's can be done hourly). Contact me for more information or if you would like to participate in trials of this product.

You can find some great resources about search relevancy in our Big Resource List

http://sharepointsearch.com/pages/bigresourcelist.aspx?category=&focus=Relevancy&class=&member=

In particular check out this article

Evaluating and Customizing Search Relevance

It is written by Dmitriy Meyerzon, Avi Schmueli and Jo-Anne West

- I have met Dmitriy and Avi at a MS Search workshop and they are THE MS Search guys to listen to.

So after you have read what they say about improving Relevancy, download this free tool I just uploaded to allow you to manipulate the weights and parameters they talk about.

http://sharepointsearch.com/cs/files/folders/searchtools/entry2527.aspx

Addendum:

Read these forum discussion. Very enlightening about search relevancy. http://sharepointsearch.com/cs/forums/t/2397.aspx , http://sharepointsearch.com/cs/forums/t/2546.aspx

- Cheers.

Here is the latest pricing from Microsoft http://office.microsoft.com/en-us/sharepointserver/FX102176831033.aspx

In terms of Search functionality, without the Enterprise License you will be forced to write custom protocol handlers ( see previous blog posts), custom web parts and/or the SharePoint designer to integrate external LOB applications into SharePoint.

The BDC provides a means of integrating your applications into every part of SharePoint including Search. The benefit of using the BDC for Search is that you have actionable results right off the bat as your search links will go to the profile of that entity it returns. Microsoft has also recently released a BDC editor tool in their latest SDK ( buggy though) and there is also the BDCMetaMan tool to help with your definitions.

There are of course other great reasons for choosing the Enterprise Edition besides the BDC ( Forms Server, Excel Engine ..), but it is not a requirement for Enterprise Search.

So how do you go about integrating LOB applications into SharePoint and Search then without the BDC? For the interface side many different options are available: Custom Web Parts, Smart Part Controls, iframes to external web apps, or my favorite; the SharePoint Designer. The SP Designer is a very powerful tool for creating integrations with databases, web services, or most any LOB data source and I have yet to find a scenario that can't be tackled (see http://sharepointsearch.com/pages/bigresourcelist.aspx for what I mean). For the Search part of the integration you can write your own protocol handler (see http://sharepointsearch.com/cs/blogs/notorioustech/archive/2007/06/19/contentenumerator-cs-for-stored-procedure-sample.aspx) or license a 3rd party connector from a vendor.(see http://sharepointsearch.com/pages/products.aspx)  

As part of my previous post on how to make search results actionable I mentioned using Citrix as a potential choice for interacting with search results. I would like to expand on that further. There is some information regarding the 2003 version of Citrix WISP, but nothing on the 2007 version at citrix.com that I could find. But, I assure you it is released and working.

WISP stands for Web Interface for SharePoint and it provides two main features:

• Application enumeration and publishing - Enumerates applications and displays the application icons inside the Web Part for users. Launches applications from the Web Part using pass-through authentication, providing single-click launching.
• Content Redirection - Access documents and content available through the portal using applications hosted on Presentation Server. The system intelligently determines which application needs to be launched on Presentation Server or on the client’s desktop to open the document or content requested by the end user.

What this means is you can turn your SharePoint portal into a virtual desktop for your employees. Because Citrix allows you to run remote desktop applications over the web, you can configure all your employees applications to be launched directly from the SharePoint portal. If you are good with XSLT you can even provide your users with a "START" menu system just like on the Vista desktop.

The aspect of WISP that I found most useful though is the ability to do content redirection from portal links. This means that when you choose to edit a document from a document library WISP will launch whichever remote application is configured for that file type, like MS Word or Excel. The way it works is that the remote application actually gets passed in the portals path to the document, this means that the remote app must be able to use that path to work with the document. If for some reason your Citrix application server doesn't have access to the portal itself and the subsequent doc library then it can't open the document.

Extending WISP beyond SharePoint Content: As stated above, WISP works with content that resides in the portal but what if you want to use WISP to launch an application that works off of database content, like WorkSite for instance. Since the file to open is actually a database record you have to get resourceful. You will need to trick WISP into calling a new Citrix launcher application that you create to proxy the launch information to your remote LOB application. I can tell you that it is doable and works great for my clients, and saves on investing in SharePoint integrations from every vendor that your client uses. Instead you can use the BDC to search and display summary information and use the actual client applications for the rest.