Share via

Co-existence of 32 bit and 64 bit IFilter binaries in MS Search Products.

  • Article

Over the last few months we've seen numerous questions from consultants and customers alike on:

   1. Why are certain IFilter binaries not available in BOTH 32 bit and 64 bit incarnations? 95% of the questions in this category pointed to the unavailability of 64 bit Adobe IFilter.

   2. What is Microsoft's strategy for dealing when 32 bit binaries from within 64 bit search processes?

   3. Is there a technical workaround I can apply to use 32 bit IFilter from 64 bit search process?

================================================================================ 

Lets handle the issues in reverse order:)

Issue# 3

From a strictly technical perspective, one can use the 32 bit PDF Filter from the 64 bit MOSS search service
By creating a utility to drop the 32 bit filter as a COM+ service component.The other option is to use dllhost.exe as a surrogate Host. However, this will NOT be officially supported by Microsoft, and when the 64 bit PDF filter dll does become available, you'd need to unregister the COM+ service and re-index the PDF documents.

Issue # 1 & 2

Our Test Manager, Dwight summed up the answers for issue#1 and 2 in his reply to one of our consultants:

" As suggested by Deb below, our search server products (Microsoft Office Sharepoint Server, Windows Sharepoint Services, SQL, Exchange, etc) do not support loading 32-bit binaries, and we have been referring customers who are using 3rd party IFilter products to original IFilter developers. As a result, we have not deployed 32-bit versions of these filters on our 64-bit installations, and we therefore do not index file formats which do not support 64-bit filters on our server products deployed internally.
We have kept our internal deployments 'pure' so that our dog-food experience exactly matches that of our customers. Overall, this has been a question we have struggled with for a while now. How do we support our server customers who may be running 3rd party code in our process, insulate ourselves from aberrant 3rd party code, and allow well behaving 3rd party code to run without restriction? We have designed the system to recover from many classes of software malfunctions, and virus attacks, but it is a arms race in the end.
I appreciate that IT organizations have a conflicting set of requirements: 99.99%+ uptime, and support 3rd party tools; some of which never were designed to be deployed in a server environment.
Adobe should be proud of their work over the last year in order to make their 32-bit IFilter multi-threaded safe, and I would encourage then to continue on the server bandwagon by generating a 64-bit version. "
Dwight

Comments

  • Anonymous
    January 13, 2007
    The comment has been removed

  • Anonymous
    January 16, 2007
    The comment has been removed

  • Anonymous
    January 16, 2007
    The comment has been removed

  • Anonymous
    January 17, 2007
    Thanks for the additional information.  I thought that I might have it figured out, but it doesn't seem to want to work. Is there any additional information that you might be able to provide me to help me on my way. Once again, thanks for all your help already. Ryan.

  • Anonymous
    January 17, 2007
    Ryan, here's another (simple ??) idea for indexing PDF documents: Write a managed filter to parse PDF documents and register it with SPS.This will be easier than using COM+. As daunting as it might sound at first, its not really that bad. There are a number of Third Party PDF Libraries which makes it very simple to instantiate a PDF document object and extract text from it.Once you have the text string, you can tokenize it to create the index. So to recap, you need two things:

  1. A Filter which exposes the IFilter interface methods(Use the links from my previous post) and
  2. A C# PDF Object model (I cannot recommend any specific ones here but a simple search will give you a lot of choices:)) Cheers, Deb. ======================================================== Disclaimer: The views and opinions expressed in this forum are solely that of the creator and participants  and are not endorsed by Microsoft in any way whatsoever.

  • Anonymous
    January 18, 2007
    Once again, thanks a million for all your help Deb.  I'll work on getting one together this week and let you know how it turns out.

  • Anonymous
    January 19, 2007
    The comment has been removed

  • Anonymous
    March 16, 2007
    Very useful information! In the long term, SharePoint needs to provide managed code interfaces for protocol handlers and ifilters. That seems to be the root cause of the issue, in my view. I have seen managed API based crawler development work beautifully with other portal search products, like Plumtree. This has been available with these competing products since a few generations and I was surprised to see that it is still missing in SharePoint 2007.

  • Anonymous
    April 24, 2007
    Just a relevant footnote here... XPS format supports 64 Bit. http://www.microsoft.com/downloads/details.aspx?FamilyId=B8DCFFDD-E3A5-44CC-8021-7649FD37FFEE&displaylang=en :)

  • Anonymous
    October 26, 2007
    Ryan, Did you get any luck with the 64 bit?

  • Anonymous
    November 01, 2007
    Does anyone have any experience with using a different 64bit IFilter like this one: http://www.foxitsoftware.com/pdf/ifilter/index.html#downifilter

  • Derek