Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

No archived items are downloaded into Vault Cache.

Created: 16 Jan 2013 | 21 comments

Hi all,

We have been running Virtual Vault / Vault Cache on EV 8.0.5 on our environment for a while now. Everything is fine for the vast majority of users. I have come across a number of people who now find though they can see Virtual Vault on synchronising items are only downloaded into Vault Cache as they are opened from the mailbox using shortcuts created by archiving.

This perplexed me completely for some time, as I could not work out why some people were effected and some were not. So I moved my archive onto the same EV server as an effected user, and hey presto I now have the same issue as well. The sync 'finishes' and I can see Virtual Vault in my client, but nothing is downloaded into Vault Cache unless the items are opened while online. Once offline I have no access to the archived emails which I have not previously opened when online.

Has anyone come up against anything like this before? I have a case open with Symantec support, however progress has been so far extremely slow with analysis of client only logs happening 2.5 weeks into the case being open.

Thank you,

Jeremy.

 

 

 

 

 

 

 

 

 

 

Comments 21 CommentsJump to latest comment

Rob.Wilcox's picture

Have you got a cache location set on the properties of this EV Server?

JesusWept3's picture

Just going through the logs, so may be some time but right of the bat i see this

16/01/2013 15:27:27.866[4796]: CONTENT:DWNL:WEB: Acquiring INITIAL slot base URL 'http://d001evmbx02.axa-uk.intraxa/EnterpriseVault'
16/01/2013 15:27:27.867[4796]: CONTENT:DWNL:WEB: Acquiring INITIAL slot with page 'GetSlotWithServer.aspx' for DBID '1' from '0000-00-00' to '0000-00-00'
 

........

16/01/2013 15:27:27.918[4796]: CONTENT:DWNL:WEB: CCFetchContentCache::ProcessResponse: 0x0
16/01/2013 15:27:27.919[4796]: CONTENT:DWNL:WEB: Return text 'System.ArgumentOutOfRangeException: Year, Month, and Day parameters describe an un-representable DateTime.' code is '500'
16/01/2013 15:27:27.919[4796]: CONTENT:DWNL:WEB: ~CCFetchContentCache::ProcessResponse: 0x8000FFFF
16/01/2013 15:27:27.919[4796]: CONTENT:DWNL:WEB: ~CCFetchContentCache::StartDBCreationJob: 0x8000FFFF
16/01/2013 15:27:27.920[4796]: CONTENT:BUILD: CCDownloadContentCache::CheckWebServerConnection
16/01/2013 15:27:27.920[4796]: CONTENT:BUILD: ~CCDownloadContentCache::CheckWebServerConnection
16/01/2013 15:27:27.920[4796]: CONTENT:BUILD: ~CCDownloadContentCache::GetFullSlotWithServer: 0x8000FFFF
16/01/2013 15:27:27.921[4796]: CONTENT:BUILD: ~CCDownloadContentCache::CreateDownloadJob: 0x8000FFFF
16/01/2013 15:27:27.921[4796]: CONTENT:BUILD: ~CCDownloadContentCache::StartJobRunning: 0x8000FFFF
16/01/2013 15:27:27.921[4796]: CONTENT:BUILD: ~CCDownloadContentCache::StartFullDownload: 0x8000FFFF
 

It was mentioned briefly here: http://www.symantec.com/connect/forums/event-40966
But that solution wouldn't apply to you, so for some reason its requesting a completely invalid date time

My best suggestion for the moment would be to upgrade to the latest EV9 client (yours is SP2) and then point those lines out to symc support.

Will keep digging though

 

jprknight's picture

Hi Rob,

Yes each of the 7 EV email archiving servers we run have the cache location set on a low activity disk (generally used for PST imports). The disk has plenty of capacity on the offending server as well.

jprknight's picture

Hi JW,

Thanks for your time. I wil upgrade the client and see what I get.

J.

JesusWept3's picture

Yup, download the EV9 SP4 cumulative client hotfix from here:
http://www.symantec.com/business/support/index?page=content&id=TECH193522

Your issue is definitely the fact that its requesting a date range of 0000-00-00
You can see it in your registry as well where it keeps track of what jobs are occuring as well

One thing i did notice though, you have OVReset set to 1 in the registry?

JesusWept3's picture

ah sorry, was going off of the Late Breaking News Page

jprknight's picture

Bugger.

I have updated my client to the 9.0.4 linked above, reset my vault cache, and in my client log I still see:

CONTENT:DWNL:WEB: Acquiring INITIAL slot with page 'GetSlotWithServer.aspx' for DBID '1' from '0000-00-00' to '0000-00-00'

So same issue unfortunately.

I will update Symantec support with this information to see what they make of it.

Thanks.

Jeremy.

JesusWept3's picture

Just as a matter of interest can you change the OVReset key?

jprknight's picture

The OVReset is not in my \HKCU\Software\KVS\... tree anywhere.

I do see it set as 0 now though in the client log.

Ben Heymink's picture

Hmmm...looks like it might be picking up a pre-existing BITS job on the client; the server is correctly informing the client of the Archive range, but there looks to be a BITS job targeting 0000-00-00 to 0000-00-00. I imagine the client is being reset but somehow erroneously attempting to start that job again.

If it's not too much trouble, could you try the following? ( I know it's not ideal)

1) On an affected client, uninstall the Enterprise Vault Outlook Add-in

2) Delete HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault

3) Reinstall the client and see if it now synchronizes.

Hope this helps! I'll try and take a look at this issue on my machine here.

Ben Heymink's picture

.. or maybe use bitsadmin to delete the bits job?

The only reason I didn't suggest that is that I can't remember if it'll just get created again from the Registry Entry for that download.

jprknight's picture

Thanks for the suggestions.

I have done the process Ben suggested. No difference, so I have reset the vault cache and the sync is still running.

I am working on a VPN today, so this will take a while to finish, but it is looking better. The header mdc file has been fully created and I have a 265MB BITD555.tmp file. My feeling is if it was going to fail in the same way it would have done it by now already.

I will update when I know more.

Jeremy

JesusWept3's picture

I'm confused because you shouldn't have had to do a reset if you deleted the registry keys and then uninstalled and reinstalled the client (not just reinstall)??

jprknight's picture

The content sync stalled the same as it did before the uinstall, reg tree removal, and reinstall. So I reset vault cache and now content sync is running, I have all of the .db files etc being created in the temp folder you would expect to see as the client is downloading the content from the EV server.

jprknight's picture

Ok my client is now well on its way to downloading my archived emails.

@ Ben -- Is this an issue you are aware of? Is there a technote on the topic? I struggled to find anything specific on this issue, we have a number of people in our organisation who have seen this at one time or another. Also I was only able to reproduce the issue once I moved by archive from my normal EV server to the same EV server as an effected user.

 

Ben Heymink's picture

It is not a known issue I am aware of! I'm not entirely convinced it has anything to do with the server though - are they running different EV versions?

jprknight's picture

I know what you mean about it not being a server side issue. I think I was able to reproduce the issue perhaps because my vaultid or something changed when I moved my archive, rather than the issue was reproducable as a server issue.

In getting the sync doing more than it did before I have only done work on the client computers, nothing has changed on the servers.

All our EV servers are as identical as can be, all on the same build of Windows (2003 Enterprise x86), all on the same version of EV (8.0.5), etc.

So I am really the first person to come up against this issue?

GertjanA's picture

Checking old entries here.

Was there not an issue where if Vault Cache was being built, and you moved the archive to another server, VC got messed up? Cannot find a technote, but did find some other forum entries.

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS
Company: www.t2.nl

www.quadrotech-it.com

www.symantec.com/vision