2015

3 Topics

Solution for VSS exceptions with VMware guests / VM tools
Hi everyone, We have been experiencing VSS issues with VMware guests in regards to the installed Backup Exec Agent and a previously installed VMware Tools VSS option. Uninstalling the VMware Tools VSS option in various ways including restarts did not fix our issues. If you search the internet for solutions, you find many attempts but no real solution or explanation. One of our admins spend several hours with the Veritas support without a solution, he was about to escalate the issue with them, when we found the root cause and could actually fix our issues. First the steps to solve this: Uninstall the VMware Tools VSS option (no restart will be requiered) Make sure VMware VSS service was deleted If this is not the case, you might need to do so manually and remove additional DLL's etc. as well as restart the system, but this is independent from this solution You might have already done steps 1 and 2 but you still get VSS exceptions from the backup that says you have more than one VSS agent installed: V-79-8192-38331 - The backup has detected that both the VMware VSS Provider and the Symantec VSS Provider have been installed on the virtual machine 'hostname'. However, only one VSS Provider can be used on a virutal machine. You must uninstall the VMware VSS Provider. Now you wonder what causes this and you get stuck You could uninstall the Veritas/Symantec Backup Exec Agent and only back the system up per VMDK You would lose the GRT / granular backup / restore capabilities Check your registry for the following reg key HKLM\System\CurrentControlSet\Services\BeVssProviderConflict If this key exists, but your VMware VSS provider is uninstalled, you need to follow up with step 5 Open a notepad as administrator Open this file in the notepad C:\ProgramData\VMware\VMware Tools\manifest.txt Search for the following two entries: Vcbprovider_2003.installed vcbprovider.installed Make sure both of them are set to FALSE, most likely one of them is TRUE Run a test backup This test backup now should not show the exception anymore The registry key should vanish (refresh/press F5) without you taking action So what happened? You uninstalled the VMware Tools VSS provider, but this manifest file did not get updated. We actually could see that it sometimes does get updated and sometimes does not. This seems to be some kind of issue with the VMware Tools uninstalled/installer. But why this manifest.txt file? As we found out, there scripts that get executed by Symantec/Veritas Backup Exec before the backup. You might find them in two locations, and it seems to depend a bit on the Windows version which script is executed (at which location). You could edit them both and just undo the checks in the scripts, but this wouldn't be correct. It is more correct to update the manifest.txt file. If you want to, you can check the date/time of the manifest.txt file before you change it - you might see it was not updated while you uninstalled the VMware Tools VSS provider (assuming you did only do this and not do additional installs/uninstalls within the VMware Tools / please note as well that this only is true when you still experienced those issues). Now, back to those scripts, you find them here: C:\Windows C:\Program Files\Symantec\Backup Exec\RAWS\VSS Provider The name of the script that matters: pre-freeze-script.bat This script checks several DLLs, registry entries, paths and on Windows 2008 and newer the ProgramData-Path for this specific manifest.txt file and the two entries mentioned. Once you uninstall the VMware VSS provider, and the file did not get updated, you might see this issue and wonder how to solve it. The solution is to simply update it to mirror the uninstallation of the VMware VSS provider (vcbprovider). We double checked this with several installations and could see if the file actually gets updated, those two values are set to FALSE, if it doesn't, at least one of the values remains true, what causes the pre-freeze-script.bat to write the registry key mentioned earlier and therefor causing the issue in the backup - exceptions. If you still have the same issues after updating the manifest.txt, simply check all the DLL's that are mentioned in the script and make sure they don't exist. You might also consider to manually delete the registry-key (it seems to be just a dumy-key) to make sure there is no issue that prevents the script from deleting it. Make sure it does not re-appear after a backup! Otherwise you might still have some DLLs left on your system that cause the script to re-create the registry key. Hope this helps a few of you out there. This was an ongoing issue for a while and I came accross those issues many times ever since Windows 2008. This applies to Windows 2008 R2, Windows 2012, Windows 2012 R2 and pretty sure to Windows 2016 as well. It helped us getting rid of those issues completely and actually not even needing a single restart of the guest VM to solve the issues (removing the VMware VSS provide did not need a restart). Regards Florian Rossmark
Solved
frossmark
8 years ago Place Backup Exec
14KViews
2likes
10Comments
OES 11 SP3 on up to OES 2015.1 NSS Novell / MicroFocus
Does anyone know if BackupExec has plans to support: SLES SP4 With: OES 11 SP3 (NSS Volumes) OES 2015 (NSS Volumes) OES 2015.1 (NSS Volumes) I understand a work arround is to edit the "/etc/novell-release" and change it to the older SLES11SP3 settings. I find this to be a poor workaround as if you forget to change it back prior to running system updates.......(Well Do I need to say the rest....)..... Another work arround would be to create a "pre and post" task to edit the file By creating OS/OES-Version "templates" for both version and the copy the Pre Job Task - Copy Template - SLES11SP3/OES11SP2 over /etc/*release Post Job Task - Copy Template - SLES11SP4/OES2015SP1 over /etc/*release Thanks! Patrick
pwolfe
9 years ago Place Backup Exec
2.5KViews
0likes
2Comments
Amazon S3 Bucket - share or connect with second BEX server?
We have two Backup Exec 2015 FP4 servers, one CASO, one MMS at different sites via site-to-site links. We are testing the Amazon S3 connector on the CASO - so far so good. It’s basically a giant disk-based storage device. I heard it’s the Hotel California of storage (HA!) free to write to, minimal storage cost, expensive to get data out. So I’m thinking about DR and all that jazz, what if this server (or building) decides to melt down? How do we access the Amazon S3 bucket from the other server? When I try to attach the existing bucket to the second server it won’t let me as this name already exists. I was hoping it would be like a shared Dedupe storage, but no dice. Just curious if anyone has this working – the same bucket with two servers – so that we can restore from either. I suppose I can delete the AWS storage from the CASO and then connect to it on the MMS but I would hope that we can set this up before disaster strikes, not after. I plan on testing this but though I would ask this community.
derwood
9 years ago Place Backup Exec
886Views
0likes
0Comments