Steven Nicolaou

Change the Default IFilter Handler

2012-11-07T22:20:00Z

IFilters are registered at the OS level and allow applications to convert binary file formats to raw text for search indexing. The IFilter that is registered to handle a certain file extension is called the Default Handler. Here we will see how to switch between Default Handlers when you have multiple IFilters installed. We will work with PDF handlers, specifically Adobe and Foxit, but the process can apply to any handler.

Add the Windows Search Service

Before you can manage Filter Handlers in Windows 2008, you need access to Indexing Options in the Control Panel. If this is not available, install the Windows Search Service Role Service, which is under the File Services role. You don't need to index any volumes.

This makes Indexing Options available in Control Panel:

Inspect the Default Filter Handlers

Now click on Indexing Options / Advanced / File Types. This shows you the list of file extensions and the default Filter Handler registered for it. Notice in my case that there is no handler for pdf, so I will be unable to index the contents of PDF files.

Install the IFilters

There are several options on the market for PDFs, the main ones being the Adobe PDF IFilter and the Foxit PDF IFilter. Suppose I wanted to install both, so I can compare their performance. Each installation will make itself the default handler, but short of reinstalling the other Filter, there is no easy way to switch between them.

After installing the Adobe Filter, you can see that it adds a Handler for PDF that it calls "PDF Filter". Notice that "Index Properties and File Contents" is selected, which is necessary if you want to extract the body of the document and not just its properties.

It's important to know the GUID for this Handler, because it'll be useful later. A quick scan of the registry for "PDF Filter" yields the following GUID: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E8978DA6-047F-4E3D-9C78-CDBE46041603}

Indeed you can verify this is the official Adobe IFilter GUID by looking at other articles describing how to configure it with SharePoint or how to replace it with Foxit. If you're curious, the InprocServer32 key below it points to the DLL for the Filter Handler.

For now, we just care that we know the GUID, which is {E8978DA6-047F-4E3D-9C78-CDBE46041603}.

Any indexing of PDF content at this point will use the Adobe Filter. Now let's install Foxit. A fresh look at the Advanced Indexing Options shows us that Foxit replaces Adobe's Handler with its own, which it calls "Foxit PDF Filter".

What's the GUID for Foxit? Another quick scan of the registry, this time for "Foxit PDF Filter" gives us HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{987F8D1A-26E6-4554-B007-6B20E2680632} and thus the GUID {987F8D1A-26E6-4554-B007-6B20E2680632}.

As previously, you can verify this by reading the Foxit IFilter FAQ, but it's nice to figure it out ourselves.

So now we know the following

Adobe GUID: {E8978DA6-047F-4E3D-9C78-CDBE46041603}
Foxit GUID: {987F8D1A-26E6-4554-B007-6B20E2680632}

That's great, but now what if you want to switch back and forth? It would be nice if the File Description right here was a dropdown, wouldn't it? But it isn't :(

Default Handlers in the Registry

How do we find out where the Default handler is configured in the Registry?

Let's look at HKEY_CLASSES_ROOT\.pdf. In my case, it contains a PersistentHandler sub-key with the GUID {3C3DCD30-E62D-49A4-A746-039334AFDE59}. This GUID is a registry branch that defines the Filter Handler for PDFs.

Note: this GUID is not constant like the IFilter GUIDs are. Yours will be different.

So let's take a look at {3C3DCD30-E62D-49A4-A746-039334AFDE59} by searching for it. This brings us to HKEY_CLASSES_ROOT\CLSID\{3C3DCD30-E62D-49A4-A746-039334AFDE59}.

And there it is, under PersistentAddInsRegistered, the (Default) key pointing to the Foxit GUID of {987F8D1A-26E6-4554-B007-6B20E2680632}. As you've probably guessed, to change the default handler back to Adobe, we just have to replace this GUID with the Adobe one. Let's try it.

Now let's take another look at Advanced Indexing Options:

And we're back to Adobe "PDF Filter". That's it!

