BackupExec 12.5 sp3 and Exchange 2007 GRT MAPI errors
BackupExec 12.5 has a technology for Exchange that they call GRT which allows for the granular backup and recovery of Exchange 2007 so that you do not have to recover an entire database in order to bring back a certain mailbox or message that was lost. In theory, this works great but unfortunately theory and reality are two different things.
I did an upgrade of BackupExec 12.5 to SP3 and before the upgrade GRT appeared to be working fine. However, after closer inspection, it wasn't really working but was not throwing errors either. The problem was that GRT uses a MAPI connection to your backup once it is on tape or disk to create the catalog of all of the mailboxes and the messages that are contained inside of them. If the account does not have full Exchange 2007 permissions on the organization or server, then this catalog process will fail with a MAPI credentials error. My original problem was that GRT was only working for a few mailboxes that actually had permissions to be logged in to from my backup account but for the vast majority it was failing. However, BackupExec relayed that the job was a success even though most of my mailboxes were failing to be indexed properly. This is obviously not good.
Once I upgraded to SP3, the problem got worse. Now, I was getting a MAPI error once the database and logs had been backed up and no indexing was taking place. I checked all of my permissions, created a new AD account with the appropriate permissions to exchange, and yet it still failed. Finally, I stumbled across an article that mentioned hardware compression as a possible culprit of the MAPI error since it was trying to log in to the image on the tape - why it does this is beyond me. I turned off hardware compression for this particular job, re-ran it and magically all of my indexes were created properly using MAPI and GRT.
I believe this to be a major bug in that you really need to verify all of the mailboxes are being indexed properly and Symantec needs to fix BackupExec so that it doesn't read the MAPI information from the backup media. This should be done against the actual database on disk in my opinion. Hopefully this will be fixed in a future release but for now, this should save you a lot of time that I went through this past weekend to solve this issue.
I did an upgrade of BackupExec 12.5 to SP3 and before the upgrade GRT appeared to be working fine. However, after closer inspection, it wasn't really working but was not throwing errors either. The problem was that GRT uses a MAPI connection to your backup once it is on tape or disk to create the catalog of all of the mailboxes and the messages that are contained inside of them. If the account does not have full Exchange 2007 permissions on the organization or server, then this catalog process will fail with a MAPI credentials error. My original problem was that GRT was only working for a few mailboxes that actually had permissions to be logged in to from my backup account but for the vast majority it was failing. However, BackupExec relayed that the job was a success even though most of my mailboxes were failing to be indexed properly. This is obviously not good.
Once I upgraded to SP3, the problem got worse. Now, I was getting a MAPI error once the database and logs had been backed up and no indexing was taking place. I checked all of my permissions, created a new AD account with the appropriate permissions to exchange, and yet it still failed. Finally, I stumbled across an article that mentioned hardware compression as a possible culprit of the MAPI error since it was trying to log in to the image on the tape - why it does this is beyond me. I turned off hardware compression for this particular job, re-ran it and magically all of my indexes were created properly using MAPI and GRT.
I believe this to be a major bug in that you really need to verify all of the mailboxes are being indexed properly and Symantec needs to fix BackupExec so that it doesn't read the MAPI information from the backup media. This should be done against the actual database on disk in my opinion. Hopefully this will be fixed in a future release but for now, this should save you a lot of time that I went through this past weekend to solve this issue.
posted by Rick Mitchell Solutions @ 9:14 AM
0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home