Yes this is rather sad. I worked with Tech Support at length and told them that hotfix 143746 was the cause of the problem. The assured me that 143746 would be unbundled from the SP1 and that uninstalling 143746 and then installing SP1 when it came out would effectively block 143746 from installing again... Needless to say 143746 was bundled in SP1 and once you install SP1 you are SOL.
So here are two workaround a lot of people don't know about for the time being; these are hacks and YMMV.
Option (1)
Step (a) Create a second backup job that runs first; have it do a backup of just Exchange and have it do it to a Diskbased backup folder. Have GRT turned on for that backup. Diskbased backups do not appear affected by this bug; at least as of SP1. The backup will dump a copy of the Exchange files to an IMAGE directory. Set those diskbased backup folders to be overwritten each time you do a backup; so you can reclaim the space each backup run.
Step (b) Then have a second pass backup job that backups up everything but exchange, and backups up the disk based backup folder created in step (a).
Now if you have to restore exchange you can restore the disk based folder; configure it as a device; and catalog it. Once cataloged you can do a brick level restore from it.
Option (2)
Continue as your are with the GRT on; and the failed messages. If you need to do a restore. Do a DUPLICATE backup set job and duplicate your tape based back to a DiskBased Media folder. During the duplicate process the priv and pub edb which were backedup by the snapshots will be GRT'd during the copy process and the resulting copy of your backup can then be used for the brick level restores. We almost always do Exchange brick level restores this way because invariably the user doesn't tell you everything they need the first time and it much faster to do one duplicate job + a couple diskbased sub-restores; than it is to do multiple direct from tape restore. In fact backupexec is doing a transparent diskbased restores anytime you think you are doing a direct tape to exchange restore. So there is no loss in throughput to do it as a two step manual process.
What I still have to test is whether (a) if GRT is OFF, then will (b) the copy job from tape to disk-based folders have the GRT info in it. If that's the case I will turn GRT off so I can see REAL failures in the logs.
