Windows Server

Benson Miller · Guest

I am working on a SPS 2003 metadata indexing and searching solution for a
large PDF document store. I am using the PDF+ iFilter from ifiltershop in
conjunction with the free Adobe PDF iFilter.

I have assigned metadata to a test document. I can view the metadata through
Acrobat 7.0 Professional. I can also validate that the PDF+ iFilter is
appropriately exposing this metadata by using the FiltDump.exe utility
included in the MS Platform SDK.

The only thing I'm missing is that SharePoint does not seem to be
registering this metadata. When I browse to 'Manage properties of crawled
documents', my custom properties are absolutley not listed in /any/ of the
property sets (hidden or not).

Now, the PDF+ iFilter exposes custom metadata under a unique (generated by
me, using GuidGen.exe) property set GUID. I don't know whether this has any
effect on whether SPS will 'notice' this metadata and make it available for
management. My assumption was that any property set should be exposed by SPS
for management after an indexing run. My assumption seems to be incorrect.

Can anyone point me in the right direction? Are there registry keys that
effect this behavior? Other settings that are hidden in dark alleys?
Suggestions of more appropriate news groups for this query?

With appreciation,
Benson

* My email address needs modification for successful replies. *

Benson Miller · Guest

I find the lack of information on this topic disheartening. I have seen
other similar questions floating about the web, none of which has had a
single response.

In short:
My experience has lead me to believe that SharePoint will ignore custom
metadata that is exposed by the PDF+ iFilter. At any rate, the metadata that
is exposed by the iFilter is not available for managment through the "Manage
Properties of Crawled Documents" interface. This is not true for Office
documents, but it is empirically true of PDF docs (and perhaps all
non-Office documents).

I imagine that there must be some way to convince the indexing service to
consider the custom properties that I'm exposing. After all, I know (and
control) all defining characteristics of the property sets and associated
properties. If this is impossible, I will find it hard to interpret as
anything other than antagonism to other (non-MS) document formats.

Will anyone provide some guidance?

Regards,
Benson

"Benson Miller" <benson@NOSPAMspeakeasy.net> wrote in message
news:FvKdnW3gsfN5NfreRVn-sA@speakeasy.net...

Hollis D. Paul · Guest

In article <sc2dnYn6DLPCgvTeRVn-rg@speakeasy.net>, Benson Miller wrote:

Benson Miller · Guest

Thank you for your response Hollis.

I have read that section of the help file. It is very good, provided your
property sets are listed for management. The property sets that my iFilter
is exposing are not even showing up in the list of property sets on the
"Manage Properties of Crawled Documents" page. I know they're being exposed
to SharePoint, but SharePoint isn't making them available to me for any
management activities.

This is certainly related to the fact that I'm indexing non-Office
documents. I have no problems managing custom metadata from Office
documents.

b

"Hollis D. Paul" <Hollis@outhousebythesound.com> wrote in message
news:VA.000024d2.015385f8@obts-outlookdev.outlookbythesound.mukwoods...

Hollis D. Paul · Guest

In article <4dednaWZeJf73PTeRVn-sg@speakeasy.net>, Benson Miller wrote:

Mike McIntyre [MSFT] · Guest

Hello Hollis,
This may be of benefit:
890052 Some documents are not returned in the search results when you use
the Advanced Search feature in SharePoint Portal Server 2003 to search for
content that has a custom property http://support.microsoft.com/default.aspx?scid=kb;EN-US;890052.

There is a hotfix & registry hack to make this work. They are documented
in the KB article.
--------------------------------------------------------------------------------
Regards,
Mike McIntyre [MSFT]

This posting is provided "AS IS" with no warranties, and confers no rights.

HP> In article <4dednaWZeJf73PTeRVn-sg@speakeasy.net>, Benson Miller
HP> wrote:
HP>

Benson Miller · Guest

Thank you, Mike. I've looked at that KB article and it doesn't apply to the
problem I'm having.

Unless someone has information to the contrary, my appraisal is that
SharePoint ignores custom metadata properties of non-Office documents at the
time of indexing. Custom metadata properties of non-Office documents are not
added to the content index. Worse: the fact that custom properties exist is
not even registered in SharePoint so that they can be manipulated via the
'Manage Properties of Crawled Objects' interface.

So far, I have had no indication from any SharePoint user that they have
been able to see their custom metadata properties (and property sets) of
non-Office documents in SharePoint. I would love some evidence to the
contrary, but I suspect that no such evidence is available.

b

"Mike McIntyre [MSFT]" <mmcintyr@online.microsoft.com> wrote in message
news:6c3b040861398c7af490bee43aa@msnews.microsoft.com...

Benson Miller · Guest

This issue has been solved. By using the iFilter Explorer, available from
citeknet.com, I was able to determine that SPS was referencing the free
Adobe PDF iFilter and not the PDF+ iFilter from ifiltershop.com. My thanks
to Olga at ifiltershop.com for the solution.

From Olga's solution:

For some reason, during installation process PDF+ IFilter registered itself
on
the Indexing Service level (System level) but it did not register properly
with
SharePoint 2003. When looking for an IFilter for PDF files, SharePoint first
looks in SharePoint specific registry settings and after that (in case of
failure) in System level registry settings.

Normally Adobe IFilter does not specifically register itself with
SharePoint. So usually, even if PDF+ IFilter was not registered with
SharePoint, it is still
being used by SharePoint which obtains information about PDF+ IFilter from
System level registry settings. But in your case for some reason Adobe
IFilter
was registered on SharePoint level, so SharePoint was using Adobe IFilter
instead of PDF+ IFilter. Adobe IFilter outputs several internal PDF
properties
such as 'title', 'author' and 'subject' which are copies of corresponding
XMP
properties. These are probably the properties that your saw on SharePoint
search result page. You SharePoint Server is most likely working properly
with
custom metadata, it just was not receiving any custom properties.

If you remove "/Filters/Extensions/.pdf" subkey from SharePoint registry
settings, restart SPS and run full-update, this should make SPS use PDF+
IFilter to index PDFs instead of Adobe IFilter.

Regards,
Benson

"Benson Miller" <benson@NOSPAMspeakeasy.net> wrote in message
news:FvKdnW3gsfN5NfreRVn-sA@speakeasy.net...

	Windows Server Forum Index -> Portal Server	All times are GMT
Page 1 of 1