Virtual vault won't show all of the content to the folders it lists in outlook

[Sani_B]

Hi,

I have somewhat odd issue with virtual vault for one user:

Earlier the user asked why when he had drag and drop some items to the virtual vault those were shown as normal items in search results - this was probably just not synced/archived to the vault yet but investigating the issue the vault cache got reset the first time and after that started this content not showing problem on a larger scale. Only one user has reported this behavior so no reason to assume this is concerning the whole organisation.

I have done these few times now:
- ran ResetEVClient
- vault cache reset
reinstalled the Outlook add in couple of times - lastly upgraded from 10.0.4 CHF3 to 11.0.1 CHF3

Virtual vault will download the folder structure fine but won't show all the content though the setting is to download everything and there is plenty of room for the cache.
The syncronation will say that both header and contect sync completes normally.
Archive explorer / search will show all of the items normally so this is purely faulty virtual vault but the cache reset won't fix the issue. 

EV server version 10.0.4 CHF3
Client workstation Win 7 SP1
Outlook: Microsoft Outlook 2010, 32-bit (14.0.0.7167)
Add in version: was 10.0.4 CHF3, now 11.0.1 CHF3

Any ideas what to try with this?

Sani B.

[Elio_C]

Outlook in non-cached/online mode?

[JesusWept3]

When you see the yallow banner saying the item can't be viewed, you should be able to see a line in the log file such as this:

03/05/2016 19:07:30.752[8844][H]: EVMSP: <email subject> [Common::GetFullItem] Reason for stub: 10

That "Reason for stub" will tell you why the item couldn't be retrieved.
In that case, Reason for stub 10 = items not in cache, which can be because it hasn't downloaded the DB file yet, or it doesn't have enough room on disk.
 

Other reasons can be that the DB file can't be opened, maybe because its locked, or maybe corrupt, or maybe outlook is out of resources.
Also seen where the DatabaseList.ini gets "corrupted" and when it tries to determine what DB file the item is in, it can't read the Database file list and thus can't read the item

So another couple of things to check, in the log file, do a search for ClientDiagnostics.aspx

10/05/2016 14:04:06.800[5992][H]: HDR: Requesting page: ClientDiagnostics.aspx?P=2&MSt=0&CSt=3&Ci=6000&Td=0&Fa=0&Pa=0&Host=usersMachine&AId=17F8889A5BA1BAF4FB65879E1CAF79FB51110000evSite&OLVer=15.0.0.4815&Iv=11.0.1.3598.0&Me=

The Ci indicates how many items are in the users Vault Cache and Td means how many items are yet to download.
So if you have Td greater than 0, it could be that that particular item is still waiting to be downloaded from the EV Server
 

Also if you know the archive has 6000 items, and Ci shows 6000 then you know that its downloaded the items that its meant to have etc.

[Sani_B]

Okay - so I opened a case to Veritas support about this issue and it turned out to be issue with windows indexing / cosmetic issue with the EV add in.

Original problem: The user could not find a mail using the outlook search on Virtual valt and was convinced the virtual vault was faulty. (All items could be found searching directly from the vault)

They had ran the vault cache reset already once and what I saw was that if one would look at the vault cache status from Outlook-File-Enterprise Vault-Vault cache settings - Details it would show that the vault cache was not fully downloaded for some reason (the content would show way too low numbers).

The Support checked the cache item account from the registry which showd the correct number and we checked that if the message was looked for directly from the right folder in the Virtual vault and just scrolling the mail list down the message would be found.

So the reason the user was not able to locate the wanted email with searching was that apparently the windows indexing had not yet indexed the item in virtual vault cache (not sure there wasn't a deeper issue with the win indexing in the users workstation). There was no explanation as to why the Vault cache details would show incorrect information but in time the number would eventually reach the right sum in that view as well.