Same result, but let me throw out some more details, one which I didn't mentioned.
Testing: Added the registry entry as requested, restarted BEX services, created an Exchange only backup, ran it with GRT:on. From here on AOFO is disabled permanently, so I won't mention it. Same result. Tried doing a full format (not a quick) of the catridge thinking that might be the problem. No change. Same driver/catridge works fine with non-GRT backups for the last two weeks.
Here may be a clue: When the backup ran, here's what happened:
0-24 secs: Pre-Processing --- Drive accessed 12 times
24-30 secs: Queued ---- No drive activity
30secs -1:47: Snapshot Processing (this is the part I assumed was VSS executing) --- Drive accessed 6 times
At 2:00 minutes, the cycle repeated, identically, then failed the job. During this entire process, 0-bytes processed.
Again, bear in mind the non-GRT backups work fine to the same device.
So I ejected the catridge and followed the volume identifier in the registry, and deleted all references (mount points, etc), thinking perhaps it had become corrupted. Reinserted the cartridge, mount points were re-created in registry, ran test backup.
Same result. Since a standard USB hard-drive works fine, BEX starts processing immediately, I though this might be a rights issue. Default rights to the RDX is Everyone, full rights. I removed the rights, then explicitly gave Admins, Domain Admins and the BEX user account full rights. No change.
I went back and stepped through all options for Exchange in GRT, enabling/disabling one at a time (including using Passive/Active copy options) -- no change.
Now, the item I didn't mention.
When I performed the intiial GRT restore, I had to make a change to the BEX account. Specifically, I had to make the account visible in the Exchange Address Book and send an e-mail from the account. I'm very security conscious, and tend to not enable options unless I absolutely must. After performing the restore, I went back and removed the account from the Exchange Address Book. For the following two days (29th - 30th), I could not get a backup of Exchange in any format. The fix was to add the BEX account to the Exchange Address Book.
Could this last item be a key? Everything we do seems to point to some kind of rights issue.
The BEX account has full, explicit rights to the GRT folder (on the second volume, instead of default C:\TEMP) and to the RDX drive.
I ran the SymHelp tool. The only issues noted were:
- Incorrectly identified 2012 SBS as 2014
- BEX account was missing "Manage audit and security log" settings. However, account is part of Administrators group which has the right. That's strange.
Thanks again for your assistance.
Quite strange that non-GRT backups aren't successful either since this message usually relates to the "staging" part.
You missed my original post...GRT/AOFO disabled, backup worked.
What is the staging location set for backup under the backup setting - grt settings ? Have you tried running a backup to an alternate location without GRT and AOFO ?
..and that's why I posted, as I would not have thought of looking at the actual BEX settings (outside the job). I bet that's it...it's using C:\TEMP, but that folder hasn't been updated since the GRT restore. Trying that right now and will see how it goes.