Ok, we have our Vault setup so users cannot delete emails from their vault archive. But once in a while, Security gives us a high pri ticket where a virus has been archived and they're getting notified and we have to delete it. The only solution I've had so far is to export their vault to pst, unprovision the user, delete the vault store, open the pst and delete the email, reprovision the user, and import the new pst.
Today I decided that's really annoying and a long tedious process and there has to be a better way. So, I created a retention policy that I unchecked the box to prevent deletion of archived items in this catagory. Then I created a provisioning group for users that can delete and gave the provisioning group the new retention policy I just created and added the one user to the target of the provisioning group. I then disabled the user for vault and re-enabled them and synced their box. I checked the policies assigned to them and they were part of the new policy that is able to delete. I then granted the vault admin account full access to their vault archive and attempted to delete the email and no go. I also got to thinking... the message could be on any closed partition of the vault store they're on... so maybe it's read only. So, I changed the percentage to when it closes to 1% higher and opened all partitions for writing. Also made sure the vault store was not in backup mode. Can't delete it. Get the error
Reason: - The deletion of the item is not currently permitted.
I'm out of ideas...
These are the things to consider:
1. What storage do you use? Is it WORM?
2. Do you use DA/CA? Items may be on legal hold.
3. Site Settings/Archive Settings = "Users delete from their archives" is checked.
4. Desktop Policy = "Delete from Vault" is enabled (just in case).
5. Retention Categories = "Prevent automatic deletion of expired items with this category" and "Prevent user deletion of items with this category" must not be checked.
6. And yes, there should be some free space on the Vault Store partitions in case you use collection.
Let me know how it goes.
Everything Virgirl said is absolutely right; and I thought I could add another point or two here -
-The changes you made are great - for anything archived in the future.
-As archiving occurs, we "stamp" a retention category ID on each saveset. Just the ID. So if you were to change the "period" of that category, you could effectively change the retention of the items that have its ID stamped to them.
-It sounds like those savesets were archived and stamped with an RC that had the "never allow deletion of items with this RC. (Retention Category)" checkbox checked. Generally speaking, with MANUAL deletions, that's the only part of the category that would stop you. The period is generally a marker for Storage Expiry as a process to check against.
-No changing that without doing what you first mentioned you were doing. Essentially re-archving the item with a new RC.
-I can't advise you to do this without support's intervention, but there are SQL update statements that could stamp your new RC ID to the saveset in question. Again, VERY DANGEROUS if you don't consult support first.
-Of course you'll need to answer Virgirl's good points about the storage device (does it allow deletions?) and legal holds (are CA/DA or eDp/Clearwell blocking this operation?). Honestly it sounds like EV is saying no, and not the storage device, based on your error. And you can easily see if that saveset exists in the "holdsaveset" table of the vault store to rule out/confirm a legal hold.
Most of these are just to help you determine why it's being blocked; really the only thing to work around this (aside from your original, more annoying method) is to update the RC stamped on the saveset, which again is border-line unsupported and dangerous. It can be done though, with proper care and consideration.
If all conditions are right, and deletions can happen, a closed partition is ok to delete from. The factor that would make a partition "read-only" is backup mode. If that's toggled, you're not doing any deletions or any archiving. Anyway, definitely follow Virgil's good advice; just thought I'd add some comments to help understand why it might not be working; and that might be expected behavior. Hope this helps!
There are a lot of reasons that can prevent an item from being deleted. To find out which one applies in your situation, we would need a dtrace of StorageOnlineOpns while you perform the deletion. The logic dictating whether the deletion will be permitted can be found in a function called "IsDeletePermitted" so that would be my starting point for searching the dtrace.