I have the same issue as described here:
I did what is suggested (delete user row from OWS_UserPreferences table) - this solved the issue, for exactly 2 days.
I had to delete it again today - any ideas how to search for the root cause of this issue?
Solved! Go to Solution.
That would be me :)
I suggest to log a case with Symantec, and mention my case : 08481332
That might help. We (Symantec and me) are still not sure where it comes from, but it might be due to some sort of corruption in an archive. I've investigated every user getting this error, and they have little to nothing in common, except several of them are in the same department. However, not enough to determine that as the common factor.
It is still under investigation. We now look at Vault Store database index fragmentation, but there does not seem to be a direct cause to be found (yet)
I will be able to open a ticket only in a week from now...
One thing that was interesting - I also got the Vault Store database index fragmentation message...
So - this might have something to do with it.
Anyway - I'll be back at the office next monday and I;ll make sure to open a case about it.
FYI - I've been working on this with support for a few weeks now. We're focussing on 1 archive in particular, as that showed in the dtrace as possible culprit. We ran an EVSVR on this one archive. IT has been running for 7 days, then was stopped by me. Support confirmed EVSVR was still doing things, but at a minimal rate (like 250 items an hour). We then checked the fragmentation level, and found that for this one VaultStore, the index for the watchfile was 99% fragmented. Some others also are high. I've now opened an internal support ticket to the DBA team, to make sure indexes are defragged, and/or recreated. According to them, there is an automated task that should do this, but apparently it is not working well.
I will report back on my Forum entry what the result is.
Did you get a ticket opened, and did you get any updates?
FYI, I am working with one of the engineers on this. It is currently unreproducable on their side.
after tracing etc, it seems it has to do something with an archive with many (8000+) folders). To workaround, we had the affected users configure the preferences in the new search to open on their inbox folder. That prevents a scan of other folders of other archives. It is obviously still possible to perform a search in any archive the user has access to.
I did open a ticket, number 08819506
I run the sql query to list the folders at the user who keeps having this issue, and she only have 231 folders.
HOWEVER... I did notice the she have 2 identical folder names under the root folder. for some reason she have 2 "sent items" folders under the root folder, one with folder icon 9 (original mailbox folder) and one with folder icon 0 (manually created or with some 3rd party tool)
I do know that identical folder names under same parent folder causes issues, so I wondering if the search is loading the folder structure from the ArchiveFolderView and just outputs this error of "user does'nt have permissions to any archive" cause Symantec didn't create a specific error for this issue.
BTW - usually I just find this identical folder issue when I get directory error and some other errors in the event viewer and I dtrace the archive task until I hit this error in the trace..
Any chance you can filter the ArchiveFolderView results for the user you have with over 8000 folders to see if he have identical folder name under the same ParentFolderRootIdentity?
I'm quite sure this is the cause in my case...
I do not have those events (I know which you mean).
I do see (working with Symantec) that there is a duplicate foldername way down.
The trace shows it hangs on the last Name folder, then throws error.
Duplicate folder name under same folder root?
I'm going to rename on of the duplicate folders, can't say if this will solve, Symantec thinks this is not the issue, but it shouldn't be there anyway.