Microsoft Index Server Guide: Catalogs

A catalog is the highest-level unit of organization in Microsoft Index Server. Each catalog is a completely self-contained unit, containing an index and cached properties for one or more scopes (virtual roots). In this version of Index Server, queries cannot span multiple catalogs.

The Default Catalog

The initial catalog location is determined during setup and stored in the IsapiDefaultCatalogDirectory registry entry. If the CiCatalog parameter is not specified in an .idq file, then this default catalog is used. Intially, the default catalog contains an index of all virtual roots with read access, but the scope of the catalog can be modified through administrative pages.

Multiple Catalogs

There are two reasons to create more than one catalog: to distribute queries, and to support virtual servers. Because it is impossible to create a query that spans more than one catalog, careful consideration of the consequences must be made before creating multiple catalogs. The ability to query “everything” is lost. Use of default catalog support is also impaired: no support for multiple IP address-specific default catalogs is provided.

Physically dividing the set of virtual roots between a number of catalogs will improve query performance, but only if most queries are restricted to a subscope (one or more virtual roots) of the Web site. This improvement occurs because the number of false hits (hits outside the query scope) will be reduced.

Creating an Additional Catalog

To create a catalog

For example, if you put the catalog in D:\Vdom2\Catalog.wci, the CiCatalog is set to D:\Vdom2. The CiCatalog specification should not include the Catalog.wci directory itself. The initial query against the catalog will start the indexing process. You may want to modify the set of virtual roots covered by the new catalog.

Associating a Catalog with a Virtual Server

By default, a catalog is not associated with a specific virtual server, and only virtual roots without a specific IP address are added to the catalog. To associate a catalog with a specific virtual server, add an entry under the IsapiVirtualServerCatalogs subkey. The name of the value is the IP address of the virtual server, and the value is the catalog location. For example, a catalog located in the root of drive G: that contains virtual roots accessible only from IP address 123.45.67.89 would look like: ...\CurrentControlSet\Control\ContentIndex\IsapiVirtualServerCatalogs\123.45.67.89 = G:\. After making this registry change, stop and restart Internet Information Server. Then, issue a query against the catalog for 123.45.67.89.

The previous procedure will add virtual roots (specific to the indicated virtual server) to the set of scopes covered by the new catalog. All virtual roots without a specific IP address will be available as well. Note that by default, common roots are indexed in all catalogs. Also, be sure to update the .idq and .ida files if you have changed them.

Multiple Catalogs for Multiple Virtual Servers

The following example shows how to set up multiple catalogs for a configuration containing multiple virtual servers.

In the following example, assume that you want to set up multiple catalogs for the following scenario:

To set up multiple catalogs for multiple virtual servers

You can of course customize the query forms to restrict access to specific scopes. You may also have to modify the administration forms separately.

Virtual Root	Physical Path	Permissions
/	D:\Vserver2\Root	Read
/Scripts1	D:\Vserver2\Scripts	Execute
/Reports	D:\Vserver2\Reports	Read

Moving and Removing a Catalog

It is safe to move a Catalog.wci directory to a new location. Similarly, to delete a catalog you need only delete the Catalog.wci directory. It is a good idea to update the relevant registry entries (IsapiDefaultCatalogDirectory and IsapiVirtualServerCatalogs) as well. Internet Information Server or Peer Web Services must be stopped before you remove or move catalogs. It is recommended that you review all your .idq files to make sure there are no references to nonexistent catalogs.

Physical Properties

The catalog is physically stored in a user-specified location. A directory named Catalog.wci is created there. Index server creates a number of files in this directory, including:

File	Purpose
`000``nnnn``.prp`	Holds cached properties. The name is the version of the property cache. Each modification to the property-cache schema increments this number by one.
`0001``nnnn``.ci`	Shadow and master indexes. Each index has a unique number nnnn.
`0001``nnnn``.dir`	Directory used to quickly search the similarly named shadow index or master index.
`cicat.hsh`	Quickly converts a path into an internal identifier used throughout the index.
`CiCL0001.*`	Contains a log of files that need to be filtered.
`CiFL``nnnn``.*`	Maps documents to the most recent index for a given document.
`CiPS0000.*`	Describes the record format of the property cache.
`CiPT0000.*`	Maps ActiveX property descriptors to internal identifier.
`CiSL0001.*`	Contains a log of in-use files that need to be filtered.
`CiSP0000.*`	Contains a list of physical scopes covered by this index.
`CiST0000.*`	Maps security Access Control Lists (ACLs) to internal identifier.
`CiVP0000.*`	Contains a mapping between physical and virtual paths.
`Index.*`	Master list of indices.

The Catalog.wci directory, and everything under it, will not be indexed by Index Server even if it is accessible through a virtual root of the Web site.