Rebuilding an index in Enterprise Vault is not necessarily something that you do every day -- nor should it be.

However, as a reference here is an outline of the steps that I followed just now to rebuild one of my test user indexes.

The user has a sizeable number of items in their archive (for a test user anyway!):

And I can see the state of their current index on the properties of their archive:

Now I issue a rebuild request from that screen and you then see the status change:

At the same time an event is logged in the Symantec Enterprise Vault event log:

When the rebuild is complete you will see another event:

Something which was added to the product quite some time ago was the ability to check on the progress of the rebuild.  Every 10,000 items the following is logged:

The event actually shows some really useful information, such as how far through the rebuild is, and an estimate of when it will finish.

How long the rebuild takes depends on a lot of different factors for example ...  how busy the Enterprise Vault server is at the moment, the type of storage device, the amount, size and complexity of the items, and the indexing level you are rebuilding to.  It is for those reasons that you need to watch out for the progress event ID's.

Another couple of things to be mindful of are two registry keys:

HKEY_LOCAL_MACHINE \ Software \ KVS \ Enterprise Vault \ Indexing

PoisonPillCount

DWORD

This will set the number of attempts to process an item before it is deemed to be poisoned.  It is actually used for two purposes.  Firstly if an error is found trying to open an index volume then after these many attempts it will be deemed corrupt and marked as failed.  If the error is found when trying to add items to the index, then the addition is abandoned and the index update steps on to the next item.

HKEY_LOCAL_MACHINE \ Software \ KVS \ Enterprise Vault

MaxConsecutivePoisonPillItems

DWORD

The maximum number of consecutive poison pill items before the index update is abandoned.  It will be restarted if the indexing service is restarted or the hourly check for pending updates.

So sometimes it might be necessary to set the first registry key low, eg 1-2.  And the second registry key high, eg 100+.  I personally wouldn't suggest changing them without investigating the cause of the failures though, and/or discussing it with Symantec Support.