Summary

Here is how the registry entries are structured to define the default handler:

HKEY_CLASSES_ROOT\.pdf
 PersistentHandler
 (Default)={PDF Handler GUID}
 |
 ˅
HKEY_CLASSES_ROOT\CLSID\{PDF Handler GUID}
 PersistentAddInsRegistered
 {Some other GUID}
 (Default)={Filter GUID} <-- Change this

If you need to change the default handler for any different filter, the process would be the same:

Find the Filter GUIDs, either from the vendor, or by looking them up in the registry
Find the extension you're working on under HKEY_CLASSES_ROOT\.<extension>
Its PersistentHandler will point you to the GUID of the registered handler
Locate that handler GUID under HKEY_CLASSES_ROOT\CLSID\{Handler GUID}
Expand PersistentAddInsRegistered and its child GUID
The (Default) value is the GUID of the Filter that handles it
Change this to the GUID of the Filter you want

Packaging it up

There's a couple things I wanted to do to make it easier to switch them.

Firstly, I added adjacent keys with the 2 Filter GUIDs so I can remember them. I think it's harmless to add keys that aren't used by the system.

This way I can just copy/paste whichever key I need into (Default).

To make things even easier, I generated a .reg file for each configuration by exporting the HKEY_CLASSES_ROOT\CLSID\{3C3DCD30-E62D-49A4-A746-039334AFDE59}\PersistentAddinsRegistered\{89BCB740-6119-101A-BCB7-00DD010655AF} key. Now all I need to do is double click the appropriate .reg file to switch to that handler.

Managed Properties in FAST vs. SharePoint 2010

2012-11-02T19:39:00Z

In SharePoint 2010 the FAST Query SSA has its own set of managed properties out of the box, which is independent of those in the SharePoint SSA. Customers often wonder how these properties are different. Here we examine all the out of the box properties of each and their differences.

SharePoint

To get a list of all managed properties for the SharePoint SSA, run the following script in a SharePoint PowerShell:

#$ssa=A reference to the SharePoint SSA

Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa | Select Name, Managedtype

This gives us the following list of 126 managed properties.

