Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

You do not have access to this vault- again

Created: 07 Aug 2012 • Updated: 15 Nov 2012 | 9 comments
Robert Primozic's picture
This issue has been solved. See solution.

Hi all

I have a strange problem just with a 7 users out of 400 (for now)... But before that, some background:

There are two separate AD forests with 2-way transitive trust. In first forest there is Exchange 2007 SP3 and EV 9.0.2 and AD 2003.  

In second, new forest, there is Exchange 2010 SP2, EV 10.0.1 and AD 2008R2

All users in new forest will be created from scratch. All mailboxes from Exchange 2007 were migrated to Exchange 2010 using Exchange 2010 tools. Right now the situation is that mailboxes are connected to new-created users but function as linked mailboxes for accounts in old forest. Archives from EV 9.0.2 will (some are already) be moved to EV 10.0.1 (using move archive task).

Now, there are some users to whome start to archive last week and they did not have any archive in old forest. Scheduled archiving works fine, but users can not access theri archived item. It prompts for username/password. But, none of combination is good, except a combination of EV 10.0.2 service account! If I click Cancel instead at last stage I got a page with yellow banner Symantec Enterprise Vault - Error: You do not have access to this vault. Opening archive explorer returns blank page and opening WebApp there is no possibility to select Vault.. All mailboxes were created iin same manner, but only this 7, new created archives has problems...

 

Any hint?

 

Comments 9 CommentsJump to latest comment

JesusWept3's picture

havve you actually looked at the permissions on their archives through permissions browser?

JesusWept3's picture

I don't think that's the guys issue

TypoProne's picture

Looks like you may have solved this ... if you have please note the appropriate postinng as the one that helped you to resolve it or please post the solution and mark it as such. This helps to ensure that resouces available to help are used wisely.

Many Thanks.

AndresMunoz's picture

Hi,

 

I'm experiencing the same issue, only my environment is slightly different

Source Forest

  • Exchange 2003
  • No EV

Target Forest

  • Exchange 2010 SP2
  • EV 10.0.1

There's a two way transitive forest trust between the forests

User accounts are located on forest A, while mailboxes are located on Forest B, as linked mailboxes. Users can access their mailbox withouth problem, and mailboxes get archived without problem, but the users are unable to access their archive, and receive the same error as the screenshots They don't get asked for credentials, etc.

When checking the archive permissions, the logon user (forestA\user) is not listed on the permissions, but other users that had permissions are.

A trace indicates

198 13:59:44.154  [4268] (w3wp) <4844> EV:L CBaseDirectoryServiceWrapper::CreateDirectoryService() - Entry [m_nNumTries = 40]
199 13:59:44.154  [4268] (w3wp) <4844> EV:L CBaseDirectoryServiceWrapper::CreateDirectoryService() - Successfully communicated with an EV Directory Service on the local machine
201 13:59:44.154  [4268] (w3wp) <4844> EV:L CBaseDirectoryServiceWrapper::CreateDirectoryService() - Entry [m_nNumTries = 40]
202 13:59:44.154  [4268] (w3wp) <4844> EV:L CBaseDirectoryServiceWrapper::CreateDirectoryService() - Successfully communicated with an EV Directory Service on the local machine
203 13:59:44.154  [4268] (w3wp) <4844> EV~W Event ID: 6287 Unable to fetch item from "evserver.fqdn.fake". |Reason: Access denied      (0xc0041801) |Saveset Id: 201211011745873~201206040214090000~Z~30634D37963295B47983377964551271 |Archive Name: UATDA4 (UATDA4)|Archive Folder Path: �Inbox�UXC�Meetings |Reference: [GOAFS] |
204 13:59:44.170  [4268] (w3wp) <4844> EV:H {CAutoStorageOnline::GetOnlineAttachmentFileSize} (Exit) Status: [Access denied      (0xc0041801)]
 

The following technote seems to be what the problem is (and the solution), but the hotfix is for 10.0.2, and if applied to 10.0.1, it breaks it... and floods event log with Event ID 6262, 6274 (sourceL storage restore) and 6265 (source: storage archive). An upgrade to 10.0.2 is currently out of the question (at this stage)

http://www.symantec.com/business/support/index?page=content&id=TECH198818

There's also the same hotfix for 9.0.4, but not for 10.0.1

Any suggestions, or ideas in the right direction?

 

TypoProne's picture

I would update to 10.0.2 personally... but if you cant your only option is to call support and provide them the TN and tell them your issue is the same and you need a HF for 10.0.1

 

If you are lucky... they will have one. If you are not ... they will not and you may have to supply business justification as to why they should make one when you can update to 10.0.2.

 

hope this helps and good luck.

 

Regards

SOLUTION
AndresMunoz's picture

Well, I recreated the problem on my lab... too easy.. I can confirm the bug exist on 10.0.1. I then upgraded to 10.0.2 and the problem remained, so I applied the hotfix above and voila... problem fixed.

So is up to write a business case, although this is a show stopper for our client, so I won't have much problem justifying the upgrade.

Thanks

donypie's picture

We had the same problem, updated to 10.0.2 appled the fix and problem is solved. I don't think the fix will be available for 10.0.1

 

Regards

TypoProne's picture

I guess that is one way to confirm the solution to an issue . OP if you have a sec to flag the solution and close this puppy down... it would be appreacated.

 

Regards