Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Cannot see a folder in Archive Explorer

Created: 14 Mar 2013 • Updated: 05 May 2013 | 17 comments
This issue has been solved. See solution.

Dear all,

We have recently imported several PSTs for a customer into EV [10.0.3]. She is complaining that she cannot see the folder into which we imported the items. This folder is called "PST Archives".

When I gave myself R/O access to her archive, I *could* see the folder, so assumed it was something on her computer causing the problem. To troubleshoot, I've done the following, in no particular order:

*Upgrade EV Client to 10.0.3.

*Run ResetEVClient.exe.

*Separately emptied IE temporary internet files folder.

*Hif refresh from the context menu in Archive Explorer.

*Rebuilt indexes.

*Used OWA.

*Used a different computer.

She can see every folder except this one.

What else can I do to try to fix this?

Thanks

Richard

Operating Systems:

Comments 17 CommentsJump to latest comment

JesusWept3's picture

OK so first of all you've logged on and see the folder yourself when you give yourself permissions, correct?
And then you've seen yourself her Archive Explorer when she's logged in as herself?

How is the domain set up btw?
Does she have like DOMAINA\username and she connects to a mailbox in DOMAINB\herUser
(i.e. a resource domain type of configuration)

For what its worth, EV builds the AE view by the Archive Folder table, so indexing really doesn't help in this situation.

I think first, go to C:\Program Files (x86)\Enterprise Vault\PermissionsBrowser.exe
Find her archive, and then find the folder, and then look at the auto security to see what kind of permissions she does or does not have to the folder
 

rasobey's picture

It's a straight forward single domain.

I gave myself permission to access her archive, then verified in archive explorer on my own computer that I could see the archive, and the folder in question. No problems there.

I remotely connected to her machine to do all the troubleshooting, so it's 1st hand knowledge of the issue. No chinese whispers here :)

PErmissionsBrowser.exe - I'm going to presume this is on the server. I'll check it out!

Thanks JesusWept3. (Where are 1 and 2 btw? :) )

rasobey's picture

If I select the folder "PST Archives\", the permissions table on the right is empty, and the Auto/Manual radio buttons are greyed out.

JesusWept3's picture

Huh, thats really weird, so that would explain why she can't see the folder, because it has no permissions
Does the user have this folder in her outlook or did you opt not to create shortcuts?

I know this is going to sound really stupid
but can you create that folder \PST Archives\ in her outlook, archive a single item in it and then refresh Archive Explorer?

rasobey's picture

Not sure how it explains why *I* can see the folder though?!

We don't create shortcuts to imported PST items.

I'll get back to the user and do a manual archived after creating the folder. Do I need to wait for overnight backups to run?

JesusWept3's picture

You can see the folder because you gave yourself permissions at the archive level
If you gave her full permissions to the archive, she would see the folder too

Anywho, you don't need to wait for backups to run, it will be instant.
You will need to do the following

1. Open outlook
2. Create a folder in the same location with the same name as what you see in archive explorer
3. Copy a test item in to the folder
4. Hit store in vault
5. Then go to the Archiving task for that user and synchronize the mailbox including Folder Hierarchy and permissions
6. Go back to her machine and open Archive Explorer
7. Right click in the folders list on the left and click Refresh (not F5 or IE refresh but AE refresh)

You should now see the folder and the contents
and to be honest you might not even have to sync the mailbox, the manual archive should be enough

rasobey's picture

The PST Archives folder in PermissionsBrowser.exe now shows a full set of perms on the PST Archives folder. But not on the subfolders :( I'm just asking the customer now if she can see at least PST Archives.

rasobey's picture

Yup she can see PST Archives and the item I archived in it.

In terms of getting the rest of the hierarchy's permissions sorted out, any more advice would be appreciated.

One thing we haven't done is simply reimporting the items, but I don't want duplicates and neither do I want to have to try and delete what's already there.

JesusWept3's picture

so hold up, you can see the folder now, but you just see the item you imported, none of the others?!

rasobey's picture

Yup. Screenshot showing a subfolder still without permissions attached.

pstarchives.PNG
Tremaine's picture

From the looks of things it would appear that the AutoSecurityDesc failed to be populated correctly when importing these pst/s. Can you please confirm the exact process you used to import the PST's (settings as well, etc.). Additionally whether this occurs for any other users (if you have migrated any others or if you could test another one)?

You can run the following SQL against the EnterpriseVaultDirectory Database to validate whether the AutoSecurityDesc has been set correctly.

declare @ArcName nvarchar(100)
set @ArcName = 'AffectedUserName.'

Select Foldername, folderpath, AutoSecurityDesc from ArchiveFolderView
where ArchiveVEID in (select VaultEntryId from ArchiveView where ArchiveName = @ArcName)
and FolderPath like '%pst%'

If they are all indeed empty and you can reproduce this as well then we will need to provide a repair script as well as identify why this occuring so that we can address it going forward. In which case I would appreciate it if you could open a support case for this.

Thanks

rasobey's picture

Ghost, 

Thanks for the update.

The PST import (7 PST files) was done through right click archive > import PST. The migration settings we used are below:

 

PST Migration Report File
Start date & time: 27/02/2013    14:57:49
 
Migration Settings:
------------------------------
=> Migrate the 'Deleted items' folder
=> Delete migrated items from PSTs
=> The language of the PSTs is Western European (1252)
=> Hide each PST file after all items are migrated
=> Archive all calendar items, including those that have not expired
=> Folder structures will remain separate
=> Folder 'PST Archives' under the mailbox root folder corresponds to the root folder of the PST
 
A PST import done after this has appeared to work properly - no one else has complained that they cannot see imported items, so I think this is an isolated incident. At least, I could go through and check each one manually!
 
Let me run that SQL and get back to you.
rasobey's picture

Ok, I'm not sure what the expected output would be, but it was done twice:

set @ArcName = 'DomainUsername'

(0 row(s) affected)

set @ArcName = 'ArchiveDisplayName'

(737 row(s) affected)

 

I got my SQL admins to run the command. Is there anything else they need to do like generate a report or something?

rasobey's picture

Doh, never mind, the SQL guys have sent me a report to go with it. The folder "PST Archives" contains a long number that begins 0x010048.

Every other folder show NULL in the same column.

Edit: so should I open up a support case with my supplier here in the UK? I've gone through four imports we've done in the past couple of weeks, both before and after the upgrde to 10.0.3, and they all look fine apart from this individual one. Should I also tell them to refer to Symantec and this thread?

Richard

rasobey's picture

This was resolved by setting manual permissions to the archive for the user in question. So she ended up with full access set both automatically and manually. I'm not particularly happy that this is the right solution, but it is working.

Chris Warren's picture

As an alternative, you could try to run the EVPM script to clear the archive permissions and try resynching:

http://www.symantec.com/docs/TECH44818
How to remove all permissions from an archive using Enterprise Vault Policy Manager (EVPM).

 

Tremaine's picture

Hi Rasobey. Its not particularly the correct solution albeit it will work for the user in question. I can only speculate on what went wrong. Another option you can try is to create some test messages in the PST folder heirarchy and see whether they archive to the correct location and populate the automatic permissions as expected. Alternatively we could set the permissions on the all the subfolders to be the same as the parent for this one off. My primary question is whether the correct attributes have been set on the folder heirarchy created in the mailbox for EV's purposes. You would need to use something like MFCMapi or Outlook Spy to view the folder properties and correlate those against the entries in the Database. Best to open a support case if you wish to pursue this further.

SOLUTION