Looking to upgrade to from EV8SP2=>EV80SP3 and have only done so in our Test lab so far. We are seeing this same exact error post upgrade when trying to drag non-vaulted items into the Virtual Vault folders...
"You cannot modify items that are in Virtual Vault other than your own"
Similar error exceptions as posted in this thread above showing up in our EV client logs...
24/12/2009 17:37:42.576[4028]: EVMSP: <Inbox> [Folder::CreateMessage] IID: NONE, Flags: MAPI_DEFERRED_ERRORS
24/12/2009 17:37:42.577[4028]: EVMSP: <Inbox> [Policy::IsOpAllowed] Operation: InterStoreItemMoveOrCopyInToBeArchived, Allowed: false
24/12/2009 17:37:42.578[4028]: EVMSP: <Inbox> [Folder::CreateMessage] A COM error exception has been caught:80040119
24/12/2009 17:37:42.580[4028]: EVMSP: <Inbox> [Common::GetLastError] Returning text: You cannot modify items that are in a Virtual Vault other than your own.
24/12/2009 17:37:46.342[4028]: EVMSP: <Inbox> [Folder::CreateMessage] IID: NONE, Flags: MAPI_DEFERRED_ERRORS
24/12/2009 17:37:46.343[4028]: EVMSP: <Inbox> [Policy::IsOpAllowed] Operation: InterStoreItemMoveOrCopyInToBeArchived, Allowed: false
24/12/2009 17:37:46.344[4028]: EVMSP: <Inbox> [Folder::CreateMessage] A COM error exception has been caught:80040119
24/12/2009 17:37:46.345[4028]: EVMSP: <Inbox> [Common::GetLastError] Returning text: You cannot modify items that are in a Virtual Vault other than your own.
I do not know where you can even edit the "InterStoreItemMoveOrCopyInToBeArchived" setting as it is not tied to any of the new VVault Desktop policy options that I see. The closest thing is "VVAllowIntraStoreCopy" which is the "Users can copy items within their archive" option under the VV desktop policy. We have that set to yes.
The fix for us was to perform a Reset on the users VaultCache. After restarting Outlook and re-synching VC, we were then able to drag items into the VC folder. Nothing was changed in any policy and we did not re-synch any accounts. Now the client logs show TRUE for that "InterStoreItemMoveOrCopyInToBeArchived" setting...
24/12/2009 18:30:09.295[1532]: EVMSP: <Inbox> [Folder::CreateMessage] IID: NONE, Flags: MAPI_DEFERRED_ERRORS
24/12/2009 18:30:09.296[1532]: EVMSP: <Inbox> [Policy::IsOpAllowed] Operation: InterStoreItemMoveOrCopyInToBeArchived, Allowed: true
24/12/2009 18:30:10.328[ 220]: CONTENT:BUILD: Completed INITIAL Job filename '2009_01_03_0006.db' state '1'
We were able to duplicate this behavior on 2 separate accounts, via two separate test machines. Both test users had fully synched/working Vault caches prior to the upgrade.
Is this a known issue with Virtual Vault? Do we need all of our users to reset their existing VCache in order to be able to take adavantage of the promised drag and drop feature of Virtual Vault?