Regarding virtual vault and read only vault stores

[FlyingBus]

Hi all, 

I'm currently testing the virtual vault after a successful upgrade to SP3. I'm a little confused about the interactions with Closed partitions. We currently have 1 EV server and 4 partitions for exchange archiving. 1 is open and the other 3 are read only as standard. When permissions to delete are given, how does the system handle users removing/rearranging items that are in the read only stores? 

I'm sure this is covered in the documentation somewhere but I can't really find it and probably searching on the wrong terms. An example. 

1.   I look at an item in the virtual vault that is from 2005, this is definitely contained in one of our read only partitions. I decide it's highly personal and don't want this in the archive so I delete it. This appears to work in            testing... should it not fail since the store is read only that it's pulling things from? 

2. one of my test users renamed a folder in his virtual vault. Now the vault event log is filling up with this error

Archive folder path: \AOLS 

Vault Id: 133B07F45595F7742AF55F90AAE60B89A1110000vault but does not have permission(s) (Control folder). 

A frequent cause of this Warning is a user attempting an operation on a forwarded, moved, or copied shortcut to a Vault for which they do not have the required permission(s). 

so I guess my question is, when users are given the permissions to reorganise and delete, how then does the virtual vault handle these requests when the emails reside on closed partitions? 

 

[RichardG · Accepted solution]

I think the two issues are separate.

1. Closed partitions are not "read only", items can still be deleted via retention expiry, archive explorer, virtual vault, etc.

2. It sounds like some strange permissions have been synchronized from the mailbox to the archive folder. You can view the archive folder permissions with PermissionBrowser.exe in the EV install directory. If this folder does not currently exist in the mailbox then it may be possible to rectify the situation by creating a new folder called AOLS at the root of the mailbox and using the archive task synchronization tab to sync the folder hierarchy and permissions for this particular mailbox.


 

[JesusWept3]

for number 2 i have that issue from time to time and it just seems to fix itself and go away

[FlyingBus]

ah ok good to know regarding the deleted items etc. Thought that was the case, but couldn't find a document explicitly stating that.

JesusWept2 - also correct this error seemed to disappear yesterday in this specific folder after a while. is now gone and for the user it definitely appears to be solved.

thanks guys.