01-31-2011 09:41 AM
This issue still exists - "tested" with SBS2008, BESR 2010 Version 18.104.22.168914. 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.
02-01-2011 12:39 AM
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.
02-01-2011 03:46 AM
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.
07-06-2011 02:40 AM
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?
07-06-2011 03:55 AM
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.
07-19-2011 04:20 AM
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?
07-19-2011 04:24 AM
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.
07-19-2011 04:51 AM
@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?
07-19-2011 04:58 AM
I have also checked that there are no updates available
07-22-2011 07:13 AM
Have you confirmed that this is still an issue still in the 2011 version?
07-22-2011 07:35 AM
This should be fixed in 2011.
However, based on your earlier reply, it sounds as though it is not.
Are you able to easily reproduce this with 2011?
07-24-2011 03:58 AM
I've done another backup and exactly the same problem.
Had to delete RPAM_Cache.dat for it to accept password doing a granular restore.
07-25-2011 12:54 AM
OK, some questions in order to narrow this down a bit:
07-25-2011 01:22 AM
1. Windows Server 2008 R2
2. External SATA drive (system sees it as a a standard hard drive)
3. 8 Characters
4. Yes, Standard 128bit
07-25-2011 04:13 AM
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.
07-25-2011 11:38 PM
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.
07-26-2011 01:23 AM
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.
12-08-2011 08:31 PM
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.....