Symantec’s Atrocious Support of a Terrible Product: Backup Exec 2012

By on Jul 13, 2012 in Blog Posts, Software | 19 comments

Share On GoogleShare On FacebookShare On Twitter

Update: For those looking for a replacement, I’ve reviewed two options here.


For years, the name Symantec has been synonymous with two areas; anti-virus software and enterprise backup systems. In 1990, Symantec purchased Norton and with it still holds the title as best-selling anti-virus software in the world, although it has long since lost its claim as the best product on the market.

Though Symantec has lost its footing on the security side of its business, they have been able to cling on in the enterprise backup scene; at least for the time being. Their Backup Exec (BE) products (purchased from VERITAS in 2005) remain popular with small to medium sized businesses, but the recent decision by Symantec to require maintenance agreements and completely redesign the program have left many customers without a reason to remain loyal.

Less than a year ago I could purchase a brand new copy of Backup Exec 2012 for Windows Servers for $381.00, which was all I wanted. I don’t need the maintenance contract or additional support. I’ve never had to call Symantec for anything other than help un-installing their products. However, in their infinite wisdom Symantec has now decided that all new versions of Backup Exec must be purchased with at least a basic maintenance agreement. That means that what used to cost $381.00 now costs $640.00.

Fine. Be that way.

Recently I decided to go ahead and give the new version a shot just because this particular customer has always used BE on their server and I have never found another product that can backup roaming profiles on a Windows server.

The process begins innocently enough. The webstore I purchased the product from sent me an E-Mail confirming the order and within a day or so I received an E-Mail from Symantec with a license certificate in PDF format and a ZIP file with two license files in it (I still don’t know why there were two). They had registered the license to the correct company, but used the wrong address information. I have no idea where the got it from.

The next step was to login to the Symantec Licensing website to register and download the software. Nothing told me this; I just guessed. One E-Mail contained a link to File Connect, Symantec’s download service, but I missed it. After registering my license key(s) on the licensing portal I figured out where to download the software through that interface. Once I got there, I was immediately surprised at how dated the download interface was. It was comprised almost solely of non-dynamic drop-down boxes labeled “Filters” that are meant to be used to choose which software to download. After choosing the only options I had, I was presented with a list of downloads without any explanation of their use. Having seen things like this before I soon figured it out – you have to download the “1of2”, “2or2” and “cmd” files into the same folder and then use the cmd file to decompress them. It’s a very lazy way to package your software, and puts even more work on the customer for no reason. At first I tried to use the Managed Download option because the downloads total over 2GB in size and the connection was pretty slow. Turns out the Managed Download tool isn’t worth using; all it says it will do is download everything you queue up but that didn’t even work. It just stopped after the first file completed. I ended up downloading them all manually.

At this point I simply wanted to install the new version of Backup Exec in parallel with my current version so I wouldn’t have to migrate or re-configure the backups. The old version was using a tape drive and I’d be using external hard drives with BE 2012, so I figured it should be possible to simple run them both. After I got 2012 setup the way I wanted I’d just uninstall 10d. Sounds like it should be a piece of cake.

Thus begins the nightmare.

After all the files were downloaded and properly decompressed I launched the installation. After running through it’s laborious and outdated “Environment Check”, which advises you to purchase Symantec’s Anti-Virus products with a warning symbol, I was told that I couldn’t upgrade my existing version of Backup Exec 10d to 2012. I was linked to this page, which told me nothing useful and linked to two equally useless support documents which linked to other documents that didn’t apply to my scenario. I grew frustrated with this and was running out of time to work on the issue, so I thought I’d use that support that I was paying through the teeth for. That extra $259.00 has to be worth something, right?

At first I looked for a live chat option. No dice. Then I decided to just open a ticket so I could follow up with it later. I got 3/4 of the way through creating the ticket only to discover that I needed some mysterious Technical Contact ID. I couldn’t find that anywhere so I resorted to actually calling Symantec support. Once on the line with someone, they verified my information and gave me my Technical Contact ID so I could finish the ticket online.

Guess what? The code didn’t work. They gave me a different code, called a Technical Case ID, and that didn’t work either. I asked them where I could look up my Technical ID codes online and was told that I couldn’t. Instead, they opened two support tickets for me – one for my inability to create a ticket online and the other for my installation issue. I told them that my installation issue was of the critical variety because I couldn’t backup data on that server (which was true because the tapes weren’t working), and they said I’d hear from someone shortly.