AboutMe	Text
Account	Text
AccountName	Text
AssignedTo	Text
Author	Text
BaseOfficeLocation	Text
BestBetKeywords	Text
CategoryNavigationUrl	Text
CollapsingStatus	Integer
Colleagues	Text
contentclass	Text
ContentsHidden	Text
ContentSource	Text
ContentType	Text
CreatedBy	Text
Department	Text
Description	Text
DisplayDate	DateTime
DocComments	Text
DocId	Text
DocKeywords	Text
DocSignature	Text
DocSubject	Text
DuplicateHash	Integer
EMail	Text
EndDate	DateTime
ExcludeFromSummary	Text
ExpirationTime	DateTime
FileExtension	Text
Filename	Text
FirstName	Text
FollowAllAnchor	Text
HierarchyUrl	Text
HighConfidenceDisplayProperty1	Text
HighConfidenceDisplayProperty10	Text
HighConfidenceDisplayProperty11	Text
HighConfidenceDisplayProperty12	Text
HighConfidenceDisplayProperty13	Text
HighConfidenceDisplayProperty14	Text
HighConfidenceDisplayProperty15	Text
HighConfidenceDisplayProperty2	Text
HighConfidenceDisplayProperty3	Text
HighConfidenceDisplayProperty4	Text
HighConfidenceDisplayProperty5	Text
HighConfidenceDisplayProperty6	Text
HighConfidenceDisplayProperty7	Text
HighConfidenceDisplayProperty8	Text
HighConfidenceDisplayProperty9	Text
HighConfidenceImageURL	Text
HighConfidenceMatching	Text
HighConfidenceResultType	Text
HitHighlightedProperties	Text
HitHighlightedSummary	Text
HostingPartition	Text
ImageDateCreated	DateTime
Interests	Text
IsDocument	YesNo
JobTitle	Text
Keywords	Text
LastModifiedTime	DateTime
LastName	Text
Location	Text
Memberships	Text
MetadataAuthor	Text
MobilePhone	Text
ModifiedBy	Text
NLCodePage	Integer
Notes	Text
OfficeNumber	Text
OrgNames	Text
OrgParentNames	Text
OrgParentUrls	Text
OrgUrls	Text
OWS_URL	Text
parentLink	Text
PastProjects	Text
Path	Text
PictureHeight	Integer
PictureThumbnailURL	Text
PictureURL	Text
PictureWidth	Integer
PreferredName	Text
Priority	Text
PrivateColleagues	Text
Pronunciations	Text
Purpose	Text
Rank	Integer
RankDetail	Text
RankingWeightHigh	Text
RankingWeightLow	Text
RankingWeightName	Text
Responsibilities	Text
Schools	Text
SecondaryFileExtension	Text
ServerRedirectedURL	Text
ServiceApplicationID	Text
SipAddress	Text
Site	Text
SiteID	Text
SiteTitle	Text
Size	Integer
Skills	Text
SocialTagTextUrl	Text
SPSiteURL	Text
StartDate	DateTime
Status	Text
Title	Text
UrlDepth	Integer
urn:schemas.microsoft.com:fulltextqueryinfo:cataloggroup	Text
urn:schemas.microsoft.com:fulltextqueryinfo:sourcegroup	Text
urn:schemas-microsoft-com:office:office#Description	Text
urn:schemas-microsoft-com:office:office#ows_CrawlType	Text
urn:schemas-microsoft-com:office:office#ows_ListTemplate	Text
urn:schemas-microsoft-com:office:office#Subject	Text
urn:schemas-microsoft-com:office:office#Title	Text
urn:schemas-microsoft-com:publishing:Category	Text
urn:schemas-microsoft-com:publishing:CategoryTitle	Text
urn:schemas-microsoft-com:sharepoint:portal:area:CategoryUrlNavi	Text
urn:schemas-microsoft-com:sharepoint:portal:area:Path	Text
UserName	Text
UserProfile_GUID	Text
WebId	Text
WikiCategory	Text
WorkEmail	Text
WorkPhone	Text
YomiDisplayName	Text

FAST Search

To get a list of all managed properties for the FAST Query SSA, run the following script in a FAST PowerShell on the FAST server:

Get-FASTSearchMetadataManagedProperty | Select Name, Type | Sort-Object Name | Format-Table

This gives us the following list of 102 managed properties:

Account	Text
anchortext	Text
AssignedTo	Text
assocqueries	Text
Author	Text
body	Text
charset	Text
CollapsingStatus	Integer
Companies	Text
Company	Text
companyteaser	Text
contentclass	Text
Contents	Text
ContentSource	Text
ContentType	Text
crawledpropertiescontent	Text
crawledpropertynames	Text
Created	Datetime
CreatedBy	Text
description	Text
DetectedLanguage	Text
DisplayDate	Datetime
docacl	Text
docaclsystemid	Text
DocComments	Text
docdatetime	Datetime
DocKeywords	Text
docrank	Integer
DocSubject	Text
documentsignature	Integer
docvector	Text
domain	Text
eetitle	Text
EndDate	Datetime
fileextension	Text
Filename	Text
FilterMetaData	Integer
format	Text
HitHighlightedProperties	Text
HitHighlightedSummary	Text
hwboost	Integer
ImageDateCreated	Datetime
IsDocument	Boolean
IsEmptyList	Boolean
IsListItem	Boolean
JobTitle	Text
Keywords	Text
language	Text
languages	Text
Location	Text
locations	Text
locationteaser	Text
MetadataAuthor	Text
MobilePhone	Text
ModifiedBy	Text
notes	Text
OrgNames	Text
OWSItemURL	Text
owsmetadatafacetinfo	Text
owsSPLocationInfo	Text
owstaxid	Text
owstaxidmetadataalltagsinfo	Text
owstaxIdSPLocationInfo	Text
owstaxIdSPLocationList	Text
owstaxIdSPLocationSite	Text
OWSURL	Text
Path	Text
personnames	Text
personnameteaser	Text
PictureHeight	Integer
PictureThumbnailURL	Text
PictureWidth	Integer
Priority	Text
processingtime	Datetime
Purpose	Text
SchemaSignature	Integer
ServerRedirectedURL	Text
Site	Text
SiteId	Text
SiteName	Text
siterank	Integer
SiteTitle	Text
Size	Integer
sizelabel	Text
spdocid	Text
spsiteurl	Text
StartDate	Datetime
status	Text
teaser	Text
Title	Text
tld	Text
url	Text
urldepthrank	Integer
urlkeywords	Text
urls	Text
UserName	Text
WebId	Text
WikiCategory	Text
WorkEmail	Text
WorkId	Integer
WorkPhone	Text
Write	Datetime

