cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual Vault's not syncing

wilsond3010
Level 6
Partner

We recently went through a upgrade from EV9 to EV10.4 but find some users unable to setup and sync to vault cache.

 

Only thing I am noticing in the logs in the. 

DisablePST is not set in the registry

Would this stop the vault cache from being created?

 

 

Registry Settings:
HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault
HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault\Client
 "FixedPreviewPane" = dword:0000000c
 "LastPSTSearch" = "20131224"
 "OVShowSyncDetails" = dword:00000001
 "OVSyncOnTop" = dword:00000000
 "OLBarState" = dword:00000000
 "NoPendingSaveMsg" = dword:00000001
 "LoggingLevel" = dword:80000003
HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault\Client\14414D5DCBBCD411820A00508B64CF34
 "OVRootDirectory" = "C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\"
 "OVStoreVersion" = "8.0.3.1857.0"
 "OVEnabled" = dword:00000001
 "OVStatus" = dword:00000004
 "OVStoreSize" = dword:0000a400
 "OVMDCLastSyncTime" = "2013-12-24T18:02:42"
 "OVMDCNextSyncTime" = "2013-12-24T16:58:10"
 "OVMDCLastGoodSyncTime" = ""
 "VirtualVaultConfiguredProfiles" = "Profile
HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault\Client\PSTsMarked
 
Directory Listing of Offline Vault:
24/12/2013 18:04:56.810[2568]: PVHelper::GetWorkingDirectory: 0x0
24/12/2013 18:04:56.810[2568]: PVHelper::GetRootDirectory: 0x0
24/12/2013 18:04:56.810[2568]: DesktopConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.810[2568]: DesktopCommonConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.810[2568]: ~DesktopCommonConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.810[2568]: ~DesktopConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.811[2568]: [Offline Config] Root Directory: C:\Documents and Settings\ecanfiel\Local Settings\Application Data\KVS\Enterprise Vault\
24/12/2013 18:04:56.811[2568]: ~PVHelper::GetRootDirectory: 0x0
24/12/2013 18:04:56.811[2568]: DesktopCommon::OpenDefaultStore: 0x0
24/12/2013 18:04:56.812[2568]: ~DesktopCommon::OpenDefaultStore: 0x0
24/12/2013 18:04:56.813[2568]: [Offline Config] Working Directory: C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\14414D5DCBBCD411820A00508B64CF34\
24/12/2013 18:04:56.813[2568]: ~PVHelper::GetWorkingDirectory: 0x0
C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\14414D5DCBBCD411820A00508B64CF34\100647E8D52D42E459128DEB5E5415E841110000evsite.mdc    12/24/2013  12:04    271360
C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\14414D5DCBBCD411820A00508B64CF34\1008C7D36AAD91447BB02DE274673D46C1110000evsite.mdc    12/24/2013  12:04    271360
C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\14414D5DCBBCD411820A00508B64CF34\1008DF4F2FF746B4E9FAF66C13E5CE6711110000evsite.mdc    12/24/2013  12:04    271360
C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\14414D5DCBBCD411820A00508B64CF34\100B6DBB6A010C741B31A72844DF6AC701110000evsite.mdc    12/24/2013  12:04    271360
C:\Documents and Settings\username\Local Settings\Application Data\KVS\Enterprise Vault\14414D5DCBBCD411820A00508B64CF34\100F1C53CB754DE49BF59343F17D3C8E01110000evsite.mdc    12/24/2013  12:04    271360
 

 
24/12/2013 18:04:56.880[2568]: DisablePST is not set in the registry
 

