cancel
Showing results for 
Search instead for 
Did you mean: 

EVS from Outlook add-in reporting "your search request failed" for all users

gillman7
Level 3

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...

1 ACCEPTED SOLUTION

Accepted Solutions

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.

https://social.technet.microsoft.com/Forums/ie/en-US/1896d727-c2b8-47b8-b648-0e1f8eee0b59/gpo-ie-use...

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!

View solution in original post

7 REPLIES 7

gillman7
Level 3

For additional details here, we are running on Windows Server 2012 R2, and the version of Enterprise Vault is 12.2.2.

Mouse
Moderator
Moderator
Partner    VIP    Accredited Certified

If it works outside Outlook but not when EVS is embedded, it's worth checking if this patchset might be a problem https://www.veritas.com/support/en_US/article.000128053

I've also seen this happening in 12.3 where the article claims it is fixed (it's critical to update the Add-In as well), but only after the second start of Outlook (on the first start, the Add-In seem to understand if it is running into the issue, then it puts a workaround in Registry but Outlook has to be restarted for the fix to work).

Thanks so much for the response and insight! We have had this registry setting for quite some time now (would argue that we were one of the first customers to report the issue with the Microsoft patches late 2017). Again, what's weird is that EVS will work for days without issue, then all of a sudden boom - won't allow remote users when using Outlook 2016, and will just resolve itself after some time without errors or warnings. Almost feels like some sort of WCF/remote connection threshold that is now being reached for some *new* reason...

@gillman7 We are having the exact same issue, Did you mange to resolve the issue. Any help suggestion would greatly help. I have spent over month with support and had no luck. Would really appriciate if you had any feedback. Thanks again.

SheldonDsouza
Level 4
Certified

Hi,

Saw this issue in another post which referenced this one.

Considering the fact you have an open ticket with Veritas, can I suggest moving a couple of users to different Provisioning Group and then create a different Desktop Policy affecting those users only. And then change the Search Behaviour and see the impact (especially when other users are facing the issue).Desktop_Policy_Search Behaviour.PNGThis may not be a solution to the issue but a decent workaround or a method of isolating (Subject to the fact that the users don't complain at all).

Regards,
Sheldon Dsouza

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.

https://social.technet.microsoft.com/Forums/ie/en-US/1896d727-c2b8-47b8-b648-0e1f8eee0b59/gpo-ie-use...

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!

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

That is an awesome find!

Can you mark your own answer as solution?

That way others can find it, and use it for their benefit.

Regards. Gertjan