Blog: Backup Exec

Since Veritas took over Backup Exec from Symantec, we’ve had issues getting licensing migrated and renewed for various reasons.  

For one customer we had recently renewed maintenance for one year and needed to apply the license to the Backup Exec console. In the console, I could see there were product licenses and maintenance licenses. The maintenance licenses had indeed expired. 

When I went to the Veritas licensing portal to retrieve the licenses, they showed an expiration date in one year from now. I downloaded the new licenses, but no matter what I tried to import or delete existing licenses, it never would display the new maintenance expiration dates.

I called Veritas and they changed the way maintenance licenses are managed from the Veritas portal; they are not managed on the Backup Exec console any longer.  You can ignore the dates for the maintenance contract now since they moved over to Veritas.


Do you remember playing those games where you would look at two seemingly “identical” pictures and try to spot the 5 differences between the two? I’d like to play that, except there’s only one difference between these two:

Here’s the situation. We’re hosting files off of a CIFS share on our NetApp device. We needed to back up this CIFS data using Backup Exec. I went through and set up NDMP on both the NetApp and Backup Exec so that the communication could be established for Backup Exec to connect to the CIFS share and grab a copy of the data. In order to get the resource credentials to show successful, I had to set the Logon Account for the NetApp to be our domain Backup Exec Service Account (BESA) and the actual CIFS share to be the NDMP user account I had created for backup.

Secondly, there is another gotcha associated with how to set up the NDMP account for backup. If you use the root account, you can simply use the regular password as if you were logging into the NetApp device from the backup server. However, if you decide to create a new account, you must encrypt the account on the NetApp device. To create the account, do the following:

useradmin user add <login_name> -g “Backup Operators”
(Type in the password)
ndmp password <login_name>

The output after the password is what you will copy and paste into the backup server so that the NDMP user can authenticate.


We recently ran into a problem where a job in Backup Exec was failing when backing up the vmdk using Virtual Consolidated Backup (VCB).  Backup Exec was reporting the following error message: and reportint the following error message:  "The Virtual Machine resource is not responding."  After some trouble shooting and research we discovered an unallocated disk may cause Backup Exec to fail with that error when another allocated disk is beng backed up.  This turned out to be the problem in our case as we had an unallocated disk. [more]

Here is some more informatino about the issue from Symantec:


Block level vmdk backups have limitations that will GET YOU.  Backup Exec and Veeam both have the ability to backup the vmdk files in a VMware environment and still retain enough information in the backup set to do individual file level restores.  However, both products will ONLY work if you have vmdk disks partitioned using the MBR (Master Boot Record) type tables and NOT the more modern GPT (Guid Partition Table) structure.


I was setting up Backup Exec 12.5 to function as a VCB proxy to back up our VMs at a VMDK level and ran into a few problems. Version 12.5 has this functionality built in so it was fairly simple to back up a VM from the SAN to the VCB proxy. Restoring it back to the vCenter cluster, on the other hand, was a different story. The first problem I ran into was in running a simple restore. The job would fail as it would try and convert the machine. Simple fix: Install VMWare Converter Standalone on the proxy. [more]

Problem 2: The job would fail and give me a suggestion that I might try restoring the machine as a redirected restore job.

Problem 3: When I tried to set up the job for a redirected restore, I receive “Access is denied.” when it attempts to connect to the vCenter and datastores.

Solution: UAC was causing the access to be denied. If I started Backup Exec as an administrator or disabled UAC on the machine, I was able to get access to the datastores and set up the redirected restore. From there, my restore jobs were successful. Now I did run into other slight problems with this restore, but I’ll save that for another time.


In troubleshooting a SBS 2003 Server, it was discovered that the system drive was almost out of space.  Upon further investigation, most of the disk space was being consumed in the %WINDIR%\Installer folder.  In that folder were numerous MSI files that were over 100 MB each over and over. 

It was noted that earlier in the week, an update for Backup Exec kept trying to install and failed until the server was rebooted by the customer.  After rebooting the server, the install took, but all of those failed attempts seemingly left these orphaned MSI files created each hour the server tried to install the update.

In order to clean out the orphaned files in this folder, you will need to run “MSIZAP.exe T!”.  You can obtain the MSIZAP file from:;en-us;290301.  Syntax for running MSIZAP can also be found here: [more]

After running this program, it deleted over half of the files in the Installer directory and reclaimed approximately 10 GB of hard disk space.  It was noted that the duplicate 100 MB+ files were removed.


To export a selection list in Backup Exec – edit job, select Submit, copy and paste.  This will give you a nice text version suitable for saving, searching, etc.  Portions of this can be copied and pasted back into the text view of the selection list.

The selection lists are accessible in the SQL server in the BEDB database in the vwScriptPropertiesBackup view.  The fields of interest are ScriptName, ScriptDescription, DeviceSelectionName, PathName, and FileName. A SQL command like this could be used to list these fields.

SELECT [ScriptName]
  FROM [BEDB].[dbo].[vwScriptPropertiesBackup]

