cancel
Showing results for 
Search instead for 
Did you mean: 

Can't open Windows Search results if it's in the Vault Cache

PaTryptik
Level 4

Hi,

We're using EV 8.0.4.1991 for Exchange (2007) archiving.  The deployed Add-in is now 9.0.2.1169 on Windows 7 x64 with Outlook 2007/2010 x86.

When starting a search with Windows Search for words present in an archived email that I can see in my Virtual Vault, the email is found and shown in the search results, but I can't open it.  Double-clicking it or right-clicking and selecting Open does nothing.

Does anyone knows about this issue ?  Is there a fix for this ?

 

Thanks

Windows Search results window

1 ACCEPTED SOLUTION

Accepted Solutions

Rob_Wilcox1
Level 6
Partner

I understand.

It's a chicken and egg thing though to work out *why*...  Could do with the MSI log of the client installation to see why that DLL doesn't get registered properly... but if you run the setup again on a broken machine to get the log, it'll likely work a second time, or not do anything because you've already got it installed, so we can't (or would struggle) to get the MSI log :(

Working for cloudficient.com

View solution in original post

7 REPLIES 7

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

I believe this will be addressed by a future release: http://www.symantec.com/docs/TECH125425

- Windows 7 64-bit is supported with the 8.0 SP3 and later EV clients but this client version will not support integration with Windows Search via the EV search protocol handler (as described above).
This means that searches via the Windows Search interface will not include items located in Vault Cache.  Windows Search can continue to be used for indexing and searching other desktop content such as files and active email and does not need to be reconfigured in any way to support this configuration.  

At the moment this functionality is due to the lack of interaction between the 32-bit client and the 64-bit Windows Search interface. Integration with Windows Search will be provided in a future 64-bit EV client.

Paul_Grimshaw
Level 6
Employee Accredited Certified

PaTryptik
Level 4

Hi Tony,

I thought that this issue had been fixed with the 9.0.2.1169 release of the EV Add-in.  It is mentioning the

Etrack "2411179: WDS architecture changes to support 64 bit OS with 32 bit MAPI".

The article you mentioned is older than the release of this Add-in, so is it possible that it should have been addressed ?

 

Thanks Paul for your comment. 

However, as mentioned in my first post it is already this version that I'm using and this is why I'm asking those questions today.

Rob_Wilcox1
Level 6
Partner

I'm sure I've seen this, and discussed it before now with our Devs.  Let me check.

Working for cloudficient.com

Rob_Wilcox1
Level 6
Partner

So there are a couple of things that you can do .. in no particular order :

a/ Grab a copy of the VaultCachePH*.log file

This lives in the TEMP folder in a similar location to the EV Client log.  For example on my machine it's c:\users\robert_wilcox\AppData\Local\Temp

We can take a look at that, if you post it here.

b/ Reregister a couple of DLL's

Using an Admin command prompt go to c:\program files (x86)\enterprise vault\evclient

Do a regsvr32 vaultcacheindexer_en.dll

Go in to the x64 folder and repeat the same registration command

Working for cloudficient.com

PaTryptik
Level 4

Thank you so much Rob, reregistering these DLLs has done the trick !!!

You're a savior, do you know that !?  :D

As you surely already know, we cannot use the built-in Outlook Instant Search to search for words located past the 100th character in the body of an archived email, and I was told this is because of a limitation of that tool.  So we have to tell our users to use the Windows Search interface to run searches through all of their email locations, but what do we look like when they do so and face this issue I raised on that forum...  They were already mad at the archiving solution because of this limitation of the Instant Search and some other issues, and now the provided workaround fails for some users! :(

Rob_Wilcox1
Level 6
Partner

I understand.

It's a chicken and egg thing though to work out *why*...  Could do with the MSI log of the client installation to see why that DLL doesn't get registered properly... but if you run the setup again on a broken machine to get the log, it'll likely work a second time, or not do anything because you've already got it installed, so we can't (or would struggle) to get the MSI log :(

Working for cloudficient.com