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

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. "


Comments (11)

  1. Deb Haldar says:

    One of our fromer MCS consultnts,Jim Welch made this very valuable suggession:

    “Another workaround for MOSS web farm deployments that has not been mentioned is to deploy a 32-bit index server while keeping the rest of the SharePoint farm 64-bit.  It gives you the performance benefits at the database and web front-end tiers, the two most likely points for bottlenecks, until it is ok to upgrade the index server to 64-bit.”

    – Jim

  2. Ryan Smith says:

    Thanks for the great thread.  Definitely got me pointed in the right direction.  I’m still having some difficulty understanding exactly how to register the IFilter as a COM+ component.

    I notice that there are several DLL files in the IFilter folder, but I’m guessing the main one is PDFFILT.dll

    Do I try and register every DLL in this folder, or just the main one.  Also, do I use regsvr32 under the WOW64 folder, or do I need to use a 64bit version of regsvr.

    Any sort of detailed instructions on how to register the IFilter as a COM+ component would be greatly appericated.

    Also, has anyone gotten this to work successfully yet?

    Once again, thanks for at least pointing me in the right direction.

  3. Deb Haldar says:

    Ryan, I haven’t had the oppurtunity to play around with it, but here’s the basic idea I had:

    –> The Filter should be registered in the WOW64 directory as a service component.You probably want to use a managed wrapper for this using .Net EnterpriseServices.

    –> Create a Managed wrapper for the PDF Filter and register this with SPS following the Registration guidelines in the blog.

    –> An Example of the managed filter wrapper can be found at:[All]

    –> The Managed Filter wrapper in effect acts as your surrogate PDF IFilter and consumes the services provided by your actual PDF IFilter now wrapped as a COM+ service.

     Let us know if it works for you.


     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.

  4. Ryan Smith says:

    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.


  5. Deb Haldar says:

    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:))




    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.

  6. Ryan Smith says:

    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.

  7. Deb Haldar says:

    You’re welcome Ryan.

    If you’re going down the route of writing a new Ifilter to index PDF documnets, make sure you set the COM CLSID of your filter to {4C904448-74A9-11D0-AF6E-00C04FD8DC02}.This value is interpreted by SPS as the CLSID of the PDF IFilter.After your component is built, please check all the registry requirements are satisfied as mentioned under "Filter Registration".

  8. Sandeep says:

    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.

  9. marcovanschagen says:


    Did you get any luck with the 64 bit?

  10. Derek Feagin says:

    Does anyone have any experience with using a different 64bit IFilter like this one:

    – Derek

Skip to main content