Video Screencast Help

index delete operations that have not yet been committed to disk. EV8 SP1

Created: 21 Jul 2009 • Updated: 21 May 2010 | 9 comments
This issue has been solved. See solution.


I am getting this message in the eventlog every morning about indexing and the number of items increases every day..

Event Type: Warning
Event Source: Enterprise Vault
Event Category: Monitoring
Event ID: 41022
Date: 21/07/2009
Time: 09:00:21
User: N/A
Computer: EVS01
There are 37712 index delete operations that have not yet been committed to disk for Vault Store 'EVSMailstore'.

Check that the Storage Service is running.

For more information, see Help and Support Center at

The storage service is running fine, indexing is running and there are no failed indexes... archiving is running fine.

Anyone got any ideas what this means and how i can get it to process the items?


Comments 9 CommentsJump to latest comment

Liam Finn's picture

 Do you have the indexes in backup mode?

If they are in backup mode no data will be written to the disk for the indexes until you reset this back to normal mode

Col G's picture

No.. i tried putting everything into backup mode then removing it again, also its had a reboot.

The Vaults are on Netapp CIFS shares, but the Indexes are on iscsi storage...

Liam Finn's picture

Check to ensure that the disk is presented to the server in persistant mode

Verify that you can read and write to the iSCSI disk by creating a TXT file on it

Did you recently just move the indexes to the iSCSI disk or has it always been there, I ask because maybe there is a performance issue with your setup and the writes to the iSCSI is not fast enough

Col G's picture

The disc is persistant and writeable, and there are only indexes on the drive.

The only change in the past was to move the volume as per the symantec technote. and add extra new index volumes as previously they were all in one folder (and still are)

I can browse indexes using the archiveexplorer, but there is very little other activity.

Col G's picture

Have just checked the SQL stuff and that looks like it could be the culprit...
Indexing has never worked right here until recently...

Will apply tomorrow eve and report back!

Col G's picture

Well changing the SQL compatibility level has indeed fixed this problem....

Should all the databases (inc directory and monitoring) be changed to SQL2005 mode?