Thoughts from the EPS Windows Server Performance Team
I have to admit that we don’t get too many calls on Desktop Search. However, the calls we usually get revolve around rebuilding the index and adding locations. Recently however, we had a customer ask us how to modify the file types properties for Indexing. Specifically, they wanted to add a new file type to each of their client machines for a network-based program that they were using. If you are not familiar with this option, in the Indexing Options applet in Control Panel, under the Advanced Options, there is a tab that lists the different file types and how they are indexed (see below):
In this specific instance, the question revolved around whether or not they could create a custom .ADM to modify these options, and if so, which registry key(s) did they need to modify to roll out the changes. Now, on the surface, this probably seems like a fairly straightforward question. However – the fact is that this list is auto-generated, partially by reading the different file type registrations and their associated iFilters from HKEY_CURRENT_ROOT. In other words – the Indexer simply picks up the information that is used by the entire operating system to determine how different file types are handled. By default, all file basic properties are indexed whether or not the file is registered in HKEY_CURRENT_ROOT.
A misconception (and this really applies to some of the more hardcore admins out there!) is that you can use the HKLM\Software\Microsoft\Windows Search\Gather\Windows\SystemIndex\Extensions\ExtensionList registry key to add new file types. In actuality, this is the key that controls which file types to NOT index. Let’s take a quick look:
In this example, I am going to disable the very first file extension listed on my system - _sln. By unchecking the box, what I am telling the Indexer is that I do not want this file type indexed.
After I click on OK, I can go into my Registry Editor, navigate to the key listed above and …
… the only file value added is the one for the extension I selected. So clearly, this is not the registry key that I want to be messing around with!
In order for a file extension for a program to be added to the dialog, its extension should be present in HKEY_CLASSES_ROOT in the registry. If you need to index properties beyond the basic file properties, then you would need to create a property handler for the file type (see the link below). If you wanted to index the actual contents of the file then you would need to write an IFilter (again, the link is below). So, going back to our customer’s case, had the application been installed on the client machine instead of being launched from a network share, the associated file type would have been registered on the local system and they would have been able to index the basic file properties.
That’s all for today’s post – the MSDN links for more information about property handlers and IFilters are below. Next week is Thanksgiving week in the United States, so we won’t be publishing any posts. We’ll see you back here on December 2nd. Until next time …
- CC Hameed
Maybe the reason you don't get many calls on Desktop Search is that it is so bad that noone uses it?
I've been using Vista for 3 years (I used to be in Redmond) and in that time I have never had a search return the results I'm looking for.
Yes, I tried talking to the Search team about it, but it didn't make any difference.
My problem is that my normal files are perfectly organised, I don't want to search for them.
What I want to search for are source code files and other files associated with development - obj files through to exes and dlls.
And I usually only want to search by part of the name of the file.
And the search engine simply doesn't work for those types of searches.
Note that having to reconfigure the search engine for my purposes isn't good enough - I use too many machines for that to be viable.