Indexing PDF in SP2013: iFilter parser error, No filter installed for extension 'pdf'

Question

When I attempt to index PDF files I get an error from the Crawl log in Central Admin: “Processing this item failed because of a IFilter parser error. (…) No filter installed for extension ‘pdf’”

To my understanding, the possibility of using custom PDF iFilter came back to Sharepoint after the July 2014 CU (source). At one point PDF’s were indexing just fine. This is what I have done:

• Set the UseIFilter property to true through Set-SPEnterpriseSearchFileFormatState in PowerShell

• Installed FoxIT PDF iFilter

• Ran full crawl and saw that PDF files were being indexed+searchable by content
• The trial of FoxIT seems to have run out and it is decided not to purchase this software, since indexing PDF’s is possible through a standard SP2013 installation (am I mistaken?)
• I can’t say for sure when these errors started appearin (before or after trial expiration), but I find it natural to think that this happened after the trial ran out
• Uninstalled FoxIT PDF iFilter, hoping the file handler through SP2013 would know how to index PDF’s

I think I read somewhere that Adobe Reader was bundled with an iFilter, so I have also installed this on both the search server and frontend server. This did’t seem to have much impact other than removing another error that was seemingly related to this: “Processing this item failed because of a IFilter parser error. (…) Value does not fall within the expected range”.

Have I broken the indexing by installing/uninstalling or by changing UseIFilter property? Do I need to re-register the iFilter for this document type? If so, how do I do that?

Answer 1

I would get rid of all the Adobe products and change the UseIFilter property back to false. Then run a full crawl to determine if the native PDF file handler is working correctly.

Answer 2

I am sure you index will be fine after installing or uninstalling but you have to have run the full crawl after this activity.

I think you should remove the custom ifilter as it is trial version and expired. We had metalogix trail product in our farm which give us tough time after expired trial.

I would uninstall the 3rd party ifilter and then configure search to use the default one.

after that "Your change is effective after you restart the SharePoint 2013 Search Host Controller process of each server that hosts a content processing component in the Search service application."

Now run full crawl. https://technet.microsoft.com/en-us/library/jj730455.aspx

Answer 3

TLDR; install the July 2016 CU for SharePoint 2013.

Full answer:

We were in the same boat but with a custom IFilter for a file type is widely used by the industry my company is in. The ifilter worked fine with SP2007 and SP2010 but with SP2013 we found that SharePoint was never loading the filter for the file type. It turns out that Microsoft changed how they detect a files type, instead of trusting the extension they look inside at the content. I suppose they had too many instances of files being handled improperly due to the wrong extension. The problem was that if your file type was a ASCII text file, their auto-detection would always trigger first and never trigger the loading mechanism for custom file types. The July 2014 CU was supposed to fix it by giving us the new parameters listed in the question, but it didn't work for us.

I was able to demonstrate using Process Explorer that the registry entry for the file type was never being read which meant that SharePoint was not honoring the 'useIfilter' parameter even when it was properly configured. I know this because we opened a support ticket with Microsoft and walked them through the installation, registry, test cases, etc. and even sent them a copy of the ifilter along with a test file and the product group admitted it was a bug. Microsoft has posted a fix for this in the July 2016 CU. Admittedly we aren't done with our testing but I can see that the custom ifilter is now being loaded so I have hope that this is fixed.