Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Backup Exec 2012 does not support Enterprise Vault 10.0.3 agent backup

Created: 25 Mar 2013 • Updated: 01 Apr 2013 | 19 comments

So pretty pissed off right now. Maybe my own fault, maybe not.

I upgraded to Enterprise Vault 10.0.3 from 10.0.2 and my agent based vault backups start failing.

Go through a bunch of troubleshooting and then log a call with tech support.

Only to find BE 2012 does not support agent based backups for 10.0.3!!! are you kidding me!!.

Vault compatibility chart here says 10 is supported.

But tech support showed me this which says its only supported to 10 with SP2!!

are you kidding me symantec!!

Boy did I read the wrong document.

So the fix I got was "please down-grade" my Vault if I want this to work.

Why do I get the feeling symantec is just going to the dogs with its product line synergy.

 

Operating Systems:

Comments 19 CommentsJump to latest comment

AndrewB's picture

is there such thing as downgrading your EV? i have never heard of it. what did they say it would take to "support" 10.0.3? what's so different about it from 10.0.2? any chance the person you talked to didnt know exactly what the answer was? can you post the error you're getting and the troubleshooting you've done?

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner | www.trace3.com

teiva-boy's picture

Can you just run manual reg commands on EV to put the vaults into backup mode take them out?  I mean thats how it was done for years before there was an "agent for it."

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."

AndrewB's picture

since v8, it's done via powershell and the registry keys are no longer used to set backup mode. as a workaround you can do it until the issue is resolved.

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner | www.trace3.com

backupexecuser1's picture

I had what sounds like the same issue as the above poster and I wanted to update this thread for any other users who may run into this issue. 

Basically we had a case open with Symantec Vault support for 50 days before they identified the problem.  It turns out the 10.0.3 installer does not properly upgrade all vault components.  It turns out there were 7 copies of EVRT.dll on the Vault server, 6 with a version of 10.0.3 and 1 with a version of 10.0.2.  The 10.0.2 dll was being called again for some reason and wasn't upgraded properly during the upgrade process, despite following the upgrade documentation to a tee.  Once that dll was manually overwritten with a 10.0.3 version, backups using Backup Exec 2012 once again started working.

For those experiencing this issue, my vault case number was 04071150...have support look over the notes for that case and hopefully they can help you out.

StephenConnolly's picture

That's a lot of copies of EVRT.dll on one host. This is not something I've come across. To help us sort this out for you in the future, can you confirm the path of the DLL that didn't get upgraded.

Stephen

Stephen Connolly | Configuration Manager| Cofunds Ltd | LinkedIn

backupexecuser1's picture

The below EVRT.dll did not get upgraded:

E:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\EVRT.dll

SMack76's picture

We are also experiencing this issue and all of our EVRT.dll files are the same version.  Can someone from Symantec explain to me how a production version of Enterprise Vault was released in January of this year and it's still not supported by Backup Exec 12?   We're in the testing phase of the Vault product and my experience with support is steering me to the conclusion that we won't push this out globally.  How can you expect customers to buy the product when there is apparently no QA process between divisions of the same company?  

 

 

StephenConnolly's picture

Note also that for historic reasons the installer doesn't re-register the PowerShell snapins on upgrade. You should always re-run the EV ManagmentShell after upgrade to sort this out. Future versions of EV will be using PowerShell modules, which don't need a registry footprint.

Stephen Connolly | Configuration Manager| Cofunds Ltd | LinkedIn

StephenConnolly's picture

I've checked with the docs team to confirm whether this is a lacuna in the upgrade instructions. It looks like when you upgraded, the EV reports didn't get re-deployed to SQL server. The main server installer does not generally go out to external systems, so in the same way as you have to roll out the FSA Agent after upgrading the server, you need to re-run EVDeploy Reports to push the updated reports into the SQL Server reporting instance.

Stephen Connolly | Configuration Manager| Cofunds Ltd | LinkedIn

backupexecuser1's picture

Hi Stephen,

The SQL server is on the same box as the Vault Server.  In the installer, the checkbox to update the reporting services was checked (the support representative asked and confirmed this as well).

StephenConnolly's picture