Mapisvc.inf File Contents:
[Services]  
LiveMeeting=Live Meeting Transport  
CRMSTORE=Microsoft Dynamics CRM  
MSCRM AB=Microsoft Dynamics CRM Address Book  
EVMSP=Virtual Vault  
MSFAX XP=Fax Mail Transport  
[LiveMeeting]  
Providers=LMXP  
PR_SERVICE_DLL_NAME=lmxp.dll  
PR_SERVICE_SUPPORT_FILES=lmxp.dll  
PR_SERVICE_DELETE_FILES=lmxp.dll  
PR_RESOURCE_FLAGS=SERVICE_SINGLE_COPY  
PR_SERVICE_ENTRY_NAME=ServiceEntry  
[LMXP]  
PR_PROVIDER_DLL_NAME=lmxp.dll  
PR_RESOURCE_TYPE=MAPI_TRANSPORT_PROVIDER  
PR_PROVIDER_DISPLAY=Live Meeting Transport  
[CRMSTORE]  
Providers=CRMSTOREP  
PR_SERVICE_DLL_NAME=CRMPRV.dll  
PR_SERVICE_SUPPORT_FILES=CRMPRV.dll  
PR_SERVICE_DELETE_FILES=CRMPRV.dll  
PR_SERVICE_ENTRY_NAME=MSServiceEntry  
PR_RESOURCE_FLAGS=SERVICE_SINGLE_COPY | SERVICE_NO_PRIMARY_IDENTITY  
[CRMSTOREP]  
PR_RESOURCE_TYPE=MAPI_STORE_PROVIDER  
PR_PROVIDER_DLL_NAME=CRMPRV.dll  
PR_PROVIDER_NAME=Microsoft Dynamics CRM  
PR_PROVIDER_DISPLAY=Microsoft Dynamics CRM  
PR_STORE_SUPPORT_MASK=STORE_CREATE_OK  
[MSCRM AB]  
Providers=MSCRM ABP  
PR_DISPLAY_NAME=Microsoft Dynamics CRM Address Book  
PR_SERVICE_DLL_NAME=CRMPRV.dll  
PR_SERVICE_SUPPORT_FILES=CRMPRV.dll  
PR_SERVICE_DELETE_FILES=CRMPRV.dll  
PR_SERVICE_ENTRY_NAME=ServiceEntry  
PR_RESOURCE_FLAGS=SERVICE_SINGLE_COPY | SERVICE_NO_PRIMARY_IDENTITY  
[MSCRM ABP]  
PR_RESOURCE_TYPE=MAPI_AB_PROVIDER  
PR_PROVIDER_DLL_NAME=CRMPRV.dll  
PR_PROVIDER_DISPLAY=Microsoft Dynamics CRM Address Book  
PR_STORE_SUPPORT_MASK=STORE_CREATE_OK | STORE_RESTRICTION_OK  
[EVMSP]  
PR_SERVICE_DLL_NAME=EVMSP.DLL  
PR_SERVICE_ENTRY_NAME=ServiceEntry  
PR_RESOURCE_FLAGS=SERVICE_NO_PRIMARY_IDENTITY  
Providers=MS_EVMSP  
PR_SERVICE_SUPPORT_FILES=EVMSP.DLL  
PR_SERVICE_DELETE_FILES=EVMSP.DLL  
[MS_EVMSP]  
PR_RESOURCE_TYPE=MAPI_STORE_PROVIDER  
PR_PROVIDER_DLL_NAME=EVMSP.DLL  
PR_RESOURCE_FLAGS=STATUS_NO_DEFAULT_STORE  
PR_DISPLAY_NAME=Virtual Vault  
PR_PROVIDER_DISPLAY=Virtual Vault Message Store Provider  
[MAPI]  
ServiceOrder=  
[Default Services]  
MSFAX XP=Fax Mail Transport  
[MSFAX XP]  
PR_RESOURCE_FLAGS=SERVICE_SINGLE_COPY|SERVICE_NO_PRIMARY_IDENTITY  
PR_SERVICE_ENTRY_NAME=ServiceEntry  
PR_SERVICE_SUPPORT_FILES=FXSXP.DLL  
PR_SERVICE_DLL_NAME=FXSXP.DLL  
Providers=MSFAX XPP  
PR_DISPLAY_NAME=Fax Mail Transport  
[MSFAX XPP]  
PR_PROVIDER_DISPLAY=Fax Mail Transport  
PR_DISPLAY_NAME=Fax Mail Transport  
PR_RESOURCE_FLAGS=STATUS_NO_DEFAULT_STORE  
PR_RESOURCE_TYPE=MAPI_TRANSPORT_PROVIDER  
PR_PROVIDER_DLL_NAME=FXSXP.DLL  
 
