V-79-57344-33928 - Access Denied. Cannot backup directory Mailbox Store and its subdirectories.

[Paulo]

Can anyone help me with this issue? Our Exchange Backup To Disk fails everynight with the above error. When I look at the job log it is saying that it backed up 40GB (which is correct), but the job status is 'Failed', and the backup set is unuseable for restore purposes.

The strange thing here is that the B2D job was working fine, until last week. The account that is running the job is both a Domain Admin and a local admin on the Exchange Server. We are runnning Exchange 2003 Standard, and BE 11d on Win 2003 x64 Storage Server R2.

Regards

Paul.

[Wkelley]

Have you got to the bottom of this issue yet? i am also having the same problems.

And what do you mean when you say "An account which is e-mail enabled?"

Message Edited by Wkelley on 06-04-200706:21 AM

[The_Dude]

My backups are still working now, so I am most confused. :( I don't have any faith that they will continue to work is the problem!

[The_Dude]

An email enabled account is just that - an active directory user that has a exchange mailbox associated with it. On your exchange server, just right click the user in active directory users & computers and select exchange tasks and add a mailbox to it. I doubt that will fix it, but worth a shot.

[Paulo]

Yep, our exchange B2D jobs are working now ever since I removed the hotfixes. However, I have created a new posting relating to duplicate Exchange backups to Tape.

have any of you guys had problems with these? I am having to resort to doing an Exchange backup to disk without GRT enabled monday to thursday and then on friday I am going to do a GRT straight to tape. Not great to be honest, but it means that I will have good duplicates on tape, albeit without GRT.

Paul.

[Wkelley]

As we are on the 7170 Version we cannot roll back any updates to fix this issue. Is it a case of granting permisions to the Backup Account within Exchange??

We are going direct to tape with these backups and have noy been successfull at all. Any ideas would be great.

What a nightmare this issue seems!!!

[Dewser]

Has anyone put a call into Symantec on this?  Like Wkelley said, if you are using 7170 you cannot roll back any hotfixes since they have already been included.  There are hotfixes available for 7170 but we have not installed them.

[Wkelley]

I am currently on the phone to Symantec as i type. Hopefullly i will have a resolution or some update shortly on this!!

I have to wait up to 8 hours for a call back from a Tech Guy. I will keep you guys posted on this!

Message Edited by Wkelley on 06-04-200707:41 AM

[Dewser]

I too placed a call yesterday and have not heard back.  I just responded in another thread to someone who will be posting here soon I imagine :D

Anyway way, hope we find something soon.  My company and I have always been very positive with the Backup Exec software and we would like to continue using it, but if it can't do something simple like backup Exchange just like it did in the past, then we will have to try out alternatives.

[thegoolsby]

Hello,

There seem to be a number of issues being discussed on this thread, so I am going to do my best to touch them all.

First, I have been working to try and reproduce the issues that most you are seeing and have been unable to do so. I’ve tried many combinations or installing, uninstalling, and reinstalling hot fixes and have had no luck in reproducing the issue.

The first thing that I need everyone to check is that we are not dealing with any disabled Active Directory accounts. There is a known issue with Exchange GRT backups and this error message when backing up directly to tape when disabled accounts are present in Exchage.

The following tech note explains in detail the reasons behind the failures, and how to identify which account is causing the failure, should this be the cause of the error:

http://support.veritas.com/docs/286144

I would like everyone who is getting this message to follow the steps in the tech note and see if there are any disabled accounts which show there.

The reason the error occurs is that we use the MAPI interface to populate the catalog restore selections, and when a disabled account has not been purged, MAPI still has that disabled account information. When we go to access the account, since MAPI tells us the account is present, we get denied by Exchange when we try to access the account since the account is disabled in Active Directory. This causes the ‘access is denied’ error.

In addition, I need everyone to run legacy mailbox backup and see if they are able to run a successful MAPI Mailbox backup that does not yield any errors.

As for the Exchange 2007 issue, the access is denied from that backup appears to be due to a permissions issue. Please verify that the account being used to backup the Information Store is a member of the Exchange Organization Administrators.

For all Exchange backups, regardless of Exchange version, we need verify that the accounts being used to perform the backups have the proper configurations and rights. More on this can be found here:

Backup Exec 11d Best Practices Guide: Agent for Microsoft Exchange Server

http://support.veritas.com/docs/285753

The following comes from the Best Practices Guide:

For Exchange data protection and recovery to work successfully the user logon for Backup Exec must have an equivalent Windows Domain account that has administrative rights to the Exchange Server both locally, through the domain and on the Exchange objects as well. The account used must have rights to the Exchange server registry and file system. The user account must also have a mailbox that has been successfully initialized using a MAPI client.

This needs to be verified for all whom experience this issue.

I have sent some of you on this thread a personal message requesting some more information. For everyone, here is a sort of check list that we all need to check:

1. Perform the steps from http://support.veritas.com/docs/286144 and verify there are no accounts disabled.

2. Verify the account has the proper rights as per http://support.veritas.com/docs/285753.

3. Can a successful Legacy MAPI maibox be completed with no errors?

I would also like everyone here to know that we are here to assist for this issue, and that we are going to work with you to get this resolved.

[frnkblk]

Thanks, I be working through these today and report back to the forum.

Frank

[Dewser]

I too will look into the above items but usually if their is a disabled account the access denied message will reflect that account not the entire Mailbox Database.  We have the Log Reports configured to show files and directories and not just the summary.

[TeknaDan]

I'm having the same problem as everyone else here, and it's not related to a disabled user.  I can successfully backup my First Storage Group, which contains my user mailboxes.  However, I can't backup my Second Storage Group, which contains my Public Folder Database.  The backup user is an Exchange Organization Administrator.  I'm running Windows Serrver 2003 X64, Exchange 2007, and Symantec Backup Exec 11d Build7170.  The exact error message I'm getting is Access Denied.  Cannot backup directory Public Folder Database and its subdirectories.  Help!

Dan Kaufman

eSource Group

[thegoolsby]

Dan,

This sounds like a permissions issue with the Backup Exec account and the public folders. If you log into Windows using the backup user, are you able to access the public folders and modify the backup folders

We’re logging to each store the same way. If we’re blocked from one store, but can access the other, then something is different with the store we cannot access. We’re not going to log into one store differently then we do the other.

Have you reviewed the Best Practices Guide for Exchange and verified that you have all of the correct permissions indicated in the article (domain admin, local admin, admin rights on all Exchange objects)?

[Dewser]

Eureka!!  Totally going to blow your minds on this one!

A best practice is to use an account that is not your default administrator account, to back up your systems.  Well in some cases it is just easier to use that account since you end up giving the new account the same priveledges. 

Well today at the client that has the brand new install I checked to make sure there were no disabled accounts with mailboxes.  Checked to make sure the backup account (administrator) had a mailbox and it did.  But while checking the account properties under Exchange I saw that "Hide this from the address list" checked off.  I figured this was normal, and I guess its something that MS does by default now when creating the mailbox for the domain admin.  Unchecked the option.   I created a backup job to just backup Exchange and success!!!!

Just to make sure that it wasn't just the fact that the job ONLY was backing up Exchange I switched the account to hidden and reran the job and it failed with the error.

So if you are running 2007 and getting the failure in BE with Access Denied to the Mailbox Database, check to make sure your backup account first has a mailbox and that the account is not hidden from the address book.  Unfortunately for those of us who like to hide our tech accounts from view of the public, we will have to figure something else out.  Guess we can always limit who sends mail to those accounts. 

This seems to have worked at the other client I have as well.  In that case the engineer who was working on that for me recreated a backup account.

[frnkblk]

Yes, this requirement that the account NOT be hidden is discussed in at least one Symantec TID, but unhiding it never solved the problem.

Any chance that the fact that the Administrator mailbox (and most others) is hosted on an Exchange 2000 system could be a source of the backup problem for my Windows 2003 x64/Exchange 2007 setup?

Frank

[thegoolsby]

Frank,

The account has to be located on the 2007 server.

Please see the resolution for the follow tech note:

Attempt to restore the individual items from the Granular Restore Technology (GRT) based backups of Exchange 2007 fails with the unable to attach error.

http://support.veritas.com/docs/288508

[The_Dude]

Collin,

What do you mean by a "legacy" back-up of Exchange?

My problem has come back last night, after being good for a week. :(

Cheers!

[thegoolsby]

Legacy backups = mailbox backups.

To enable them, go to Tools > Options > Microsoft Exchange and select the ‘Enable legacy mailbox support).

You will then have to modify your selection list, and select the Microsoft Exchange Mailboxes and Public folders.

It’s very odd to hear that your backup works one day and not the next. Something has to be changing in the environment. We’re not going to backup one way one day, and then change our backup the next day. If something was configured incorrect, either on the Exchange or Backup Exec side, you would get this error 100% of the time.

Are you using LCR or CCR in Exchange?

I’d be interested to see what happens with a legacy mailbox backup when you get this error.

[frnkblk]

Well, that solved my problem.  Interesting how the error as described in 288508 ('Unable to attach to a resource. Make sure that all selected resources exists and are online, and then try again.') doesn't match all with what I was getting:

Backup- \\SERVER3\Microsoft Information Store\First Storage Group
V-79-57344-33928 - Access Denied. Cannot backup directory Mailbox Database and its subdirectories.

Backup- \\SERVER3\Microsoft Information Store\Second Storage Group
V-79-57344-33928 - Access Denied. Cannot backup directory Public Folder Database and its subdirecto...

I also see that the details listed in 288370 make mention of mixed environments, but the stated error message ('Unable to attach to a resource. Make sure that all selected resources exist and are online, and then try again.') also doesn't match the error message I received.  TID 288370 should be updated to mention Exchange 2000, too.

The only thing that's the same in all these TIDs is "0xe000848c".

I also want to recommend that TID 286144 be updated to include a reference that the Backup Account's mailbox must be on the local server. 

My follow up question is this: what if I use the same Domain account across multiple boxes, each running a copy of Backup Exec?  It sounds like it wouldn't work, such that I might want to use a local account rather than a Domain account?

Frank

Message Edited by frnkblk on 06-06-200701:35 PM

[thegoolsby]

Frank,

I understand that none of the errors mentioned in the tech notes were your particular error, however they were all caused by the same permissions issues. In all of these cases, yours included, Active Directory wasn’t allowing us stream the data from one store to another.

As for mixed environments, the user account should be backwards compatible. A 2007 account should be able to backup a 2003 or 2000 store, but the compatibility is not forward compatible.

As for the permissions for multiple Backup Exec installs, as long as the machines are attached to the domain you are going to need domain level rights. The local admin rights will not always have the proper permissions to backup certain Active Directory machines and components (Exchange included).

The following is from the Best Practices Guide (http://support.veritas.com/docs/285753:(

“For Exchange data protection and recovery to work successfully the user logon for Backup Exec must have an equivalent Windows Domain account that has administrative rights to the Exchange Server both locally, through the domain and on the Exchange objects as well. The account used must have rights to the Exchange server registry and file system. The user account must also have a mailbox that has been successfully initialized using a MAPI client.”

As long as all of these rights are set correctly in your environment, then the same user account should be able to backup every Exchange server in your environment. Since you use Exchange 2007 and 2000, the mailbox must reside in Exchange 2007. This holds true for any mixed environment with Exchange.

“I also want to recommend that TID 286144 be updated to include a reference that the Backup Account's mailbox must be on the local server.”

This does not hold true if the above permissions are set correctly.

Let me know if you have any questions.