cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange 2007 SP1 backup error V-79-57344-766

Chunda
Level 3

Getting the following error when trying to backup on an Exchange 2007 SP1 server, recently migrated from Exchange 2003, and upgraded to 12.5:

 

V-79-57344-766 - Cannot log on to MAPI with the specified credentials. Review the resource credentials for the job, and then run the job again.

 

Link to support knowledge base doesn't return any information?

 

I checked with OWA that I can send/received email using the account specified for backup. Its a member of the administrators group on the exchange server, also a domain admin, and also set as an Exchange administrator.

 

Installed CDO on Exchange server and tools on local server, permission test seems to work fine, only thing that seems strange is when selecting the server selection fro backup it takes maybe a minute before showing the storage groups for backup.

 

 

Any ideas?

 

Thanks

Paul

 

 

23 REPLIES 23

atlantika07
Level 2
Partner

Hello, i have the same error:

 

SRV 1: Exchange 2007 (singel) on Windows 2008 with SP1 and RU4 (64bit), MAPI CDO 1.2.1 GERMAN

SRV 2: Windows 2003 R2 32bit, Backup Exec 12.5, Echange System Manager 32bit GERMAN

 

Backup to a directory work, but is slow.

Backup to tape not work but is fast :)

 

By Kai

Anup
Level 6
Certified
Uninstall and reinstall the MAPI/CDO on exchange server.

atlantika07
Level 2
Partner

Hello,

 

i do:

 

- deinstall MAPI CDO 1.2.1 on Exchange 2007

- Restart Exchange Server

- install MAPI CDO 1.2.1 on Exchange 2007

- (Info: Exchange 2007 Server with Backup Exec 12.5 Agent)

- Test Backup on Tape : OK !!! (Thanks)

- Test Backup on File : slow but works, was with Backup Exec 12 not slow :(

 

Kai 

 

trafsta
Level 3

I have this same problem. With BE 12.0 SP1 I could do GRT Exchange backups to disk without issues, but GRT Exchange backups to tape never worked, so I just turned off GRT on our tape backups in hope that it would get fixed in the future.

 

Now that I've upgraded to BE 12.5 I've been told on an Experts Exchange post (http://www.experts-exchange.com/) that GRT to tape works perfectly, so I tested this out in our test environment and had no issues doing a GRT Exchange backup to a small tape drive. However, in our live environment, I am receiving the same error that other people here are receiving in a GRT Exchange backup to tape (to disk still works fine like it did under 12.0). This credentials error is different than the error I used to receive under 12.0, so it seems I am closer to getting this to work...

 

I have tried uninstalling MapiCDO 1.2.1, rebooted, downloaded latest from MS, installed, ran a GRT backup to tape and I am still recieving this error - however to disk STILL works... so its just an issue of backing up to tape. This doesn't make much sense to me considering the same exact credentials work when backing up to disk.

 

I have tried 3 different sets of credentials, and even created a new account and followed Symantec's instructions for granting the appropriate permissions to allow GRT Exchange backups, but to no avail

 

Any help would be greatly appreciated.

Anup
Level 6
Certified

Did you activate the mailbox of backup account by sending an email to that account

and then accessign the account through OWA or outlook 

trafsta
Level 3
I just tried doing that right now, same result when GRT backing up to Tape. When backing up to Disk, it works fine. Same backup job, same everything, just different destination. :(

Anup
Level 6
Certified

When backing up to disk , it does not check for all the credential requirements.

Make sure that the Mailbox is not hidden from global address list.

Also check the credentials once again.

1. Backup Exec logon account should have unique active mailbox. Activate the mailbox of Backup Exec "Logon Account" by sending an email to his account and accessing the mailbox for this account.

2. Backup Exec "Logon Account" should have Exchange Organization Administrators or Exchange Server Administrators role.
<http://support.veritas.com/docs/288777>
3. Ensure that the Backup Exec "Logon Account" being used to backup Exchange is a member of Domain Administrators
4. Verify that the Backup Exec "Logon Account" mailbox being used to backup Exchange is not hidden from the Global Address List
<http://support.veritas.com/docs/243328>
5. Verify that the Backup Exec "Logon Account" being used to backup Exchange is Unique within Exchange Organization
<http://support.veritas.com/docs/256537>
6. Verify that the Backup Exec "Logon Account" being used to backup Exchange is a member of Local Administrators Group on exchange server.

trafsta
Level 3

Hi Anup,

 

Thanks for your prompt responses. I have previously read all those support articles and have made sure all 6 steps you have listed have been done.

 

1) sent and received emails to a new account called "zibra" (I made a unique account name for this test account)

2) Zibra has "Exchange Orgainization Administrator" and "Exchange Server Administrator" perms, as well as "Exchange View-Only" perms (I've tried with and without the View-Only perms just in case)

3) Zibra is a member of the Domain Admins group

4) Zibra is visible in the global address list

5) Zibra is quite a unique name, we only have 5 user accounts here, none of which even start with a Z :)

6) Zibra is a member of the Local Administrators group on the Exchange Server

 

In case it helps, our Exchange server is Exchange 2007 SP1 w/ all rollups running on Windows Server 2008 Standard x64.

 

Any more ideas? :) Cause I'm seriously all ears (err, well, all eyes). Can I enable more details logging somewhere? Is there a text file log file somewhere that might show more debugging info? etc?