24/12/2013 18:04:56.901[2568]: PSTs disabled in Mapisvc.inf
24/12/2013 18:04:56.901[2568]: Unicode PSTs disabled in Mapisvc.inf
24/12/2013 18:04:56.901[2568]:  
24/12/2013 18:04:56.901[2568]: PVHelper::GetOnlineDatabaseList: 0x0
24/12/2013 18:04:56.902[2568]: DesktopConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.902[2568]: DesktopCommonConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.902[2568]: ~DesktopCommonConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.902[2568]: ~DesktopConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.902[2568]: ~PVHelper::GetOnlineDatabaseList: 0x0
24/12/2013 18:04:56.903[2568]: PVHelper::IsRemoveOVSet: 0x0
24/12/2013 18:04:56.903[2568]: ~PVHelper::IsRemoveOVSet: 0x0
24/12/2013 18:04:56.903[2568]: DesktopCommonConfig::GetConfigValue: 0x0
24/12/2013 18:04:56.903[2568]: DesktopCommonConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.903[2568]: ~DesktopCommonConfig::GetClientStoreKey: 0x0
24/12/2013 18:04:56.904[2568]: DesktopCommonConfig::GetSetting: 0x0
 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

So I found this:

 

Enterprise Vault creates MDC files for each additional Archive end users have access to regardless of the choice to synchronize the additional Archives into Vault Cache.

Article:TECH200200  |  Created: 2012-11-28  |  Updated: 2013-08-29  |  Article URL http://www.symantec.com/docs/TECH200200

Which means there was a server side fix for an issue in 10 sp4.

You do have those entries in the client log.  But then I found this in the Updates.htm in the Changes affecting Outlook users and requiring new Outlook Add-In section:

Users with access to a large number of archives experienced errors with Vault Cache synchronization [2983983]

This issue occurred when the Vault Cache advanced setting Synchronize archive types in the Exchange desktop policy was set to All mailbox archives or All mailbox and shared archives. The issue affected users with access to a large number of archives. Vault Cache synchronization failed and users experienced out of memory errors, even when the primary mailbox archive was the only archive selected for synchronization with Vault Cache.

This has been fixed. A user with access to a large number of archives can now successfully enable a few of them for Vault Cache synchronization. Errors may still occur if the user enables too many archives for Vault Cache synchronization.

It looks to me from the log the affected user has permission to a lot of archives. If that is the case you might consider pushing the new client out.


Regards,

 

View solution in original post

12 REPLIES 12

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

Do you have mutliple EV servers? Is the Cache location on each server ok?

Have grabbed a client trace yet?

wilsond3010
Level 6
Partner

I grabbed a client trace,

Only 1 EV Server and cache location looks ok

wilsond3010
Level 6
Partner

Here is a trace from original machine.

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

Did you move this users archive?

I see this:

HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault\Client\D0BD86CE2EDE7643AE06477851296DF3
 "OVRootDirectory" = "C:\Documents and Settings\***\Local Settings\Application Data\KVS\Enterprise Vault\"
 "OVStoreVersion" = "9.0.1.1038.0"
 "OVEnabled" = dword:00000001
 "OVStatus" = dword:00000004
 "OVMDCLastSyncTime" = "2013-06-13T17:19:29"
 "OVMDCNextSyncTime" = "2013-06-14T17:19:30"
 "OVMDCLastGoodSyncTime" = "2013-06-13T17:19:36"
