Solution: Publish mail-enabled BE account in the GAL, as per this document. I'll leave my edits in place for troubleshooting purposes of other people.
Check the status of the Exchange VSS writer. From a CMD prompt, type VSSADMIN LIST WRITERS. A list of writers (including Exchange) will output. They should all be in {1} stable condition.
On the restore, make sure that you have the "Restore to Server" field properly populated.
EDIT: From here:
Ensure that GRT is enabled before you
run backups if you intend to be able
to restore individual items. You can
enable GRT for all backup jobs in
Tools > Options. Or you can enable GRT
for individual backup jobs on the
Backup Job Properties dialog.
Back up your current or most recent
GRT-enabled backup jobs to disk. It is
more convenient to work with
GRT-enabled jobs on the volumes that
do not have file size limitations. You
can create duplicate backup jobs and
send copies of your backups to tape
for archival purposes.
Use a backup-to-disk folder on a
volume that does not have file size
limitations as the destination for any
backups that are enabled for GRT. An
NTFS drive is an example of a volume
without file size limitations. Some
examples of volumes that have file
size limitations include FAT and FAT32
volumes.
Review the requirements for staging
locations in the Administrator's
Guide.
You must use a staging location for
GRT-enabled jobs in the following
scenarios:
You back up to or restore from a
volume with file size limitations.
You restore granular items from tape.
You run an offhost backup job.
Use a volume that is not your system
volume for a staging location. The
volume on which the staging location
resides should have at least as much
available space as the size of your
largest GRT-enabled backup job. You
can change the default staging
locations in the default backup and
restore option settings.
I'm going to have to look a little closer at BE2010 restore procedures, which will be later, but I would start with the above. Maybe it's because you're not staging it?
EDIT 2: Are you using incremental backups?
GRT restores will not work for individual mailboxes or items if the backup was to tape. From this document page 314:
Backup Exec must have access to a uniquely
named mailbox within the Exchange
organization for backup and restore of the
Information Store.
See “Requirements for accessing Exchange
mailboxes ” on page 1081.
You cannot restore individual mailboxes and
messages if both of the following conditions
exist:
■ The incremental or the differential
backup method was used.
■ The destination was a tape device.
If you create full, differential, or incremental
backups, GRT-enabled jobs have the
following restrictions:
■ The full, differential, and incremental job
templates must be part of a policy.
■ The destination device must be a
backup-to-disk folder.
■ The backup sets from the full,
differential, and incremental jobs must
be on the same volume.
Your strategy doesn't sound that bad to be honest, but the transaction logs not flushing does concern me somewhat. If you have other specific concerns about your setup, please edit your question to include them and I'll do my best to answer.
I read it that you're doing daily full backups. Depending on the size of your mailbox stores you might want to switch to daily incremental (i.e transaction log) backups instead of daily full backups. This will mean you complete your daily backups much quicker and they will consume less storage space, but this may not be an issue for you if you have small mailbox stores or the current backup window is acceptable.
Since you're using Backup Exec, make sure you are using the Exchange Agent. I won't stress that enough, since that's what does all the heavy lifting and makes sure your Information Store backups happen properly.
You say you're backing up all local volumes - specifically exclude the directories your mailbox stores and transaction logs live in from the file level backup. Hopefully Backup Exec won't be stupid enough to try and back these up.... but we are talking about Symantec after all!
As I said, I'd be concerned that your transaction logs aren't flushing. In the vast majority of cases this means backups are not completing properly, since the transaction logs are flushed after a backup. Check your Backup Exec job logs to see if your backups are actually completing successfully and investigate any warnings or errors. Your Exchange server should also log events relating to backups, so check out event viewer if necessary.
On a related note, make sure you do frequent Active Directory backups too. Exchange relies very heavily on Active Directory and stores an awful lot of configuration date in it.
I'll also do a quick spiel about your backups being effectively useless unless they are tested. I appreciate it isn't always possible, but if you can restore your entire environment (Active Directory and Exchange) to a completely isolated and different set of servers it will make you feel a lot better.
Best Answer
I resolved this issue finally. Symantec changed something is SP4 for BackupExec 12 that requires that you predicate the service account being used for backups to include the domain (i.e. domainname\service account). Changed to this topology and backups function properly