Differences

So now we have a handy reference for all the managed properties. You'll notice not only that the FAST list is shorter, but there are actually a lot of changes. FAST drops and introduces quite a few of them. For a better look at how they are different, here is a Diff of the two, showing the change as you move from the SharePoint SSA to the FAST Query SSA.

Legend:

In SharePoint SSA but not FAST Query SSA

In both

New in FAST Query SSA

AboutMe

Account

AccountName

anchortext

AssignedTo

assocqueries

Author

BaseOfficeLocation

BestBetKeywords

CategoryNavigationUrl

body

charset

CollapsingStatus

Colleagues

Companies

Company

companyteaser

contentclass

ContentsHidden

Contents

ContentSource

ContentType

crawledpropertiescontent

crawledpropertynames

Created

CreatedBy

Department

Description

description

DetectedLanguage

DisplayDate

docacl

docaclsystemid

DocComments

DocId

docdatetime

DocKeywords

DocSignature

docrank

DocSubject

DuplicateHash

documentsignature

docvector

domain

eetitle

EndDate

ExcludeFromSummary

ExpirationTime

FileExtension

fileextension

Filename

FirstName

FollowAllAnchor

HierarchyUrl

HighConfidenceDisplayProperty1

HighConfidenceDisplayProperty10

HighConfidenceDisplayProperty11

HighConfidenceDisplayProperty12

HighConfidenceDisplayProperty13

HighConfidenceDisplayProperty14

HighConfidenceDisplayProperty15

HighConfidenceDisplayProperty2

HighConfidenceDisplayProperty3

HighConfidenceDisplayProperty4

HighConfidenceDisplayProperty5

HighConfidenceDisplayProperty6

HighConfidenceDisplayProperty7

HighConfidenceDisplayProperty8

HighConfidenceDisplayProperty9

HighConfidenceImageURL

HighConfidenceMatching

HighConfidenceResultType

FilterMetaData

format

HitHighlightedProperties

HitHighlightedSummary

HostingPartition

hwboost

ImageDateCreated

Interests

IsDocument

IsEmptyList

IsListItem

JobTitle

Keywords

LastModifiedTime

LastName

language

languages

Location

Memberships

locations

locationteaser

MetadataAuthor

MobilePhone

ModifiedBy

NLCodePage

Notes

OfficeNumber

notes

OrgNames

OrgParentNames

OrgParentUrls

OrgUrls

OWS_URL

parentLink

PastProjects

OWSItemURL

owsmetadatafacetinfo

owsSPLocationInfo

owstaxid

owstaxidmetadataalltagsinfo

owstaxIdSPLocationInfo

owstaxIdSPLocationList

owstaxIdSPLocationSite

OWSURL

Path

personnames

personnameteaser

PictureHeight

PictureThumbnailURL

PictureURL

PictureWidth

PreferredName

Priority

PrivateColleagues

Pronunciations

processingtime

Purpose

Rank

RankDetail

RankingWeightHigh

RankingWeightLow

