01-08-2019 11:16 PM
Hello guys,
I hope you can help me with the following issue.
We have a number of VIPs who complaign about the fact that sometimes Outlook is crashing if you switch from mail to calendar. When investigating we found that in Outlook profiles, there was one EVxyz.tmp. If we detele that, everything would be back to normal.
I have checked the affected users archive 9 (ok), started a verify and sync task of the index (no errors were found). No errors were found in Event Viewer for this user or something related to.It is hard to recreate the problem, since it is happening random and there is no trigger. Being a VIP we have extremly limited access to his pc.
I have attached also two, not so relevant pictures, that I received from the local IT, but maybe it could help or be a hint.
We are running EV 12.1/ Exch2016
01-08-2019 11:17 PM
01-09-2019 04:25 AM
Hello Lorena,
The issue your VIP's have is with the local machine, Outlook and EV Add-In, not on your EV servers.
Can you replicate the issue easily? If so, you might want to set up a Client logging. See this
Do they by any chance use Vault Cache? Do you happen to have GPO's to prevent creation of PST files on local machines?
01-31-2019 01:03 AM
Hi Gerjtan,
Many thanks for you recommandations and my appologies for the late reply.
The problem cannot be replicated, just have to wait for a VIP to experience it again, in order to start the Max trace in Outlook and get the EV logs, maybe we can find out what is triggering this.
Yes, they have Vault Cache and as far as I am aware and have checked, there is no GPO to prevent the creation of pst file. Our users actually use pst file, although we don`t encourage their creation.
I will return with more info as soon as gather some logs.
Many thanks!
02-14-2019 12:17 AM - edited 02-14-2019 12:22 AM
Hi,
I finally have an affected user and some client logs, that, I hope, could lead to the root cause of this. I`m not quite sure, since my experience with administering EV is not too big, but can this behavior and the errors in the Client logs, can be related to the virtual vault?
Many thanks!
02-14-2019 01:21 AM
I found this post related to my problem.
So, these .db are related actually to the Vault Cache. " the files are created on the server first and then downloaded to the client which is then placed in their user profile on the machine, once downloaded the DB files are then deleted from the server" My question is, why are they triggering that error and how can it be fixed.
In the past when we had similar cases, the IT solved the issue by deleting those temp profiles in Outlook created by EV.
Any other idea or maybe someone knows what the process is behind?
Thank you in advance!
06-05-2019 05:23 AM - edited 06-05-2019 05:35 AM
Hello Lorena / all,
we have the same problem at our company too.
Hunderds of users are getting these error messages that some tmp files couldn't be found, mostly when trying to open the calendar. We also found these data files added to Outlook. evresetclient.exe and also resetting Vault Cache from the EV tab doesn't help. If you delete these tmp files it just appears a few days later again.
Our environment:
> 80k archives
EV version on server side: 12.3.2
EV Addin in Outlook: 12.2.3.1576 (Rollout of the newer version hasn't been done yet)
EV Cache and the Virtual Vault option is active. (users can active this manually)
But also installing the new EV Addin 12.3.2 doesn't change anything. The error messages still appear.
I'm starting to think that it has something to do with the Virtual Vault option, as the vault then appears as a "mailbox". The next time I will try to just deativate the Virtual Vault option, maybe it helps. I'll post an update about it.
Where you able to find any solution to this?
It's getting really annoying!
Thanks in advance for your help!
Outlook Data Files from EV?!
06-07-2019 02:00 AM - edited 06-07-2019 02:04 AM
Hello all,
so after a few tests I can now confirm, that the following steps didn't help:
Error messages still appear that some tmp files can't be found, eventhough the users never changed or deleted something. A few hunderd users are affected now.
Anyone else has these problems?!
No help at all?
What a mess, really desappointing...
I would be grateful for any help.
06-18-2019 03:23 AM
have you tried to reinstall Outlook?
or recreate the profile?
10-09-2019 02:16 AM - edited 10-09-2019 02:17 AM
Hi CConsult,
yes, we tried all of that.
Even a OS reinstallation didn't help. After a few days the errors appeared again.
Here some updates of the last few weeks:
In the meanwhile we tried additionally the following to rule out some possible causes (recommended by Veritas-Support / Back line engineer):
**\AppData\Local\Temp\EnterpriseVault
**\AppData\Local\KVS\Enterprise Vault
>> Run EICAR test for verification
We have ruled out everything possible, which leaves us with the EV-Cache as highly potential cause.
I'll keep you posted, if we find the solution together with the Veritas-Support.
Cheers
01-30-2020 01:23 AM
Hi,
I was curious if you managed to solve that annoying problem.
Support suggested at some point to recreate those .db from user`s PC. Solved the problem at that time. Haven`t received similar cases in a while...
This is an EV client log when the issue happened and below the steps applied on the pc. The partial and full reset of the Vault Cache didn`t solved the issue, so I recreated the .db files .
26/02/2019 12:09:45.138[61644][H]: CONTENT:STORE: ERROR :- Setting status of file to INVALID
26/02/2019 12:09:45.139[61644][H]: CONTENT:STORE: Filename is 'C:\Users\x443754\AppData\Local\KVS\Enterprise Vault\F83842A9F3E11F478F1D06B38321B0EB\2019_01_01_0013.db'
26/02/2019 12:09:45.139[61644][H]: CONTENT:STORE: Current status of DB is '4'
26/02/2019 12:09:45.140[61644][H]: CONTENT:STORE: ERROR :- Setting status of file to INVALID
26/02/2019 12:09:45.140[61644][H]: CONTENT:STORE: Filename is 'C:\Users\x443754\AppData\Local\KVS\Enterprise Vault\F83842A9F3E11F478F1D06B38321B0EB\2019_01_01_0014.db'
26/02/2019 12:09:45.141[61644][H]: CONTENT:STORE: Current status of DB is '4'
02-06-2020 09:50 AM
You should launch the user's outlook in safe mode. that way no add-ins are loaded. it could be that two add-ins are having issues playing nice with each other
02-25-2020 06:41 AM - edited 02-25-2020 06:51 AM
Hi Lorena,
yes, we still have this problem.
We have already tried deleting the folder 'C:\Users\userAccount\AppData\Local\KVS\Enterprise Vault\XXXXX' and reset the EV-Addin before, but it didn't help. The EV-Addin then start downloading the whole content again and all files would be recreated, as you said. At this steps we didn't always recreate the Outlook profile, but anyway it didn't help.
We also tried installing the new EV-Addin 12.5.0.1221, but nothing changed.
At the moment we are trying an EVSVR Repair and an index rebuild afterwards for an affected archive, just in case it helps.
Did this problem appeared again in your environment in the last few weeks?
@JimmyNeutron : Starting Outlook in SafeMode will prevent the popup from appear if you make a cleanup before. This is only because the EV-Addin is not running anymore, but at some point you have to activate it again to use it and the error will appear again. We also tried to deactivate other Outlook Addins while the EV-Addin stayed active, but it didn't help.
Cheers
06-22-2020 05:41 AM - edited 06-22-2020 05:43 AM
Update: Issue is still appearing and the EV-Support hasn't provided a solution for it. For now the only solution we see is to completly migrate away from Enterprise Vault to O365 - Exchange Online and use the built-in archive.
06-22-2020 11:25 PM
Hello.
Migrating away from EV is a harsh decision to fix an issue imho, but yor choice.
Have you contacted your Veritas Sales person? Did you request the case to be escalated? I'm pretty sure if you tell sales you will stop using EV, and paying licenses/support, they will assist in getting backline support for you.
08-27-2020 03:44 AM - edited 08-27-2020 03:45 AM
Hi GertjanA,
yes, quite a strong decision, but it's not only about this issue. It's more about the whole picture: Too many problems in the last 8 years, that took quite long to get fixed or are not yet fixed. The Veritas support sometimes give us the feeling that they don't even know their own product very well, too much concentrating in finding the error somewhere else (AV, other Addins, etc.), instead of analyzing their own code or trying to reproduce it.
For example this tmp files issue we now have over a year without getting a solution from Veritas. It's simply embarrassing, at this point. Almost 9 months they were trying to blame our Antivirus software, which turned out not to be the problem. It's heavy time consuming, without getting results.