Office Server 2007 Ramblings

Some useful links that help guide a configuration of SharePoint when using Kerberos...

How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication

How to use SPNs when you configure Web applications that are hosted on IIS 6.0

How to configure SQL Server 2005 Analysis Services to use Kerberos authentication

As yet I have not tested this, but it sounds good.  especially useful for large lookups, which in standard InfoPath are pretty painfully slow due to the massive amount of code that is produced by InfoPath Forms Services.  This method would mean that you could write your own code which is much more efficient.  Although to be honest if I was faced with this kind of thing I would be more likely to use ASP.NET forms instead of InfoPath.

see: Serve's Sharepoint blog post

Looking at Mark Harrison's blog, he points out that version 2 of the MOSS faceted search is available.

Not having seen this tool before I thought I would have a look.  It seems pretty useful, but probably I need to test a lot more with many documents before I can really tell.  But it seems to add an element of guided discovery/findability to MOSS search which is quite neat; especially as it is open source on codeplex.

The link to MOSS Faceted Search is here and a demo is here.  The faceted search is made up of 2 web parts.

If anyone has any opinions on this, I would love to hear from you, please add comments of your experiences/impressions of this tool.

There seem to be some people in the big world of blogging that have posted that the correct way to get Outlook messages to be correctly crawled and made searchable within Sharepoint is to edit the registry.

They are now out of date, as Microsoft have released a Filter Pack that provides this functionality, albeit undocumented.

The 3 blogs I have found are as follows :
Gavin Adams
Tom Vandaale
Lirliron

If you follow their advise you will firstly be taking a risk by altering your registry (always back it up before making any changes) and secondly creating a solution that does not work fully.  I tried all 3 of the slightly altered solutions, none of which were able to produce the results I required, which was to index & search .doc attachments, worked ok for .docx.  Also it is worth noting that it did not prefix the summary/extract with the attachment's filename, so the context of the result was lost.

Now the most recent method it is to install Microsoft's Filter Pack which provides all the correct iFilters for Microsoft Search products to use; including Sharepoint.  I performed a restart of the server after installation and then a full crawl and it produces very nice results for all the emails and attachments that I need.

I recommend that you don't fiddle with the registry unless there is no other way, admittedly this is not documented anywhere and it was more by luck that I discovered this than anything else.  So credit to Gavin, Tom and Lirliron for what they discovered, but a much more complete & safe solution is to download the filter pack from Microsoft, the link again is here.

Also, just so that you are aware, if you already have the PDF iFilter installed and expect this to mean that you can index and search pdf attachments, you will be disappointed as it does not work.

Recently I have been customising MOSS search results pages using XSLT and am quite pleased with the results ;-). However, one requirement from our customer was to break up the document url into it's component parts and provide links to site and library and folder separately.

In essence this is quite easy to do using Javascript splits and slices etc....

However once I click on the link for the folder, it does successfully take me to the folder but with one rather annoying problem..... as follows....

If the tree view is being displayed on the page then it will not expand the library to show the folders and highlight the chosen folder IF the document that was found was a PDF.  The reason for this seems to be that the PDF iFilter always returns lower case urls, whereas the iFilters built into MOSS provide URLs with upper and lower case as they were originally typed into the system.  e.g. http://moss/Docs/library/folder works fine but http://moss/docs/library/folder does not

My solution to this is to always ensure that internal names for sites and document libraries are always lower case. 

This can be seen as either a Microsoft bug or an Adobe bug... 

• MS because the tree view webpart does not work with any case URLs (even though the url is converted to uppercase in the browser, clearly behind the scenes the webpart is using the request passed in which is lower case; frankly all code and data for hierarchies in my mind should be stored in lower case for internal data as this would mean that these kind of problems would never occur).
• Adobe because they did not spot this MS issue during the testing of their iFilter - understandable though as default results pages do not provide a URL to anything other than the actual document and therefore this issue would not arise

This bug is annoying but as long as system designers are aware of this issue then it can be avoided.  I recommend always avoiding this bug by ensuring that all of your internal names for site collections, sites, document libraries and lists are lower case.  The titles(display names) can be any case.