So what I will do is cross post links to the articles I’m writing on the company blog.

The first one is ‘SharePoint Search results not visible for users‘.

I hope you find this post helpful.

Microsoft have just released a hotfix to search DCOM permission post SP1 problem which I wrote about previously.

The hotfix can be found here. http://support.microsoft.com/kb/953137

I’ve just stumbled across a problem post MOSS 2007 SP1.

After applying SP1 to an existing installation and running a full catastrophic backup it fails on the shared search index item with an error regarding UnauthorizedAccessException.  The environment I am experiencing this in is a single virtual machine that is a domain controller, SQL2005 SP2, and multiple domain service accounts for the farm service account, search service, etc.

The error can be seen in the spbackup.log as:-

[5/8/2008 2:59:48 AM]: Error: Object Shared Search Index failed in event OnPrepareBackup. For more information, see the error log located in the backup directory.
    UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.
[5/8/2008 2:59:48 AM]: Debug:    at Microsoft.Office.Server.Search.Administration.SearchApi.RunOnServer[T](CodeToRun`1 remoteCode, CodeToRun`1 localCode, Boolean useCurrentSecurityContext, Int32 versionIn)
   at Microsoft.Office.Server.Search.Administration.SearchApi..ctor(WellKnownSearchCatalogs catalog, SearchSharedApplication application)
   at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.get_SearchApi()
   at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.Microsoft.SharePoint.Administration.Backup.IBackupRestore.OnPrepareBackup(Object sender, SPBackupInformation args)
   at Microsoft.SharePoint.Administration.Backup.SPBackup.RunPrepareBackup(SPBackupRestoreObject node)

It looks like SP1 is blasting away the permissions on the OSearch DCOM application.

I’d like to thank Jason Medero with his post and /dev/arthur for his post on this issue which lead me to confirm what they had found.

While their posts talk about manually editing the DCOM launch permissions for the OSearch application, Ali Mazaheri on his article has a far simpler solution.

Just run the following command:

stsadm -o osearch -action start

After you run this command you can browse to the permissions of the the OSearch DCOM application and confirm that the sharepoint service accounts and the WSS_ADMIN_WPG and WSS_WPG groups have been granted local launch and local activation permissions.

Note that while I found this error while trying to run a backup, my application event log was full of errors similar to what Ali describes in his article. This just demonstrates that if you have errors in your event log after applying a patch or service pack, something has gone wrong and you need to investigate it.

Adobe Labs have a pre-release of how to support Adobe Reader v8.1 ifilter on 64bit sharepoint.

I’ll admit that I haven’t tested this yet and it involves a 64bit ‘thunking’ layer. In the past I have seen some instructions on to use this technique to ‘hack’ together a custom 32bit ifilter handler onto a 64bit system.

The main significance of this is that currently the only cleanest way of supporting pdf indexing on sharepoint 64bit platforms is to use foxit pdf ifilter. However this is commercial software that is priced based on the number of CPU cores. (As at 25JAN2008 this was “License cost for each server with up to two CPU cores is $329.99. Each additional CPU core costs $129.99.”) Now with most production servers these days being dual quad core processors (ie 8 processing cores) This would be US$1109.93 for each production server. Congrats does go to foxit for seeing a large hole left in the market by Adobe being so slow to support the 64bit platform and providing a solution.

The other comment worth making is that the foxit 64bit ifilter may be coded natively in 64bit but I’m not sure of this. Whereas the Adobe solution is taking the existing 32bit ifilter in wrapping it into 64bit which does involve a processing cost overhead. If you had a large index with lots pdf documents then going for a native pdf ifilter could bring a significant performance difference.

I spotted another bizarre default behaviour in sharepoint yesterday.

If you have a publishing site and you apply individual permissions to pages (also known as fine grained permissions), which is not beyond the realm of possibility on an intranet or similar website by default these pages will not be included in the search results.

Go to the site settings for the site and from the ‘Site Administration’ column select ‘Search Visibility’. You will notice that aspx pages by default are not indexed if they have fine grained permissions.

This just seems to be a bizarre default setting. Given that search results are security trimmed why is the default behaviour not to index all aspx pages?

Anyhow change the setting to ‘Always index all aspx pages on this site’ and they will be indexed.

The nice thing on the screen above is that the sentence above the radio buttons will indicate if your site has fine grained permissions.

Some recent updates to the technet sharepoint doco were pointed out to me yesterday that listed msg indexing support as being available out of the box.
This is the relevant page:-

File types and IFilter reference (Office SharePoint Server)
URL: http://technet2.microsoft.com/Office/en-us/library/09357d8e-37b9-4e96-b8fd-f17b990d010a1033.mspx

So this doc basically states that msg filters are inbuilt. So I do a search of some content that is in the body of a .msg file and no results are returned.

Now I’ve been down this path before with the foxit pdf ifilters so I’m pretty sure that it is a problem with missing values in the registry. I also note at the bottom of the above reference page is a link to an article on search onenote 2007 files. This document provides hints as to the missing registry keys.

Install and register the OneNote IFilter (Office SharePoint Server 2007)
URL: http://technet2.microsoft.com/Office/en-us/library/2e715e42-c09b-4b4f-a082-b19e1cad96031033.mspx

Crank up regedit check that the :-

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.msg keys exist.
(They should do, all my installs have this by default)

The following key is the one that is missing.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\Filters\.msg]
“Extension”=”msg”
“FileTypeBucket”=dword:00000001
“MimeTypes”=”application/msoutlook”

[Edit 08JUL2010 - changed MimeTypes key above as per testing from others. Thanks to devparts comment below]

Now, I have taken a guess on the mimetype for outlook. I can find no mimetypes for .msg files in the registries on my servers and my workstations. A web search yielded 3 possibilities, “application/vnd.ms-outlook”, “application/x-msg” & “application/msoutlook” 

So the next thing was to restart the office search service, and iisreset. I think reset all crawled content (purge the index). Then I ran a full crawl.

Fortunately I got lucky on the mimetype and the index successfully crawled the content of the email! Now for the caveats. I’ve only done basic testing. I haven’t checked if the msg ifilter will pull an attachment (eg word doc) and index that as well. Also I haven’t checked this with Microsoft, though I think it is worthy of a bug report (at least in the doco).

Also thanks to Mutaz from MCS for his initial guidance on pointing me in the right direction this.

Mark Harrison originally posted some reg hacking on how to this. You can also do it from the front end of IE7.

For example if you want to add a people search from your Sharepoint 2007 corporate portal. Browse to the portal and run a people search with the criteria of ‘TEST’. Then copy the URL of the results page. Next click on the search drop down in IE and select ‘Find more providers..’

On this page copy in the URL of the results page and give it some display name ’eg Corporate People Search’.

The power of this is that your users can now directly launch and people search from IE7 without having to first browsing to the sharepoint site.

Now combine this with the registry hack that Mark Harrison posted you can now roll this out to all your users.

Basically the plan will recreate the indexes without the ‘allow duplicate keys’ ticked.

Microsoft have also posted a KB on this.
http://support.microsoft.com/default.aspx/kb/930887/en-us