You could set up a DSN and access this with Excel, or use the sqlcmd from the command line.  Adding a WITH clause to select a particular selection list could be useful also.

UPDATE:  This is not applicable to BackupExec 2010.  Instead, you can go to the Job Setup tab, find the selection list, right click "View Summary", and then highlight and copy the text from the window that pops up.


We recently ran into a problem where one of our customer's servers was randomly rebooting. It looked like the cause of this was the updates from Backup exec that were being downloaded and installed. We checked backup exec and it was not set to install updates at all. After some research we found that they updates were being installed even though it wasn't set to do so. [more]

We noticed the updates were occurring the same time as the SMSE updates. After researching with Symantec I found that by default Backup Exec is registered with LiveUpdate and is configured to receive updates ANYTIME LiveUpdate is run from ANY Symantec application configured to use LiveUpdate. Thus every time that SMSE started LiveUpdate it would install Backup Exec updates as well. I downloaded a utility (BeUpdateOps.exe) that I used to unregister Backup Exec from LiveUpdate and this stopped the random reboots.


When using the Advanced Open File Option with Backup Exec, make sure you check the Job Log to see if it is actually getting used correctly. I wanted to use it to back up VMWare Server virtual machines at CITBA. The job was running successfully, so I thought it was working correctly. We started getting calls that VMs running on that server could not be reached by users trying to RDP to them. Once the OSE connected to them via the VMWare Server console, the app would show an "access denied" error (only once) and then go away and stuff would start working. [more]After research, it was discovered that Backup Exec was actually using standard backup (not AOFO) to backup the VM vmdk files thus causing a file lock issue with VMWare Server. Note the very inconspicuous log below.

You can find this is the "Job History" tab of the job log. The reason was that no AOFO licenses were installed. So, the moral of the story is Backup Exec will let you select the AOFO option in a backup job and let you deploy the Backup Exec agent with the AOFO option even in you don't have the license installed. Thus, making you think AOFO will actually work, but don’t be fooled. It doesn't.


If you want to restore a SBS 2003 box that was upgraded from SBS 2000 using tape backups from Backup Exec, here is the process…and believe me this is abbreviated. [more]

  1. Install SBS 2000 so that you can get the system path to be c:\winnt and some necessary dlls that will break the kernel if you try to go directly to SBS 2003. It is temping to use an unattended install and skip directly to SBS 2003 with a  custom install point, but I speak from experience…it doesn’t work. No need to install and configure DNS…I know it sounds like it will break, but it won’t. The only component that should be installed is SBS. Don’t install Exchange, ISA, SQL or the optional components….JUST SBS. Trust me. Be sure to name the domain the same as it was before during setup.
  2. Your goal is to get to SBS 2003, but before you upgrade your SBS 2000 install, you must install Windows 2000 SP3, then SBS SP 1a, then Windows 2000 SP4. Having fun yet?
  3. Upgrade to SBS 2003 and then fix what didn’t work when you upgraded it….just kidding this actually works pretty well considering.
  4. Your next step is to get Backup Exec up and running. So either reinstall Backup Exec on the SBS 2003 box and inventory your recovery tape or install the tape drive and Backup Exec to another server and do it there. Really doesn’t matter where you do it from. Make sure your backup exec service account has access to your restored server if you moved it to a different server.
  5. Reboot your restored SBS 2003 server into AD recovery mode by pressing F8 at boot time. It’s like booting to safe mode, but it’s a different option on the same screen.
  6. Do the authoritative restore, but DON’T restore anything that has anything to do with SQL, Exchange. That includes program files directories, databases, all the other items that are included in the doc link below. Yeah, this seems strange, but bare with me. Oh, and if ISA was originally installed, you can restore it, BUT if it was set up to log to a local SQL MSDE database (which most are because it is an SBS install and I think that is the default behavior), it won’t work. Exactly how ISA will act once restored is somewhat of a mystery so best of luck to you. IMO, just remove it and deal with it after all this mess is done.
  7. Reinstall SQL Server and Exchange Server from media. I know, I know….you have a backup of it so why do you have to reinstall it from the CD that you don’t have. Because…
  8. Using single user mode, restore the master SQL Server database first then restore all the other databases.
  9. Reinstall Exchange with the /disasterrecovery option. Follow the instructions in the doc…just follow the doc. Just get ready to run eseutil on your databases because they will need it, especially if circular logging was turned on at the message store level (and if you are the one that turned circular logging on…shame on you!). Mount your databases after all the consistency checking is complete.
  10. Now, take a breath, go get a burger from Whataburger because by now it is 2:00 in the morning and that is the only place open.
  11. Address the literally hundreds of issues that will arise after you have done this procedure.

Here is a link to the unabridged version: 

Oh, and in all this you better hope you are restoring to similar if not the same hardware. The support on this process from Backup Exec goes right out the window if you aren’t restoring to the same/similar hardware. And you MUST have the media to reinstall all this stuff. Gathering this type of stuff seems trivial, but it is actually one of the MOST difficult parts of this process, especially if the customer is not a volume license holder.