That was seven hours ago. I don’t have an E-Mail confirming my tickets, and haven’t had a phone call. I can’t even check to see if the case is open online at MySymantec because my Contact ID doesn’t work.

Feeling frustrated and eager to get the installation working, I Googled my way to two answers which came in the form of a Symantec community post and a Symantec KB Article.

The first option, outlined in the community post, describes how to upgrade. It seemed that I would need to upgrade BE 10d to 11d, then to 2010 R3 and finally to 2012. Sounds like a fun day and a lot of registry settings I don’t need. Pass.

The method described in the KB article lists several methods to un-install BE 10d. At this point I am OK with that; I’d just suck it up and rebuild my backup jobs from scratch in BE 2012. However, something is wrong with my BE 10d installation and the Add/Remove Programs entry to un-install it isn’t there. There is no un-install tool in the program folder, so I needed to do it manually. The first method given by Symantec is simply to re-install BE 10d over itself, using the same configuration settings. That’s supposed to fix any problems that prevent the un-installation from working. Well that doesn’t work for me because the 10d installation program won’t run. It just crashes without even giving an error. I also tried applying the latest BE service pack to the 10d installation but that didn’t work either; it crashed too.

So that’s where I’m at right now. I can’t repair 10d, and I can’t remove it. I can’t upgrade to 2012 and I can’t install 2012 in parallel with 10d. I’m still waiting to hear back from Symantec and I’ll update this post when I come up with a solution.

Update 7-16-12: Shortly after this post went live I was contacted in the comments by a representative from Symantec named Matt.. We exchanged information, and he said that he would look into my issue. Three days passed without hearing from Symantec support, so this morning I reached out to Matt again and asked him what was going on. He replied telling me that support had been trying to contact me, but had the wrong phone number and E-mail address assigned to the tickets. This was odd given that they were correct in two different areas on Symantec websites and I gave the correct information to the tech support agent who opened the original tickets.

Within an hour I received a phone call from a technician who came to the same conclusion that I had three days ago. I’d either have to upgrade the 10d installation three times or manually remove it. I’m going through the upgrade process now and will let you know how it turns out.

Update 7-20-12: After three more days of waiting to hear back from support and finally just giving up on them and proceeding on my own, I’ve finally made some progress. During the initial conversations with Symantec tech support it was agreed that the best route was the upgrade path, even though it’s a tedious one that involves three separate program upgrades to get to the latest version. When I ran the 10d to 11d upgrade I received an error and the installation rolled back, something anything familiar with Symantec installations is surely familiar with.

The error log showed that there was a problem installing MSXML 4.0 and MSXML 4.0 SP2 (Error V-225-235). The solution, as it turned out, was to uninstall every instance of MSXML from Add/Remove Programs and then re-run the BE 11d installation. Well this is hardly an optimal solution, since BE isn’t the only program that uses MSXML and there were five entries for MSXML Windows Updates, but I went ahead and tried to remove them anyway, desperate to get this over with. Well wouldn’t you know it, that failed as well. It turned out that the installation source files had long since been deleted off of the server as many of them were over five years old.

To work around this problem I downloaded each of the original installation files from Microsoft based on their KB number and used 7-Zip to extract them to folders. Inside the installation files were the msxml.msi files that the updates needed in order to be removed, so I was finally able to get rid of every MSXML instance in Add/Remove Programs. After that, 11d installed normally. I’m getting ready to start the next phase of the upgrade and I’ll let you know how that goes.


Backup Exec 11d Upgrade SQL BPA Command Line Error

Update 7-23-12: After removing the MSXML entries I was able to upgrade from 10d to 11d, but not without an error message during the installation. Despite the ominous SQL error the installation succeeded and I was able to get to the next step; upgrading to Backup Exec 12.5.

After upgrading to 11d I ran BE just to be sure it would launch and carried over the backup job, and it did on both accounts. Feeling comfortable that I was through that part unscathed, I went on to the 12.5 upgrade. The initial stages went along without a hitch until the actual installation where another error message appeared. Unlike the 11d error, this one killed the installation and it rolled back to 11d.

Backup Exec 12.5 Error 1606

The error itself – “Error 1606. Could not access network location IDRData.” – eventually linked to a tech article on the Symantec site for error code V-225-226. There were four articles and a half dozen community posts listed there, but none of them referenced my exact issue so I updated my ticket with Symantec and I’m awaiting a response.

