Managing Search in C#

Encoder QR in C# Managing Search

ontent indexing was first introduced by Index Server in the NT4 Option pack and then was included in every version of Windows beginning with Windows

2000. The Index Server name was later changed to Indexing Service. This feature includes a file indexer but no gathering or crawling functionality and was not extensible to non-file system content. Site Server introduced the first Microsoft gatherer (or crawler) and reused the content index technology from Index Server. at the same time, content indexing was also added to Microsoft SQL Server 7 and has been enhanced in later versions of SQL Server (as well as Exchange Server). The indexing pipeline was rewritten for SQL Server 2005 to provide enormous increases in indexing throughput and scale for large databases. Microsoft Sharepoint portal Server 2001 and later versions built on the gathering and content indexing features from SQL Server 2000 and Exchange 2000 Server to provide aggregated gathering for portal and non-portal content. Eventually, this code base was retuned for the client desktop by the MSN team that produced WDS. WDS 3.0 was then integrated into Windows Vista as a system service and platform for use by applications (including the 2007 Microsoft Office system). Now WDS 4.0 is included as part of Windows Vista Sp2 and Windows Server 2008 Sp2 and is integrated into Windows 7 and Windows Server 2008 R2. Note for trivia buffs: Microsoft Office Xp shipped a version of the indexing engine for use on Microsoft Windows NT 4 and Microsoft Windows 98 (but would use the Indexing Service on Windows 2000).

The new Windows Search engine in Windows 7 and Windows Vista is based on the MSSearch indexing and search engine developed previously for SQL Server, SharePoint Portal Server, Microsoft Office SharePoint Server, and other Microsoft products . The new Windows Search engine replaces the Indexing Service (Cisvc .exe) used in earlier Windows platforms, including Windows XP and Windows Server 2003 . The Windows Search engine logically consists of the following four processes:

Indexer process The indexer process (SearchIndexer .exe) is the main feature of the Windows Search engine and is responsible for core indexing and querying activity on the system . This process is implemented as a Windows service named Windows Search

service (WSearch) and is exposed for management in the shell through the Service Control Manager (Services .msc) . This service runs in the context of the LocalSystem account but has all privileges removed except for the following two privileges:

SE_BACKUP_PRIVIlEgE This privilege allows the service to read every file on the system so that it can be indexed . SE_MANAgE_VOlUME_PRIVIlEgE with the NTFS change journal . This privilege allows the service to interact

System-wide Protocol Host The system-wide Protocol Host (SearchProtocolHost . exe) is a separate process that hosts protocol handlers to isolate them from the main indexer process . Protocol handlers are plug-ins assessing different stores, retrieving documents, and pushing the information to the SearchFilterHost process for filtering . The system-wide Protocol Host runs within the same LocalSystem context as the main indexer process . This security context is needed because the Protocol Host requires access to all files on the system . The system-wide Protocol Host also supports crossuser notifications and enumeration of per-computer data stores such as the local file system . Per-user Protocol Host The per-user Protocol Host (also SearchProtocolHost .exe) is another separate process that hosts protocol handlers to isolate them from the main indexer process . The difference between this process and the system-wide Protocol Host is that this process runs within the security context of the logged-on user . (If two users are logged on to the computer using Fast User Switching, it is likely that two per-user Protocol Hosts will be running .) A per-user Protocol Host is necessary because some data stores must be accessed using the credentials of the logged-on user to be indexed . Examples of such stores include Outlook e-mail (using MAPI), the CSC, and remote file shares . Search Filter Host process This process (which runs as SearchFilterHost .exe) hosts IFilters, which are used to extract text from files and other items . IFilters are hosted within a separate process instead of within the main indexer process to protect the Windows Search service from possible crashes and ensure the stability and security of the indexing engine . This process is needed because, although many IFilters are written by Microsoft, other IFilters may be written by third-party vendors and are therefore considered to be untrusted code . Hosting IFilters within a separate process (such as a filtering host) that has very restricted permissions (such as a restricted token) provides a level of isolation that protects the main indexer process if an IFilter crashes . The indexer process runs a single instance of SearchFilterProcess .exe, and this process holds all IFilter parsing documents that come from the system-wide and per-user SearchProtocolHost processes . This Search Filter Host process only reads streams of content, runs IFilters, and returns text to the indexer process .

In normal operation, each of these processes starts immediately after Windows boots and the desktop appears . The main indexer process (SearchIndexer .exe) is the only one that always continues to run, however the other processes may or may not be running, depending