RankingWeightName

Responsibilities

Schools

SecondaryFileExtension

SchemaSignature

ServerRedirectedURL

ServiceApplicationID

SipAddress

Site

SiteID

SiteId

SiteName

siterank

SiteTitle

Size

Skills

SocialTagTextUrl

SPSiteURL

sizelabel

spdocid

spsiteurl

StartDate

Status

status

teaser

Title

UrlDepth

urn:schemas.microsoft.com:fulltextqueryinfo:cataloggroup

urn:schemas.microsoft.com:fulltextqueryinfo:sourcegroup

urn:schemas-microsoft-com:office:office#Description

urn:schemas-microsoft-com:office:office#ows_CrawlType

urn:schemas-microsoft-com:office:office#ows_ListTemplate

urn:schemas-microsoft-com:office:office#Subject

urn:schemas-microsoft-com:office:office#Title

urn:schemas-microsoft-com:publishing:Category

urn:schemas-microsoft-com:publishing:CategoryTitle

urn:schemas-microsoft-com:sharepoint:portal:area:CategoryUrlNavi

urn:schemas-microsoft-com:sharepoint:portal:area:Path

tld

url

urldepthrank

urlkeywords

urls

UserName

UserProfile_GUID

WebId

WikiCategory

WorkEmail

WorkId

WorkPhone

YomiDisplayName

Write

Extend the Search Box web part in SharePoint 2010

2010-06-24T20:54:00Z

Introduction

With SharePoint 2010 you can now extend the out of the box web parts, which essentially means you can create a new web part that inherits from one of the out of the box ones. In this post, I demonstrate extending a SharePoint Web Part in depth, using the search box as an example. First, let's take a look at the search box web part.

Find the Class

Since we will be inheriting from this web part, the first question we need to answer is: What is the class name of the web part I'm trying to extend? The answer isn't straightforward. The SharePoint Web Part Gallery doesn't provide this information, so it's not readily apparent by looking at the web part in design mode.

One way to find out is to add the web part to a page. In this case, from the Web Part gallery select the web part "Search Box" from the Category "Search". On the upper right corner of the web part, click on the drop down arrow and select "Export..."

This will prompt you to save the Web Part Definition file (.dwp). Open this file in a text editor and look for these two XML elements: Assembly and TypeName. In our case, the values are:

<Assembly>Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
<TypeName>Microsoft.SharePoint.Portal.WebControls.SearchBoxEx</TypeName>

This tells us a few things:

The class name for this web part is SearchBoxEx, which is what we have to inherit from.
It resides in the Microsoft.Office.Server.Search assembly.
It's part of the Microsoft.SharePoint.Portal.WebControls namespace.

You can confirm this by looking at the SearchBoxEx documentation. We have two namespaces involved here because SearchBoxEx is implemented in Microsoft.Office.Server.Search, but it inherits from Microsoft.SharePoint.Portal.WebControls.WebPartLoc. With a little digging around, I found that these two namespaces are in:

Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.Office.Server.Search.dll
Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\microsoft.sharepoint.portal.dll

As it happens, these are not listed in the .NET tab of the "Add Reference" dialog in Visual Studio, so you will have to browse for them manually.

Create the project

Create a new project using the Empty SharePoint Project template and add a new Web Part to it. I called mine SearchBoxExtension. Your class definition should look like this:

public class SearchBoxExtension : WebPart

As with every inherited web part, start by calling base.CreateChildControls:

protected override void CreateChildControls()
{
base.CreateChildControls();
}

Add the assembly references using the Browse tab to locate the two DLLs. Your references should look like this:

Inherit your new web part from Microsoft.SharePoint.Portal.WebControls.SearchBoxEx (the TypeName value) instead of WebPart:

public class SearchBoxExtension : Microsoft.SharePoint.Portal.WebControls.SearchBoxEx

Build and deploy your project and try to add your new web part to a SharePoint page. You should get this error:

.dwp vs .webpart

