Vault Cache not working

[Mx]

I have a case openwith Symantec Support for this but thought I would post this here as I havent heard back from them despite having logged this over 48 hours ago (sadly this appears to have become the standard over the past few months). That was after calling their UK support number and being asked if London was in Maidenhead... (At least it made me laugh)

Sorry, rant over.

The problem is with Vault Cache. It has been enabled for users and set to store the full item content however when users are offline and doubleckick archived items they are prompted wtih "Cannot contact the web server. Try again later. Unknown error 0x80072EEF"

I dtraced the client and it looks like it is trying to connect to the EV server to retrieve the items but it fails for obvious reasons. 

I confirmed that the vault cache mdc and db files have been created and currentyl occupy 4GB (max cache size is 12GB)

Whilst troubleshooting this I renamed the mdc to pst and mapped it to the user's mailbox. It turns out that it does not contain the full item but rather the a shortened version of it. I wonder if that is OK or whether it should have the full item given that the content strategy is set to "Store all items"

Here is part of the client dtrace that led me to believe that the client is trying to connect to the EV server instead of using the vault cache. 

~CShortcutItem::Display: 0x0

13/11/2012 16:31:48.598[4840]: Downloading: https://email.domain.com/enterprisevault/download.asp?VaultID=159DBA6A195386744A416DD6A1850A56811100...

13/11/2012 16:31:48.601[4840]: CDownloadSTA::DoDownload: 0x0

13/11/2012 16:31:48.602[4840]: CThreadManager::Add thread THID=5712

13/11/2012 16:31:48.602[4840]: DesktopCommonConfig::GetConfigValue: 0x0

13/11/2012 16:31:48.603[4840]: DesktopCommonConfig::GetSetting: 0x0

13/11/2012 16:31:48.603[4840]: DesktopCommonConfig::LoadSettingsFromHiddenMessage: 0x0

13/11/2012 16:31:48.604[4840]: ~DesktopCommonConfig::LoadSettingsFromHiddenMessage: 0x0

13/11/2012 16:31:48.605[4840]:     Desktop Setting: DOWNLOADSHORTCUTHIDEPROGRESS

13/11/2012 16:31:48.605[4840]:     No Value

13/11/2012 16:31:48.606[4840]: ~DesktopCommonConfig::GetSetting: 0x1

13/11/2012 16:31:48.606[4840]:  DOWNLOADSHORTCUTHIDEPROGRESS = 1 [default]

13/11/2012 16:31:48.607[4840]: ~DesktopCommonConfig::GetConfigValue: 0x1

13/11/2012 16:31:48.607[4840]: Download progress dialog delay set to 1 seconds.

13/11/2012 16:31:48.613[5712]: DesktopCommon::GetEVUserAgent: 0x0

13/11/2012 16:31:48.614[5712]: DesktopCommon::GetClientDLLVersion: 0x0

13/11/2012 16:31:48.620[5712]: ~DesktopCommon::GetClientDLLVersion: 0x0

13/11/2012 16:31:48.621[5712]: ~DesktopCommon::GetEVUserAgent: 0x0

13/11/2012 16:31:48.621[5712]: CInternetHelper::OpenURL

13/11/2012 16:31:48.623[5712]: DesktopCommon::GetIELanguageHeader: 0x0

13/11/2012 16:31:48.623[5712]: sHeader = [Accept-Language:en]

13/11/2012 16:31:48.624[5712]: ~DesktopCommon::GetIELanguageHeader: 0x0

13/11/2012 16:31:48.914[5712]: ~CInternetHelper::OpenURL

13/11/2012 16:31:48.915[5712]: CDownloadBytes::Complete

13/11/2012 16:31:48.915[4840]: CDownloadBytes::End

13/11/2012 16:31:48.916[4840]: Waiting for DownloadBytes thread, THID=5712 to exit

13/11/2012 16:31:48.916[5712]: ~CDownloadBytes::Complete

13/11/2012 16:31:48.917[5712]: CThreadManager::Remove thread THID=5712

13/11/2012 16:31:48.918[4840]: ~CDownloadBytes::End

13/11/2012 16:31:48.918[4840]: ~CDownloadSTA::DoDownload: 0x80072EEF

And here are the Vault Cache settings on the client:

OVDOWNLOADITEMAGELIMIT = 365

OVENABLED = 2

OVLOCKDOWNLOADITEMAGELIMIT = 1

OVMESSAGECLASSINCLUDE = IPM.Post*;IPM.Note*;IPM.Document*;IPM.Appointment*;

OVSETUPWIZARD = 0

OVSTARTDOWNLOADBTNVISIBLE = 1

Any ideas of where it could be going wrong?

[Rob_Wilcox1]

What version(s) of software are involved here? There was, if I recall correctly, a bug with the 8 SP 4 Outlook Add-in which meant it wouldn't use local content - it always went to the server. Try an 8 SP 5 client extension, or even better 9...

[Rob_Wilcox1]

Here is the reference about the client:

https://www-secure.symantec.com/connect/blogs/opening-archived-items-8-sp-4-client

[Prone2Typos · Accepted solution]

Also is this all items and after the VC stated it completed teh sync. I believe the first step is to pull the header information for an item and then to populate the headers with messages applicable to the restrictions placed on the settings. So when testing, you should a) make sure you are not on the busted client that Rob suggested 2) make sure you did a full sync of VC prior to testing and 3) try testing with newer items that are archived and most likely to be in the VC in the first place. 

If this is resolved... be it by Rob's posting or some other method... Please update the posting to reflect the solution and flag it accordingly. 

THanks in advanced. 

[Rob_Wilcox1]

Any further information needed?