Backing up Active Directory: V-79-57344-33928 - (AD LDS) database was not found.
Hello, We have this error from time to time, but it usually fixes itself without any end user intervention. However I am getting this error three nights in a row now on one of our domain controllers. This started happening on Wed morning, and continued through Friday morning. In all three instances the error message in the log is: Job ended: Thursday, October 29, 2009 at 1:18:54 AM Completed status: Failed Final error: 0xe0008488 - Access is denied. Final error category: Security Errors For additional information regarding this error refer to link V-79-57344-33928 Errors Click an error below to locate it in the job log Backup- \\dc1.domain.com\System?State V-79-57344-33928 - Unable to complete the operation for the selected resource using the specified options. The Active Directory, Active Directory Application Mode (ADAM) or Active Directory Lightweight Directory Services (AD LDS) database was not found. So I checked the selections and under the server in question, I can see System State > Active Directory > C:_WINDOWS_NTDS, and this is all checked off. I did a test Resource Credentials for everything in this backup and it all returnedsuccessfulso I'm at a loss. Under Settings > Microsoft Active Directory for this job properties we have all three boxes checked (GRC, Consistency Check, Continue if Consistency check fails.) Backup method is greyed out, but says Full - Back up entire Active Directory. We are using Symantec Backup Exec 12.5 for Windows Servers Media Server Version 12.5 Rev 2213 Administration Console 12.5 Rev 2213 Desktop and Laptop Option: Version 3.1 Rev. 3.41.32a Installed updates: Service Pack 2 Hotfixes: 324947 317436 325647 319242 324012 326004 323894 324011 Thanks for the help, we really do appreciate it!3.2KViews0likes11CommentsRestore serial appointment
We tried to restore a Outlook serial appointment which one was edit on element level every time when the meeting occur. After the successful restore we have the only unknown Items in the Series. Is this normal? I'm grateful for any help! Thanks in advance!628Views0likes0CommentsBackup Exec log files 38GB
We've had an issue with our server due to lack of free space. We've examined the contents of the drive and "C:\Program Files\Symantec\Backup Exec\Logs\" is taking up 38GB of space. Can you tell me why it would take up this much space please? More importantly how do i cap it at say 10GB? We are using Backup Exec 2010 R3 on a windows 2007 sbs server. All our backups are backup to disk folders on removable drives and we backup also backup exchange and SQL. Thanks, your help is appreciated ThanksSolved12KViews1like4CommentsCannot back up system state
Good afternoon, We are currently experiencing an issue when attempting to backup one of our servers. We are running full backups on 7 Windows 2008 servers, but one is failing when it comes to back up the system state. The error is reported as: - AOFO: Initialization failure on: "\\<SERVER>\System?State". Advanced Open File Option used: Microsoft Volume Shadow Copy Service (VSS). V-79-10000-11223 - VSS Snapshot error. The Microsoft Volume Shadow Copy Service (VSS) snapshot provider that you selected cannot snap this volume. Select the default snapshot provider, and then run the job again. The following volumes are dependent on resource: "C:" "X:" . The issue appears to be "X:" - this is theDVD drive on the server and obviously VSS isn't able to snap it, and this is the only server on which this is apparently a dependent resource.I'm prety sure it shouldn't be listed here at all? I have checked in the seemingly obvious places (I'm not much of an expert with BE) to no avail, would anybody know how to resolve this and remove X: as a dependent resource? Cheers,2.7KViews1like16CommentsSolution 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 RossmarkSolved14KViews2likes10CommentsCAPI2 - 513 : Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
Hi, I am running BE12.5 SP4 on a W2003 Server to backup a W2008 file server. On that W2008 file server I got a multiple error in Windows application log: CAPI2 - 513 : Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object. I have checked Symantec doc id327192 (http://seer.entsupport.symantec.com/docs/327192.htm), but all security settings are ok and the SystemWriter *is shown* in vssadmin and the buckup job does not fail. Anyone any idea how to fix that? Cheers Dirk3.3KViews1like4CommentsBackup Exec 16 - Temporary VMware folders are not cleaned from the Backup Exec data directory
HI All, So we started with Backup Exec 14 few years back and I've updated to BE 16 last week with latest patch due to following issue when Symantec could not resolve it. Issue: When backup up VM's, there are lot of Temporary folders been created in folder C:\Program Files\Symantec\Backup Exec\Data. (Folders name include VM's name and date ), and number of folders been created keep growing everyday. Troubleshoot done: I've logged a call with Symantec and for a week they did troubleshooting and today an Advanced tech called me and advised that this is a known issue and only work-around is to delete these folders manually ? Now I have had the same above issue while we were on BE 15, with all the patches installed, hence why I quickly upgraded to BE 16 to see if that resolve the issue. Symantec advance support tech directed me to this article ( https://www.veritas.com/support/en_US/article.000023219 ) which is according to the article was an issue on BE 2014. So I don't believe that Backup Exec 16 will have this now, will it ? And I can't accept an answer been deleting these folder manually every day as a solution. Does anyone experienced this kind of issue ? Cheers3.3KViews0likes3CommentsDisk is offline, Physical volulme library drive is not available
Dear Community, I have an intermittent problem whereby my backup jobs will fail on certain days with the error: - Media Error: The disk is offline and then followed by - [Job Name] - The job failed with the following error: Physical Volume Drive not available. Edit: Do take note of the dates. Backups are failing randomly on certain days. However, no action is performed on the problem and the backup would run fine on the next schedule. I am backing up to a local drive. Please refer to the attached screenshots.2KViews0likes7CommentsBackupExec 2010 dropping tape drive offline
Hi, This is a new topic to re-open the issue discussed here: https://www-secure.symantec.com/connect/forums/tape-drive-goes-offline-second-backup Just to recap on the issue itself: Running BE2010 Trial on Windows Server 2008 R2 x64. Hardware is Dell R710 rack server, connected to a HP Ultrium 1760 LTO4 SAS drive via a Dell PERC 6/E SAS Adaptor card. This is what’s happening: Setup and run a backup job with full verify. I’ve tested up to a 250GB job and it completes fine the first time around. After completion of first job, rerun the same backup job (after tweaking the media overwrite/append etc settings) The job immediately fails, reporting the drive as offline – cannot bring drive back online using BackupExec administrator Close BackupExec administrator, restart BackupExec Device/Media service (which also restarts associated service dependencies). Re-open BackupExec administrator - drive appears to be online again, ready for another job to be kicked off. I’ve completely replaced: Numerous LTO tapes The Dell SAS adaptor that connects the Dell server to the HP rack chassis The HP Rack chassis that houses the 1U internal HP LTO4 Ultrium 1760 SAS drive, SAS adaptor board and all The internal HP LTO Ultrium 1760 drive itself We’ve verified that all above component drivers and firmware are fully up to date. This problem occurs with both Symantec Tape Drive drivers and HP's official LTO4 tape drivers, To me, the following facts suggest that the problem lies with BackupExec itself: After the drive goes offline, a simple restart of the BackupExec services seems to bring it back online again If the drive goes offline, and I stop the BackupExec Device/Media service, I can still access the drive using HP LTT utility, and HP Data Protector Express – only BackupExec detects the drive as offline. We’ve replaced all possible hardware components and the problem still remains This problem only ever occurs with BE, I'm testing with HP Data Proctector Express and MS's Data Protection Manager - all work fine. Luckily, I haven't bought a license for BackupExec yet, however this means I doubt Symantec Support will be willing to spend too much time on it, so I might be forced to go with MS's Data Protection Manager instead if I can't get a resolution soon. Has anyone seen/resolved this issue before? AlistairSolved8.8KViews1like40CommentsBackup Exec 2010/2012 Media Server Installation on a ESXi 5.0 Virtual Machine
Hi All, I would need to heed your expert advice in regards to the Backup Exec Media Server. I have a plan to run Backup Exec 2010/2012 on a ESXi 5 Virtual Machine running Windows Server 2008 R2 Operating System. I have read through some of the KBs available like the one that is an Alternative Configuration using the SCSI passthrough. Some have commented that it will experience issues. I would wish to run the Backup Exec 2010/2012 in a Virtual machine, with SAS connectivity from the ESXi Host to a HP autoloader/library. Regards, Chong YeeSolved2.1KViews1like10Comments