cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to open archived items in a shared mailbox.

Dear Experts, a Weird problem:

I can open archived items in a number of shared mailboxes without any trouble at all.

However in one shared mailbox, the following process occurs.

I click on the item shortcut, this is followed by a dialogue box with a green progress bar and 'Enterprise Vault is retrieving your item.' and 'Your password may be required...'

A further 'Windows Security' dialogue box opens listing my domain\userid and requiring a password to be entered.

If I enter the password, the 'Windows Security' panel closes and reopens again with the same credentials (my credentials).

If I respond with a 'Cancel' instead of the password, I receive the content of the shortcut item, with a dark grey band containing the legend "This item was archived by Enterprise Vault on 14 June 2014 14:47:38" and "There was an error loading this item - some functionality may not be available".

If I click on View the original item, which is displayed in the body of the shortcut, as a link, I am again prompted with my domain\userid credentials.

I enter my password and receive the disappointing result of a new browser panel that contains the helpful legend 'Symantec Enterprise Vault - Error' on a yellow background with, on a new line: 'You do not have access to this vault'.

I have checked the access control rights for the shared mailbox - they appear to be correct. I checked the access control rights for the archive in Enterprise Vault via the VAC and they do not appear to be incorrect. [There are some users/ groups with automatically set access rights that I can neither change nor delete. I do not know how to use the oft referred to "zap process".I'm sure that it is simple if you've seen it used, but I've never seen it used !!]

This ocurrs for any archived item in this particular shared mailbox. I can still open archived items in other shared mailboxes.

I am clearly missing something obvious in this process. a touch of not seeing the wood for the trees, possibly.

Please put me on the path to joy and success ?

17 Replies

if you're asking how to zap a

if you're asking how to zap a mailbox, here you go:

How to remove (zap) Enterprise Vault (EV) properties from Archive-Enabled Exchange mailboxes

basically, you create an ini file with the parameters in the technote above (which is just a text file with the .ini extension saved in unicode using notepad.) then you run EVPM.exe which is in your EV app directory and follow the prompts.

Thanks for the pointer re

Thanks for the pointer re ZAPping.

However, I don't know if zapping the archive file really is the complete answer to this problem. It's something I've never done before and I'd appreciate advice on any other means of solving the access to this archive, in the event that zapping doesn't work.

It certainly appears like a

It certainly appears like a permissions problem. Try using premissions browser to see if they are different between the working / non-working cases.

 

https://support.symantec.com/en_US/article.TECH56331.html

Although that article is for public folders, you can view mailbox permissions too.

I suspect there will be some group on the problem mailbox with a "Deny" on it.

 

Andrew

Apologies for behiving like

Apologies for behiving like I'm unwilling to dive into a cold swimming pool, but...

I tried EVPM command string as follows:

EVPM -? -e Servername -m ServicemailboxAlias -f c:\temp\zapfile.ini

 

the zapfile contains:

[Directory]
DirectoryComputerName = Servername
Sitename=Siteappellation

[ArchivePermissions]
ArchiveName=Fred Bloggs
Zap=True

 

Command didn't succeed.

Do I need to 'fully qualify' the servername ? ie Servername.domain.uk, for example ?

you dont need -? in your

you dont need -? in your command. if you want to, just run EVPM.exe and it will prompt you for each variable to input

Hi Andrew. a big thankyou.

Hi Andrew.

a big thankyou. Using EVPM as you described was successful! Hooray!

All of the permissions were successfully removed as hoped, by EVPM.

 

However....

perhaps this was the wrong approach, but I tried it.

I disabled the problem archive in EV, allowed for a few minutes and then re-enabled the archive.I wanted to re-apply just the default permissions.

To my disappointment all of the permissions list that had been there prior to running EVPM re-appeared. As a result, it remains impossible to open an archived item in this mailbox's archive.

I guess I'll have to remove all permissions again with EVPM and manually add, one at a time, only the permissions I believe are required.

Appreciate your advice.

IS there a recommended way to

IS there a recommended way to avoid / prevent users or groups with 'automatically set' permissions from being re-added to the permissions list, if an archive is re-enabled ?

it sounds like the

it sounds like the permissions are inherited from Exchange/AD. this is an optional setting in the mailbox policy. unless you want to disable it for all your archives, what you might do is create a seperate provisioning group with its own policy and you can add accounts to it as necessary and then deal with the permissions manually.

I'm left wondering if I

I'm left wondering if I hadn't disabled and re-enabled the archive for this mailbox, would the unwanted accounts have reappeared ? I'm going to try zapping the archive again and manually adding just the accounts I believe are required.

Looking through the accounts

Looking through the accounts that I'd added back, after successfully running the zap a second time, I found one group with an anomalous name. I've tried renaming the account, which is a group in AD. I've corrected the anomaly in the group, its DL and its UNV entries, but so far no improvement in accessing the archived contents. Most frustrating.

Tried correcting the

Tried correcting the anomalous field in a group name - didn't make things worse, but didn't resolve the problem either. Recalled an odd problem that occurred when we had EV 7.5, where duff indices prevented access to archive files, so with that in mind, I rebuilt the index for the problem archive..... no change :catsad:

However, I did succeed in opening items in the archive, but only if I used the Service account for EV that holds the highest priveleges. If I use my own domain admin accounts, I get the same failure as the users.

I should point out that we have several AD domains. Our EV and Exchange servers reside in a resource domain. Our users accounts reside in another domain and between the two, we have linked accounts for access to Exchange mailboxes.

That said, if the behaviour I am encountering for this one shared mailbox could be blamed on the AD structure, then I wouldn't be able to open archived items in any other shared mailboxes!

This seems to be a problem with just one archive only and is driving me bananas.

I have viewed all of the Event logs on the EV server and in my own laptop but I cannot identify any related error events. It would seem to be overkill to raise a support call with yourselves for this issue, but I feel I've long run out of sensible ideas. It may be that I cannot now 'see the wood for the trees', I would like to take a step back and disregard the problem for a couple of days and return with a fresh and clear mind, but the users patience probably won't stretch that far...

Look forward to your further advice.

This sounds like it's to do

This sounds like it's to do with the sync'ed permissions, so forget about the archive permissions for a minute and concentrate on the mailboxes.

How are you controlling access to the shared mailboxes?

Are you using groups containing the mailbox accounts (i.e. resource domain) or user accounts (that they authenticate with)?

What is different about the access control to this one shared mailbox?

 

I have been thinking along

I have been thinking along the same lines and compared the access to other similar shared mailboxes.

I found one shared mailbox that had all but one of the same groups and individuals in its permissions, both 'full access' and 'send as' access with the exception of one group*. That shared mail box seems to be working fine. Indeed from the exchange perspective, both my problem mailbox and the other one allow access from outlook users. It is only the problem mailbox, where access to archived material is denied.

*That was the group which had some malformed field content that I corrected earlier this week. Sadly, that made no difference.

I propose to remove most of the groups and individuals today, via Exchange Management Console, Zap the archive (again) and add them back in, one at a time, after the weekend.

I am having a miserable time

I am having a miserable time with the archive for just one shared mailbox. The shared mailbox in Exchange has remained fully accessable for the users, but when they attempt to open a shortcut to item archived by EV 10.0.3, it fails as previously described. I have replaced their group, its UNV group and the DL group in the resource domain. Yes, they can still access the shared mailbox and its contents, but the situation remaiins the same for archived items when access is attempted either via a shortcut or via a weblink or via the Outlook 2007 EV search buttons. The result is always the same: failure.

Appreciate that this is an odd situation. I found an old post for EV 2007 that sounds similar, ( https://www-secure.symantec.com/connect/forums/vault-store-not-synchronising-permissions-exchange-se... ), but like an old-fashioned radio detective episode, the climax was approached but there was no link to the next episode where the thrilling conclusions could be found and understood @&£%@#~ Aaargh !

I'm sure I've missed something that the experts will blithely tell us starting.... "What you should have done was....." However, whatever it is, I admit it I cant see it, no matter what I do.

I guess I will have to log a support call, unless one of the renowned (sincerely) experts has a bright idea.

Meanwhile,  I will leave you all in peace as I'm on hols from tomorrow until June 1st.

                     

There's a thin chance that I

There's a thin chance that I might have identified a contributing factor.

I'd replacedthe AD group that contained the users who should have had access to the shared mailbox. I compared the AD groups with another mailbox that was functioing successfully and the only difference between them was the user access group.

Remember I couldn't open the archived items in the shared mbx, either ! I tried fiddling with the settings in my IE client and found one setting that looked promising: I went to tools... internet options... Security...  Local Intranet... custom level and changed a setting at the bottom of the list - User Authentication.

Mine was set to 'Prompt for user name and password'. This setting had been in place for several years and hadn't noticeably affected my access to EV archives in the past few years. I half expected the same error as before or something even more nasty, but to my surprise, when I changed this to 'Automatic logon with current user name and password', access was granted immediately. I've asked the user to try the same but he responded that it failed.

After a couple of days and a couple of similar attempts, it still works for me. I've passed the users problem to our deskside teams as the user is in a different country to visit and check out his settings. EV Server, Outlook client and EV Add-in appear to have been ruled out as problems. It looks very much to be a local user issue. Appreciate any thoughts comments in case I am missing any other fundamentals here. Thanks all for your patience and good humour.

 

What's your version of

What's your version of Exchange?

Are the permissions being inherited from further up the hierarchy rather than being set on the mailbox directly?

As mentioned previously,

As mentioned previously, we're using EV 10.0.3 on the server. The user I believe is using a ver 8 EV add-in, though I had asked him to try replacing it with the 10.0.3.1169, which is the add-in I'm using.

As regards permissions inheritance, it's conceivable that they're bein inherited from further up the heirarchy, but this is something that we've never needed to change for any other mailbox. As far as I know the permissions on this mailbox should be identical to all the other working mailboxes.