Backup Exec 12.5 - cannot restore individual Exchange mailbox using GRT

[rocketman]

Environment: Windows 2008 servers, one running Exchange 2007. Symantec Backup Exec 12.5 running on different server, with backups being done to disk. I get the following error message after the restore job fails during the initialization part -

"Final error: 0xe00084b7 - A backup set was created which contains no data. See the job log for details.

V-79-57344-33029 - Error - Mount failed.
Invalid Physical Volume Library Media Identifier.
V-79-57344-33029 - Unable to acquire device for the specified pool and media"

All of the literature surrounding these error messages suggest it's got something to do with the System Logon Account, but my SLA is all configured as per requirements. In fact, GRT object recovery works just fine when restoring an Active Directory object using same account, which lead me to believe it's something particular to the Exchange server. However, the SLA is a member of "Exchange Organization Administrator" group, and is also a "Exchange Server Administrator" on the local Exchange machine, it is able to logon as a batch job, it's an AD administrator account with a unique Exchange mailbox, address not hidden in Global Address List, etc. In the job setup window, in the "Resource Credentials" part under the "Source" section, the credentials seem to check out when I test them..

Exchange and Backup Exec seem to be mutually configured as per instructions - both have the same Management Console isntalled (Service Pack 2), remote agent seems ok..

The backups used to be done on tape until about 3 months ago, and this article suggests that it could be a driver issue with the tapes (though it seems to be directed at people who don't want to use the tape drives for their backups anymore, whereas we still want to use the tapes once in a while). I didn't try uninstalling the driver yet, do you guys think this will be necessary?

Please advise, much thanks

[Gurvinder]

Is your SLA and Backup Exec Service Account the same ? Can you launch SGMON,exe from BE Install Path. Select capture to file, beremote, bengine, device and media. Click on clear log. Start the Restore Job. When it fails paste or attach the log in the post here.

[rocketman]

Yes, the SLA and BESA is the same, and (for the most part) works fine for all backup and recovevry jobs, even recovering AD object using GRT.

I didn't see an option for "beremote" and "bengine" on the debug tool, so I just selected all the options; attached is the log. Much thanks

[VJware]

The debug log seems to have lines missing at the top, however these are the relevant ones:-

BEREMOTE: [12/03/14 08:51:31] [7028]     LogonUser failed for user:
BENGINE:  [12/03/14 08:51:31] [5632]     ERROR: 4 Error: Connection has not been authorized

Is the system logon account configured as the default logon account ? Was the password recently changed ? Try editing the account and re-enter the password.

Run the SymHelp Tool (http://www.symantec.com/business/support/index?page=content&id=TECH170752) to double-check the permissions.

If all the permissions come up right, try creating a new BE account and run the restore.

[rocketman]

Hi,

sorry for not checking in sooner;

VJware, I ran the SymHelp Tool, and indeed it seems that it's a problem having to do with backup account / credentials.

So I'm starting to think that I may not have setup the System Logon Account correctly. Here is the logon account screen accessed from the Network tab -

All of our backups are made from the "cozog" account name, which shares the same username (in the DOMAIN\USERNAME format) as the SLA account, which is why I figured that they are in effect the same.

Do both the backup and recovery job have to be made using the "System Logon Account" account name in order to implement GRT recovery of an Exchange mailbox?

If so I will have to revamp the whole backup configuration, which is fine, but I'd like to make sure.

[VJware]

It's simpler and preferred to have the same logon account (typically the default System Logon Account) for backups/restores.

Per the screenshot, the SLA doesn't seem to be set as Default. Try setting it as default, create a new restore job and check. If it still fails, try using a new account.
 

[rocketman]

You know what, I just ended up having to update the credentials (password) for the System Logon Account, to match the ones for the default account (cozog) and it ended up working. Sorry for being such a dolt.

Anyway thanks guys, you've been very helpful

[rocketman]

yeah i figure it'd be most simple to set the SLA as the default and do all jobs using that, but it still worked as per my configuration...

I'm probably gonna set up the SLA as the only account in the future for simplicity's sake. Thanks