Anup
Level 6
Certified

There two methods

1)

How to use the SGMON utility in Backup Exec 11d for Windows Server (BEWS)

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

 

2)

How to enable or disable "debug logging" in Backup Exec for Windows Servers

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

 

How to enable Granular Restore (GRT) Debugging in Backup Exec for Windows Server (BEWS) 11d and above

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

trafsta
Level 3

I've logged a backup attempt using the -debug service parameters and will start looking through it now. Here is a link so anyone else can look at them at the same time :)

 

FYI I have removed any server names and replaced them with generic ones before posting these.

 

Here are the Log Files

 

Thanks in advance for your help!

Message Edited by trafsta on 10-22-2008 12:35 PM

smashp
Not applicable

Im getting the same error on a brand new deploy of BEWS 12.5

 

Fresh OS install Backup server running 12.5, Windows 2003 R2sp2 and has an IBM LTO 2 drive

 

New exchange server running Windows 2008x64 and Exchange 2007 sp1

 

Both The backup and the exchange server are at the same exchange patch point (rollout 3)

 

I have tried the mapi install/ uninstall garbage and it doesnt work

 

Backup to tape fails 100%

 

Backup to Disk works perfectly

 

Was using service account and switched it to use administrator account. No changes

 

Its a real bug people, symantec needs to get on the ball

trafsta
Level 3
Yup you have the same problem as I do smashp. It definitely is a bug, and they must know about it, and I would assume they're working on a fix. Hopefully it's fixed soon. The log files I posted may help in getting it fixed, I don't know... for now I'm just leaving GRT turned off when backing up to tape.

DD4v3
Level 2

Hi all, same problem over here: Fresh install of Windows server 2003 R2 x64 with BackupExec 12.5 64bit edition and Exchange agent; other Windows server 2003 x64 as Exchange 2007 server and MAPI Client and Collaboration Data Objects 1.2.1 instaled.

 

Cannot login with MAPI credential althought account used on both side is my Domin Administrator.

Cannot browse exchange folders from BE selection tool, got this error.

 

Tryed uninstall CDO, reboot exchange and then reinstall with no luck.

 

All other prerequisites (http://seer.entsupport.symantec.com/docs/311718.htm) are met.

 

Do I need to install CDO on BE Server too?

 

Any suggestion?

 

Is this deninitely a bug?

 

Thank you

 

Dave

DD4v3
Level 2

...is a new installation on Exchange 2007 SP1 server machine going to solve this issue?

 

Dave

mithrax
Level 3

I was having this same issue.  I did a test and i was able to backup only the exchange information store without getting an error.

So I created 2 backups one for exchange and one for the rest of the server.  Had the exchange backup  (overwrite media) run first with the second backup to start after a few minutes (append media terminate if no appendable media available) which waits till the first job is done.

No errors - see if this works for you

Felix_
Not applicable
Partner

I can see that I'm not the only one with this problem. Does anyone now when Symantec can release a fix? My backup job goes fine alone from disk to tape, but not when I'm combining it with other jobs. This is definitely a bug....

 

- Felix

 

mithrax
Level 3

this solved the issue for me on sbs 2008 server w/ 12.5
http://seer.entsupport.symantec.com/docs/305539.htm
The above error message may continue to occur even after having made the changes mentioned above if :
A.) Exchange 2007  is installed on a Windows 2008 machine
AND
B) In the resource order for the backup selection list Information Store is not the first resource to be backed up
AND
C) Backup job is targeted to tape device

Resolution:

To resolve the issue edit the backup selection list such that the Microsoft Information Store is the first resource to be backed up followed by the other local resources on the server.

shauncarter1
Level 2
This definitely looks like a problem with Exchange and 12.x. I have this issue with a reinstall of Backup Exec and the Mapi CDO. I'm going to run seperate backups for now.

kpeakman
Level 2
I am having the exact same issues here.

We are running E2K7 SP2 on Win2K3 servers in a SCR cluster with BE 12.5 fully patched and hotfixed. We have tried everything from the tips above and still the backups will fail. There's absolutely no pattern. Sometimes we'll go several nights in a row with the backups to tape completing and then we'll have a week of nightly backup failures.

At this point, we just leave the GRT option checked and hold our breath. If we get a failure notification, we'll log in and uncheck the GRT box and re-run the job. Our thought is that a backup that is hard to restore is better than no backup at all.

While I am almost ready to concede that this appears to be a bug with Symantec's product, I will admit that our SG's are large (some are pushing 160GB) and we are running in a SCR cluster which I believe is unsupported by Symantec. Until I can get management to let me re-build the servers into a CCR cluster with several, more evenly loaded SG's, I am using Quest Archive Manager to try and offload some of the data from Exchange

However, after reading the many post here and on other sites, it would appear that I would still have the same problem with backups when I get the SG's under control in a CCR.

The following statement by Symantec gives me little relief:

Symantec Corporation has acknowledged that the above-mentioned issue is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec Corporation is committed to product quality and satisfied customers.
There are no plans to address this issue by way of a patch or hotfix in the current or previous versions of the software at the present time. However, the issue is currently scheduled to be addressed in the next major revision of the product. Please be sure to refer back to this document periodically as any changes to the status of the defect will be reflected here