What's the problem? Here's what just happened. Both .dwp and .webpart file types are XML web part descriptors that are deployed with your web part. The Dashboard Web Part (.dwp) format was used in earlier versions of SharePoint, where web parts inherited from Microsoft.SharePoint.WebControls.WebPart. The newer .webpart format, which supersedes .dwp, is what you use when you inherit from System.Web.UI.WebControls.WebParts, which is what you should always do when developing brand new web parts. For this reason, when you create a new web part in Visual Studio 2010, it automatically creates a .webpart descriptor for you:

SharePoint 2010 comes with a mix of older and newer web parts, so the descriptors that go with them might be either .dwp or .webpart. As you might've guessed from its namespace, Microsoft.SharePoint.Portal.WebControls.SearchBoxEx is one of the older ones and therefore requires a .dwp descriptor. The error we just got is therefore telling us that it doesn't like SearchBoxExtension.webpart.

Create the .dwp descriptor

So how do we get the .dwp file?

There are two ways:

Create it manually
Modify the .dwp exported from the original class

To create it manually, use SearchBoxExtension.webpart for reference. First, add a new XML file to your web part and give it the same name but with a dwp extension. Your web part folder should look like this:

Corey Roth has a nice post that compares the differences between the two formats. First, let's look at SearchBoxExtension.webpart:

<?xml version="1.0" encoding="utf-8"?>
<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
   <metaData>
    <type name="SearchBoxTest.SearchBoxExtension.SearchBoxExtension, $SharePoint.Project.AssemblyFullName$" />
    <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
   </metaData>
   <data>
    <properties>
     <property name="Title" type="string">SearchBoxExtension</property>
     <property name="Description" type="string">My WebPart</property>
    </properties>
   </data>
</webPart>
</webParts>

By looking at the differences between the two formats, mapping the values from one to the other was relatively straightforward. Let's look at the result first:

<?xml version="1.0" encoding="utf-8"?>
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
<Assembly>$SharePoint.Project.AssemblyFullName$,Version=1.0.0.0,Culture=Neutral,PublicToken=ed9dffbe9e0cad7e</Assembly>
<TypeName>SearchBoxTest.SearchBoxExtension.SearchBoxExtension</TypeName>
<Title>SearchBoxExtension</Title>
<Description>My WebPart</Description>
</WebPart>

XML schema differences aside, there are essentially two changes. First, the xmlns is http://schemas.microsoft.com/WebPart/v2 instead of http://schemas.microsoft.com/WebPart/v3 indicating our move to an older format, and second, we need the assembly's public token. To get the public token, use the strong name tool with the -T parameter (sn.exe -T), or use Kirk Evans' cool trick using Visual Studio External Tools.

Alternatively, you can use the .dwp that you exported at the beginning of this exercise. Follow the steps above to create a new XML above and copy the contents of the original .dwp into your new one. Then make the following changes:

In the WebPart root element, remove all but the xmlns attribute.
Set the Assembly name to $SharePoint.Project.AssemblyFullName$ (you can copy this from the .webpart file)
Set the Assembly version to your assembly's version. This is usually 1.0.0.0, but you can find it in AssemblyInfo.cs in your project.
Replace the PublicKeyToken as described above.
Replace the TypeName with the type name provided in your .webpart file.

Deploy

Next, we have to ensure the .dwp file is deployed with the web part. Click on the file in Solution Explorer and change its Deployment Type property from NoDeployment to ElementFile. You can now safely delete the .webpart file. Your web part folder should now look like this:

Finally, edit Elements.xml and replace both instances of .webpart with .dwp in the Elements/Module/File element. Build and deploy your project and add your web part to a SharePoint page. You should see the default search box:

Conclusion

The web part you just added to your test page may not look exactly like the original. If you created your .dwp from scratch, you will have ignored all the other properties that had been set in the .dwp for the base class. If you modified the original .dwp, you will have retained the other parameters that defined the web part's default configuration.

You are now ready to build your derived search box.