Exchange 2007 SP1 backup error V-79-57344-766
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
Comments
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
Uninstall and reinstall the MAPI/CDO on exchange server.
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
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.
Did you activate the mailbox of backup account by sending an email to that account
and then accessign the account through OWA or outlook
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. :(
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.
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?
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
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!
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
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.
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
...is a new installation on Exchange 2007 SP1 server machine going to solve this issue?
Dave
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
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
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.
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.
Same issue here!
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
Was having the same issue!!!
We were having the same issue where we were not able to use GRT on exchange 2007 when backing up to tape. (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.)
Backup Exec 12.5 Sp2 on Server 2003 Standard Sp2
Exchange 2007 Sp1 Enterprise on Server 2008 Sp2 Enterprise
I called support and theses are the steps they had me perform to resolve the issue:
--On Exchange 2007 open registry and browse to the following: HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\ESE
--Right click on ESE and select New --> DWORD
--Name the DWORD e2k7_mbox and set the Value Data to 1
--Restart BackupExec Agent Service on Exchange 2007 server (Verify that is is set to run using Local System as the Log On As)
--From within Backup Exec select Tools --> Options --> Microsoft Exchange and Check the box to Enable legacy mailbox support and select OK
--Select Tools --> Backup Exec Services and Restart all services
--Open Backup Selections list and expand exchange 2007 server
--Select Microsoft Exchange Mailboxes (An error about MAPI Permissions should appear)
--Create new Active Directory account with mailbox for use only with backup exec (If you already have as account as we did, delete and recreate. make sure that there are no other user accounts that share the first 5 letters of the username.). When creating the account make sure the user is a member of the domain admins group.
--Go into Exchange Management Console and add the user as an Exchange Organization Administrator Role (Open Exchange Management Console and select Organization Configuration. Select add and browse for the Backup Exec account just created)
--From within Backup Exec select Tools --> Backup Exec Services --> Services credentials. Check the box to Change service account information and enter in the newly created account info. Select OK and then restart all backup exec services.
--Open Backup Selections list and expand exchange 2007 server
--Select Microsoft Exchange Mailboxes only this time you should see all the mailboxes within the exchange 2007 server. (This is the old way backup exec used to backup mailboxes and is only used to test the MAPI access to the exchange 2007 server.)
--On Exchange 2007 open registry and browse to the following: HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec For Windows\Backup Exec\Engine\ESE
--Delete e2k7_mbox DWORD
--Restart BackupExec Agent Service on Exchange 2007 server
--From within Backup Exec select Tools --> Options --> Microsoft Exchange and uncheck the box to Enable legacy mailbox support and select OK
--Select Tools --> Backup Exec Services and Restart all services
--Open hosts file on Exchange 2007 server (C:\windows\system32\drivers\etc\) and create entries for both the exchange and backup exec servers. There should be two entries for each server (1 with onlye server name and the other using FQDN). Also the reference to IP v6 should be commented out. See example below (Where ***.***.***.*** is the actual IP address registered within DNS)...
# Copyright (c) 1993-2006 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost
#::1 localhost
127.0.0.1 Exchange Server Name
127.0.0.1 Exchange Server Name.Domain.com
***.***.***.*** Exchange Server Name
***.***.***.*** Exchange Server Name.Domain.com
***.***.***.*** Backup Exec Server Name
***.***.***.*** Backup Exec Server Name.Domain.com
After completing the steps above I was able to use GRT to backup Exchange 2007 mailboxes to tape.
Hopefully this also works for others.
-jwenson
Cudos to Vishal who is the symantec support rep who assisted with the fix.
Thanks a lot. These
Thanks a lot. These instructions really helped us. We did have to tweak them a little as follows:
1. We made the changes to the hosts file first and then restarted the server to ensure all services saw this.
2. We also made the BackupExec account a member of Enterprise Admins.
3. We went through the Logon Account Wizard to change the credentials of the BackupExec logon to the new account.
4. Not sure if we needed to do this but we retarted the server again just to make sure!
Then we were able to access the Exchange Mailboxes without the MAPI permissions error. Once past that, GRT worked fine.
Jwenson, I tried all the
Jwenson,
I tried all the options and did exactly the way you said in the above post. But still I am getting the MAPI error when selecting the exchange mail boxes. Please help!
Cheers
Jil
new user account solved our problem
I tried almost eveything mentioned, but the new user account (with rights) solved my problem
Would you like to reply?
Login or Register to post your comment.