I checked with Infodev. The Upgrade instructions have a section for reporting (round p88\chapter 12 in the current version) which mentions the additional step to perform to upgrade reporting. I agree it's not perfect but the instructions are there.

Installation (including upgrade) and configuration are two discrete steps.

Stephen Connolly | Configuration Manager| Cofunds Ltd | LinkedIn

backupexecuser1's picture

True, I do see that now.  Are you saying that configuration step would have replaced the EVRT.dll with the correct version?  That seems more like something that should have happened in the installation/upgrade phase rather than configuration phase.  I'd try it and see but I don't want to break anything again.

StephenConnolly's picture

I'm chasing up. It looks like we aren't doing a great job of distinguishing between clean install and upgrade use-cases.

Initial config requires you to provide a separate set of credentials for the reporting user and you must have run the main EV configuration before running the reporting configuration. So we made a pragmatic decision to not embed the reporting configuration inside the installer (We tried to do this in EV 7 and it was a mess). However for upgrades, EV is already configured, so in theory it should be OK to run the reports deployment tool in an upgrade mode during the installation so that you don't have to go back and run it manually.

This would likely require work from both the SQLreports and Install team for us to fix.

Meantime, you just have to remember to run the tool manually after you upgrade the rest of EV.

Stephen

Stephen Connolly | Configuration Manager| Cofunds Ltd | LinkedIn

backupexecuser1's picture

I appreciate you monitoring this thread, Stephen. 

I do think there is a problem somewhere.  While I do see now the area of documentation that was missed for the reporting services configuration update, this case took 50 days to resolve with tech support with hours of troubleshooting occurring.  If it took 50 days for tech support to find the issue, then I would conclude either the documentation needs some work to provide a better workflow (and like you said, distinguish better between clean install vs upgrade use-cases) or there is a problem on the support side (more prof devel or training needed, etc).  In addition, they solved the case by finding the out-of-date .dll file but they never pointed out the missing configuration step that you found.

I guess all in all what I'm saying is that I appreciate you taking a look at this case and following up with the appropriate teams.  I have the resolution now and am happy but I do feel bad for others who cannot get Backup Exec working with 10.0.3 possibly due to a similar issue like I had, either due to poor support or hard to follow documentation.

KeirL's picture

Hi

The way I read the above issue would suggest that an upgrade from 10.0.2 would cuase this issue, but what if I was doing a new install of 10.0.3 in a green field environment - would Backup Exec 2012 then work ok? (and be supported by Symantec)?

cheers K

 

Backup.Admin's picture

Hi

 

I checked Enterprise Vault compatability chart found that Enterprise Vault 10.0.0, 10.0.1, and 10.0.2 only for BE2012. Support for Enterprise Vault 10.0.3 is pending.

check page 23 and 24

http://www.symantec.com/business/support/index?page=content&id=TECH38537

Also Forum below as you issue

https://www-secure.symantec.com/connect/blogs/enterprise-vault-1003-reaches-general-availability

KeirL's picture

Many thanks - it seems there are parallel posts on this issue :o)

I'll keep an eye on both.

I guess my question was more about if it was just the 'upgrade' process that broke it? I've had personal (painful) experiences of upgrading 10.0.2 to 10.0.3 and BUE failing to work any longer (as above) but not yet tried an new install of 10,0,3 and seeing if that works ok with BUE2012...... the thread above indicates it might just work.

But - without Symantec support on 10.0.3 with BUE 2012 it would perhaps be foolish to install this combination anyway as Symantec will just play the 'not supported' card if there were any future issues.

SMack76's picture

I got in touch with support yesterday and did some testing.  We excluded the SQL components of the backup job and just selected the Vault Stores and the Indes.  The job ran correctly.

We are now going to run the job with all components selected and run debug to see if we can diagnose the issue.  I will update this thread as we progress.  Although not officially supported the Backup Exec team proceeded with diagnosing the issue as if it were supported.  

Stephen thanks for updating the thread, I'll check that out as well and report back. 

Thanks.

SMack76's picture

Our issue was resovled by deselecting the SQL components of the backup job and running the job by targeting only the Vault Stores and Indexes.  We then readded the SQL components and the job ran successfully.