Restore of Exchange 2007 mailbox fails even after a successful backup

[jclifto]

We backup our Exchange 2007 information store nightly and everything has been going smooth.  I thought I'd test out the restore functionality on my personal mailbox and ran into a problem.  I deleted a useless email and went to a backup to restore it.  I receive the following message when attempting to restore the mail message:

Error category    : Resource Errors
Error             : e000848c - Unable to attach to a resource.  Make sure that all selected resources exist and are online, and then try again.  If the server or resource no longer exists, remove it from the selection list. Edit the selection list properties, click the View Selection D
For additional information regarding this error refer to link V-79-57344-33932

All account information is correct from what I can tell.  The backup and restore credentials are using the same account which is an administrator on the domain.  This is a big problem if we can't restore from our valid backups.

Anyone have any ideas?

Thanks!
Jaret Clifton
 

[Steve_W_]

Make sure that the Backup Exec services are running as the Administrator account.  Also verify that the Administrator account is an Exchange Organization Admin, has a mailbox, and is not hidden in the global address list. 

[jclifto]

The services are all set to run as the domain administrator account which is a member of the Exchange Organization Admin group and has a mailbox that is not hidden in the GAL. 

Please help!!!!  This product is USELESS TO US until this is resolved!

[jclifto]

This is absolutely pointless.  The documentation doesn't list all the requirements to get this to work.  The utility to change the logon for the services doesn't work correctly.  No matter what account I put in (all valid accounts) it says they don't exist.

If I edit the services manually, only one administrator level account is able to be used to start the service.  I created a new backup exec user and gave it admin rights on the domain, exchange org admin rights, local admin rights on the exchange server.  The services refuse to start under this account.

Why did we pay so much for the Exchange Agent if this product refuses to restore any data?!  Someone PLEASE point me in the direction of a solution.  This has been a giant waste of time and money.

[mdzale]

Hello Jaret,

try to copy only tape or only data needed for restore from that tape to disk. I think this will help you to do you restore fast, and then you can search for the real solution.

Good luck...
Marinko

[stelben]

Hi!

I have the same problem with 0xe000848c.
My admin account is an Exchange Org Admin, has a mailbox.
Speaking about the global address list... we don't have any DEFAULT global address list if that's what what you mean.
We are using address list segregation hosting several domains so the def glob address list is deleted.
Doesn't the software just connect to the mailbox name?

What is the solution?

Thanks

[jclifto]

Just as an FYI here is the resolution as I ended up calling Symantec and filing a case.

Since Exchange 2007 requires Windows Server 2008 and Server 2008 has IPV6 enabled, the communication for the RPC-over-HTTP Proxy were failing.  This is documented in article: 305539 -- http://support.veritas.com/docs/305539

======================================
Once this was addressed, restores succeeded. 
======================================

Now on to the service account startup problem.

The backup exec services refused to start under the newly created backup exec user that has a password that doesn't expire etc.  The account apparently didn't have the correct rights that can only be assigned by group policy object.  The rights needed were "Logon as a batch job" and "Create Token Objects".  This is documented in article: 302352 -- http://support.veritas.com/docs/302352

The services were able to be started under the newly created user and a restore of an email message was successful.

Note:  The "Backup Exec Remote Agent for Windows Systems" service needs to be run under the LOCAL SYSTEM account and not a custom domain user.  This is true for all remote systems as well, not just the backup server.

Hope this helps anyone else that had this similar problem.