This issue still exists - "tested" with SBS2008, BESR 2010 Version 22.214.171.124914. Posting into this thread is not possible anymore.
As this is a software you should *trust* in, this is ... ahm... interesting. In the end GRO is a major functionality worthless with broken Exchange and Sharepoint support.
It just seems as if Symantec has a huge problem with passwords all over: BE Agent for Linux does not work with encryption, too. Ticket open since June 2010 - and NOT solved in R2, as tech support stated last time they contacted us.
We cannot understand that problems like these exist for such a long time - are we the only company caring for data security in the form of encryption? Can't imagine that.
Ran into this problem yesterday for the first time - Need to recover a single, super-important Email.
And since I followed the BESR user manual best practices (p. 224)...
About the recommended use of Backup Exec System Recovery with
Additional backup applications are not needed to run with Backup Exec System
...my only option (as I see it) is to restore the entire exchange server into a lab environment and pull this Email from the database.
I Noticed that when I connect with GRO client to the server that holds the recovery points for my Exchange, I am presented with a password prompt for an old, no longer existing v2i file (_Drive015), where the oldest v2i around is _Drive021. Authentication failes, of course... See attched .jpg files.
This is a known issue: http://www.symantec.com/docs/TECH128501
Try the following to see if this helps:
Delete RPAM_cache.dat from C:\Documents and Settings\All Users\Application Data\Symantec\RPAM (or C:\ProgramData\Symantec\RPAM). Then try and open the recovery point using GRO again.
If this does not help, please open a case with Tech Support.
I started a same case a year ago https://www-secure.symantec.com/connect/forums/granular-restore-password-not-valid
The workaround as mentioned doesn't work for us.
I tried to open a support case (mysupport) to get the fix (see at the bottom of TECH128501). After putting in the full case a couple of times, we keep getting errors (with IE9 and Chrome). I give up, it cost too much time. How can I get the fix, so we can test this in a testenvironment?
The fix for this should be in BESR 2010 SP3 (9.0.3) - are you using this version?
If not, please update to 9.0.3 via LiveUpdate (reboot required) and try again.
Please let us know if this fixes the issue.
Thanks for your reply Chris.
I was exited to finally test the solution. After running live update and executing the work around, I opent GRO and select a backup from USB (2.0)
Then I put in my long password for the 128-bits AES encryption. The file doesn't open in a week! I aborted the process on our server. It's a HP Proliant server from 2007 with 8GB ram. Our Exchange database is 25GB.
It is faster to restore a BESR backup to an other pc/server and than export the mail via outlook.
Is there a better solution?
Not only have you had this problem for over a year in 2010 but you've got exactly the same problem in 2011.
I have no confidence in Symantec anymore. Your backup solutions are a farce. When you reach for your backups you are already in the crap and you need to know they are going to get you out of it. YOUR'S DONT.
It's not like this is the only product that is completely unreliable. I've also experienced bugs in your Backup Exec software that made it impossible to restore a Windows 2008 Server OS (got the data backup but had to setup the server OS - a DC to make things worse) from scratch. This bug was fixed but it was way too late for me and I will never get those days back now.
For the record, the deleting RPAM_Cache.dat fix "solves" the problem in 2011. The fact that you have had a "solution" for this for over a year but not fixed a piece of mission critical software just proves what a dire company you are.
@firstname.lastname@example.org: So it sounds as though the password issue is now resolved, right? The performance issue really is a different issue by the sounds of it. Are you able to just mount the recovery points (via windows explorer) on your server?
@TomT: to my knowledge, this issue should already be fixed in SSR 2011. What operating system are you seeing this issue on?
OK, some questions in order to narrow this down a bit:
I cannot reproduce this here so there is clearly something different between what you and I are doing.
Are you using GRO on the same machine that you are backing up? Was this an upgrade from BESR 2010? If yes, has the backup job been re-created since upgrading?
Any additional information you can provide is going to help.
We are using GRO on the same machine we are backing up. This isn't an upgrade, it was a clean install on a new server installation.
Without knowing how your software works and the mecanics of how that file is created it is difficult to know of any other information that may be useful.
TomT: do you have a support contract with Symantec? If yes, please open a new case for this issue so that we can investigate further.
If you decide to go this route, please let me know what the case ID is.
Running SR 2011 SP1.
Same problem re passwords.
Deleted the RPAM file, the password for the SERVERNAME_C_DRIVE file was accepted, but then it asked me for a password for the SERVERNAME_SYSTEM_RESERVED archive. The same job imaged both drives, so the password is the same. i.e. you can only have one password for each job, not on each source drive.
But alas, it will not accept the password.
Why does this happen version after version after version.....