HKEY_CURRENT_USER\SOFTWARE\KVS\Enterprise Vault\Client\FFE350D3D706FB42AEA38490E85E0F25
 "OVRootDirectory" = "C:\Documents and Settings\***\Local Settings\Application Data\KVS\Enterprise Vault\"
 "OVStoreVersion" = "9.0.1.1038.0"
 "OVEnabled" = dword:00000001
 "OVStatus" = dword:00000004
 "OVStoreSize" = dword:00009800
 "OVMDCLastSyncTime" = "2013-12-27T19:33:44"
 "OVMDCNextSyncTime" = "2013-12-28T18:47:09"
 "OVMDCLastGoodSyncTime" = ""

If you look in the OVRootDirectory do you see both folders there?  What size are they?

 "OVRootDirectory" = "C:\Documents and Settings\jdebray\Local Settings\Application Data\KVS\Enterprise Vault\"

wilsond3010
Level 6
Partner

No he's not moved but i did do a full reset of his vault and deleted the sub-folders under there it's about 125mb in size.

Not sure which of the 2 options fixed that mailbox.  either the disable and re-enabled mailbox or zapping him with the zap.ini

What is weird is the fact that no failed sync's showing on the client diagnostic's web page for vault caches.

-------------

Also any one had issues with the the disable pst being done via GPO instead of registery key?

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

Using the GPO will just set the registry key so that shouldn't be the problem.

I think that zapping the mailbox probably did the trick as it looked to me like it was looking for a different archive id.

Anyhow, glad your sorted now.  :)

wilsond3010
Level 6
Partner

Thanks Tony,

 

Yeh the problem I have is the GPO is setting the disable pst but when i run the vault cache it's still reporting it's not set

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

Ah ok, gotcha.  I worked with a customer recently on a different kind of project and they discovered their GPO was actually adding a space to the end of the registry key. I am not entirely sure how that happened for them but it might be worth looking at that to verify.

wilsond3010
Level 6
Partner

Tony,

 

This only started happening after the move to ev10 on a new server.

 

Wondering is it possible that when we put the original ev inplace. 

They did disable auto-archiving but didn't do the disablepst

However since all the clients went through a pst migration using the pst client and I believe it sets a flag once it's complete

Could it be that once migrated onto the new ev10.0.4 server that this was lost

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

Hmmm, that is a client side setting and I don't see how a server upgrade would change that. 

Did you upgrade the client's as well?  If yes, how?

wilsond3010
Level 6
Partner

clients where on what was told compatible version 9.0.1 or 3 I believe

so we haven't been forcing upgrades as yet

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

So I found this:

 

Enterprise Vault creates MDC files for each additional Archive end users have access to regardless of the choice to synchronize the additional Archives into Vault Cache.

Article:TECH200200  |  Created: 2012-11-28  |  Updated: 2013-08-29  |  Article URL http://www.symantec.com/docs/TECH200200

Which means there was a server side fix for an issue in 10 sp4.

You do have those entries in the client log.  But then I found this in the Updates.htm in the Changes affecting Outlook users and requiring new Outlook Add-In section:

Users with access to a large number of archives experienced errors with Vault Cache synchronization [2983983]

This issue occurred when the Vault Cache advanced setting Synchronize archive types in the Exchange desktop policy was set to All mailbox archives or All mailbox and shared archives. The issue affected users with access to a large number of archives. Vault Cache synchronization failed and users experienced out of memory errors, even when the primary mailbox archive was the only archive selected for synchronization with Vault Cache.

This has been fixed. A user with access to a large number of archives can now successfully enable a few of them for Vault Cache synchronization. Errors may still occur if the user enables too many archives for Vault Cache synchronization.

It looks to me from the log the affected user has permission to a lot of archives. If that is the case you might consider pushing the new client out.


Regards,