EVS from Outlook add-in reporting "your search request failed" for all users
Since late November 2018, we have now had four unexplained outages for EVS, where all users receive "your search request failed" when visiting Enterprise Vault Search via Outlook. We have clients on both 12.0.1 and 12.2.2, and the issue is experienced on both versions. In the past, I was not able to identify the root cause (even after working with support on two different occasions now, surprise), and the past three times, was able to restart EnterpriseVaultAPI, EnterpriseVaultAPI32, and EVOnlineWebSearch application pools in IIS, then restart Net.Tcp Port Sharing service (and dependencies), and roughly 7-10 minutes later, all would be well again.
Recently, I have noticed an uptick again in DCOM errors, and had to re-add expected privileges to StorageOnlineOpns as well as DirectoryService, as the EVA no longer had launch or activation permissions. Today, we have incurred three hours (and counting) of end user service downtime for no reason, and there are no errors in any of our logs. Even stranger, I had found on the first instance of this issue that searches directly on Archives in VAC would work, and "Launch in a new window" would also work as these were OUTSIDE of Outlook and the quirky version of IE (or whatever is being used) to render the EVS page via the add-in.
Anyone else have this experience, and would like to share workarounds or additional troubleshooting thoughts? Have yet another open case with Veritas on this, but this issue is quickly becoming the nail in the coffin for our use of this archiving product...and blaming Microsoft for patching every time we open up an incident is becoming frustrating...
We finally DO have a solution for the issue we have had for almost 5 years. I was researching what might be causing this in our environment, based off of this article:
https://www.veritas.com/support/en_US/article.100014871
I started tracing what was being handled in both Group Policy, as well as what was being changed in the registry after Group Policy Preferences were evaluated via background refresh, and what I found when watching via ProcMon trace was that the 1a10 value was being thrashed between value data 3 vs value data of 1. After digging, I found that when the original IE11 Group Policy object was created, every single tab and setting was clicked on to evaluate what settings needed to be configured. According to the article below, this FOREVER guarantees that the GPO/GPP sets a value of 1, and the only way out is to recreate the GPO from scratch.
Well worth the 3 hours in my opinion as EVS has been stable ever since, and we have not had management screaming at us (for this issue, mind you). Hope this helps someone!
