InTrust 11.4.2 - Repository Indexing for Advanced Search Capabilities

Recreating the Index

In some situations, the index for a repository needs to be rebuilt from scratch—for example, if it becomes damaged. To recreate the index for a repository, take the following steps:

1. If you have multiple InTrust servers, find out which server manages the repository. To look up the server, open the properties of the repository and go to the Indexing tab.
2. Stop the Quest InTrust Server, Quest InTrust Real-Time Monitoring Server and Quest InTrust Agent services on that server.
3. Delete the IndexingRoot$ folder, which stores the indexing data. This folder can be in the following locations:
   • If the Store index in option is set to Repository folder (in the repository properties on the Indexing tab), IndexingRoot$ is in the folder specified on the Repository tab.
   • If the Store index in option is set to This location, then the location of IndexingRoot$ is specified there. In addition, you also need to delete IndexingRoot$ in the repository folder (look it up on the Repository tab).
4. Start the services from step 2 again.

After you have done this, the index will be recreated automatically, but it can take a very long time.

Notable Index Implementation Specifics

Where the Index Data Is Located

InTrust stores indexing information for a repository in a set of files located either in a folder on the InTrust server or in a network share on a remote computer.

To specify the location of the index data, open the properties of the repository, go to the Indexing tab and use the Store index in this location field.

Where the Processing Occurs

In the simplest case, the index of a repository is processed by a single InTrust server. This server is specified as the Index manager server in the repository properties.

However, if multiple repositories refer to the same InTrust server for indexing, this affects performance considerably. For better scalability, use a dedicated indexing worker, as described in the Dedicated Indexing topic.

What Happens to Index Data for Missing Events

When audit data is removed from a repository (for example, by a repository cleanup job), index data related to the removed events is not purged immediately; this cleanup operation starts automatically within 24 hours. If a lot of such orphaned index data stays behind, this may slightly slow down repository search.

Index data is made consistent automatically the next time the indexing utility runs—it starts every minute to process the newest events.

The Index Is Not Transferable

If you transfer the contents of a repository to another repository through a consolidation job, the index data from the source repository is not integrated with the target repository. All new data coming into the target repository needs to be indexed anew.

Therefore, indexing is not necessary in such situations, unless the source repository and its index are in frequent use.