Update 7-24-12: Yesterday I spent some time talking with a second Level 2 Symantec technician after trying this and getting no where. Since 11d was working, the tech recommended simply uninstalling that and trying to perform a clean install of BE 2012. I had considered this, but was concerned that it wouldn’t uninstall cleanly and that then I’d be in an even worse situation. After some discussion we agreed to try it, since nothing else we were trying to resolve the issue was working, and the uninstall seemed to proceed normally. After rebooting the program entries for 11d were still present and a lot of files/folders/registry entries, but since this is normal for Symantec products I ignored it and tried installing 2012 anyway. It failed, with exactly the same message as the first time I attempted it ten days ago. Backup Exec 2012 was still detecting Backup Exec 10d and refusing to upgrade it, although 10d had been upgraded to 11d and 11d had been “successfully” uninstalled – just as I had feared it would.

The technician and I spent some time trying different things to remove the remnants of Backup Exec 11d, including running the old Windows Installer Cleanup Utility and manually deleting files and registry keys. This got us no where, as BE 2012 still found the old version and refused to “upgrade” it.

After making no progress on this front, the tech said we should look into using Microsoft Windows SDK for .NET to perform a “sector removal” of Backup Exec that he described as “kind of risky.” That didn’t sit well with me, so I put the troubleshooting on hold and asked him to review our situation and see if he could come up with any other solutions and I’d do the same.

That brings us to today, the 24th of July, 11 days after I started troubleshooting the original issue.

This morning I received an E-mail from the technician stating “The next step that we discussed yesterday requires that I get engineering approval before using this. The reason is that this can do great harm if not done correctly. This is for your protection and mine. I hope you understand. As soon as I get approval I will let you know.” That was enough for me to seriously consider the tedious manual removal process outlined in Symantec Article 50720.

If you’ve actually read this entire blog post and clicked on the links (wow), you’ll recognize that article as being one of the two original options I was considering. I was at a fork in the road, and I went left when I should have gone right. After spending a few hours combing through the registry and the file system as per the article’s instructions, I re-ran the installation for Backup Exec 2012 and it worked. Finally. I can’t even begin to express my relief.

In the end, to be able to install Backup Exec 2012 I had to manually, piece by piece, remove all traces of the previous version(s) of Backup Exec that were on the server. This was because BE 2012 wouldn’t upgrade the 10d installation, wouldn’t allow a parallel installation and the upgrade path Symantec outlined didn’t work. This process was a nightmare, but I’ve learned a few important things from it:

  1. Trust your gut. Had I listened to my instinct and just ran through the tedious manual uninstall first I could have saved myself untold hours of troubleshooting. Instead I tried to find a cleaner solution, and desperately wanted the product to just work as it should, although I knew from experience that Symantec products often require manual removal in these circumstances.
  2. Don’t expect high level tech support to be better than you. I trusted Symantec’s support technicians when they suggested that we try one thing after another that didn’t work. I figured that since they work on these issues every day that they may know something I don’t know. They didn’t. In fact I almost always had more information about the products and errors than they did. I’m not saying they were incompetent; just that I shouldn’t have gotten my hopes up. The technicians appear to be overworked, often taking half a day to reply to E-mails even though I had a critical level case and have been down for more than ten days. I had to send numerous E-mails just asking for updates. Maybe they just can’t give cases their full attention.
  3. Symantec is mired in the past. Backup Exec is a dinosaur that despite being in existence for decades still can’t get simple tasks done like uninstalling or upgrading. What’s more, Symantec support seems completely unequipped to work through these issues. While it’s true that they have a myriad of support articles, many of them are out of date, poorly written and don’t solve the problems they proclaim to. The installation doesn’t bother to tell you that it’s going to gobble up 800MB of storage space on your system volume even if you specify a different installation path for the product. The installation files have gone from around 660MB in 2006 to 2,390MB in 2012. The product is nearly four times larger. For what? I didn’t measure the memory usage before and after, but I can tell you that 2012 uses significantly more to do the same thing. A quick review of my processes shows Backup Exec and its SQL processes eating up at least 600MB of RAM. That’s without the manager or a job running!
  4. Time to start looking for new solutions. I’m not going to be purchasing another Backup Exec product. This experience has seen to that. Despite Matt from Symantec reaching out and escalating my case to a higher level of support, which I appreciate and find very pro-active, I essentially had to resolve the issue on my own. All for a product that costs $259.00 more than it used to in order to perform the same job.
If anyone out there can recommend a solid backup solution that will backup to external drives, folders on disks (for cloud backup) and is capable of backing up Windows roaming profiles stored on servers using user credentials let me know in the comments!