Hello,

I've been looking around here a bit and did not find any answer on the following question:

I bought a new server for vRanger backups and I want to move now my existing vRanger 5.2.1 installation with all job settings and other setup from the existing server to the new one. Is there a guideline available to do this or could me somebode explain, how to do this?

I want to prevent it to create the backup jobs once again.

the vRanger database is stored on a separate SQL Server database server. If you need more Information about my setup to answer the question, please let me know.

Hi all,

after migrating to ESXi5 i receive an error trying to do backup of some VMs with the Quiesce Virtual Machine Option.

The error in the vRanger log is: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: API Call failed with message: An error occurred while quiescing the virtual machine. See the virtual machine's event log for details.

Checking on vCenter, the task regarding the VM Snapshot shows an error: The guest OS has reported an error during quiescing. The error code was: 5 The error message was: 'VssSyncStart' operation failed: Unspecified error (0x80004005).

Also, after this error, the VM runs on a machinename-000000001.vmdk disk insted of the usual machinename.vmdk. In the Snapshot Manager there is no open snapshot after this and to restore the "orginal situation" i have to make a new snasphot and then do a "Delete All" in the snapshot manager. After this the VM get back on running on the machinename.vmdk.

Inside the VM SO (Windows 2008 R2) i have this entry in the System Event Viewer: The device 'VMware Virtual disk SCSI Disk Device' (SCSI\Disk&Ven_VMware&Prod_Virtual_disk\5&22be343f&0&000100) disappeared from the system without first being prepared for removal. Source: PlugPlayManager. EventID:12

Taking a manual Quiesced Snapshot from vSphere Client completes correctly without issues.

This error occurs only on some VM with Quiesce Virtual Machine Option. Other VMs with the same option are working just fine.

Anyone got the same issue?

Thanks for your help

Hi,

we plan to build an virtual Domain Controller on a Windows Server 2012 VM (on an ESXi 5.1 VMware Server).

Will there be any Problem with the Backup of this VM or is everything as usual? Like on a normal Windows Server VM?

Do we have to pay special attention on something?

Is the Backup of  the Active Directory consistent if we use Quescing?

Thank you for your help!

I did a full backup of a test VM the other night and it worked great and I was able to restore it. I tried one of our production servers next and I got the below email when it failed. I'm not sure if there is any other information somewhere withing vRanger to look at but this is all I have now. Would anyone know a cause of why this one didn't work?

Thanks.

Host Name: VEEAM
Job Name: Backup 'WINAT'
Inventory Name: WINAT
Result: Completed
Start Time: 1/30/2013 6:30:51 PM
End Time: 1/30/2013 6:30:58 PM
Duration: 1 minute(s)
Backup Type: Full


Machine Name: WINAT
Result: Failed
Start Time: 1/30/2013 6:30:54 PM
End Time: 1/30/2013 6:30:58 PM
Duration (minutes): 0
Archive Size: 0 GB
Message: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: Object reference not set to an instance of an object.

Hi,

We are running out of space on our disk staging area and although the long-term fix is to increase the size of it, as an interim solution I am looking to reduce the retention policy so that we keep fewer versions of each VM on disk.  Currently our policy is set to 7, and I want to drop this to 6, but I am wondering if there will be an automatic purge of the old, redundant copies, or if there is some process I need to initiate to do this?

Any help would be much appreciated.

Cheers,

L8E

Hallo zusammen,

Habe beim Backup eines VM's folgende Meldung:

An internal error occurred during execution, please contact Quest support if the error persists. Error Message: API Call failed with message: Datei ist größer als die vom Datenspeicher '' unterstützte maximale Größe

Die einzige Partition die ich gerne sicheren will ist das C-LW und ist 25GB gross. Das 2. LW ist ein virtuelles LW, den ich gar nicht sichern will (s. Bild unten, oder Anhang)

und der Repository hat noch genügend Kapazität (s. Bild unten):

Trotzdem bekomme ich die Fehlermeldung !

Was läuft hier ab und wie kann ich es in Griff bekommen ?

Herzlichen Dank im Voraus und

Viele Grüsse aus der Schweiz

Farouq

Hi,

This will be my first post since i used the products for the past few years.

I got a problem with HotAdd at the moment, which doesn't seem to work correctly.

From the 45 virtual machines we backup daily, mostly only 5 random work thru HotAdd, the rest is thru LAN

Since there is support for ESXi and vCenter 5.1 we made the jump from 5.3.2 to version 6.0.1

We also upgraded our hosts from 4.1 to 5.1, our vCenter was already 5.1 for awhile now...

And we changed from a virtual to a physical vRanger server on top of Windows 2008 R2 which is fully patched with 5 VA's (one per host)

Everything works ok ... even cataloging works now (which never worked for us in 5.x)

Here is a log file of one if the failures:

[2013-02-12 20:01:06.246]: vRanger Backup & Replication - v6.0.1.31606
[2013-02-12 20:01:06.246]: Selected Options: Compress backed up files. | Enable guest quiescing. | Enable Active Block Mapping (ABM). | Enable Cataloging. | Selected SpaceSavingTech: Incremental | Included Disks [1].
[2013-02-12 20:01:06.246]: Task for virtual machine ap-xxx01-sql was queued.
[2013-02-12 20:23:00.381]: SourceVm:ap-xxx01-sql | Uuid:xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | VC:ap-xxx00-vc.xxx.lan, Host:vm-xxx03.xxx.lan [ESXi 5.1.0]
[2013-02-12 20:23:00.381]: Beginning backup task for ap-xxx01-sql
[2013-02-12 20:23:00.381]: Starting task validation.
[2013-02-12 20:23:00.381]: Connection to vm-xxx03.xxx.lan was properly validated.
[2013-02-12 20:23:00.381]: vm-xxx03.xxx.lan is properly licensed.
[2013-02-12 20:23:00.397]: Test connection to repository Database Servers starting...
[2013-02-12 20:23:00.974]: Test connection to repository Database Servers successful!
[2013-02-12 20:23:01.473]: Ending task validation... success!
[2013-02-12 20:23:01.473]: Beginning initialization of backup information.
[2013-02-12 20:23:01.473]: Retrieving the tasks parent information.
[2013-02-12 20:23:07.074]: Retrieving save points for any full backups associated with this job.
[2013-02-12 20:23:07.167]: Verifying content of repository.
[2013-02-12 20:23:09.180]: Finished initialization of backup information successfully.
[2013-02-12 20:23:09.180]: An Incremental backup will be run for this task.
[2013-02-12 20:23:09.289]: Gathering credentials for ap-xxx01-sql completed.
[2013-02-12 20:23:09.554]: Checking for VMotion completed.
[2013-02-12 20:23:10.911]: Gathering data for ap-xxx01-sql from API completed.
[2013-02-12 20:23:12.050]: Gathering data for vm-xxx03.xxx.lan from API completed.
[2013-02-12 20:23:15.154]: Retrieving the VM BIOS configuration completed.
[2013-02-12 20:23:16.215]: Gathering credentials for va-xxx03-vranger completed.
[2013-02-12 20:23:17.260]: Gathering data for va-xxx03-vranger from API completed.
[2013-02-12 20:23:18.040]: Validating connectivity to virtual appliance 10.9.2.3 completed.
[2013-02-12 20:30:25.369]: Creating a quiesce snapshot for vRanger completed.
[2013-02-12 20:30:32.732]: Gathering data for ap-xxx01-sql from API completed.
[2013-02-12 20:30:32.747]: Local machine is a physical machine.
[2013-02-12 20:30:32.747]: Backup task will attempt to use VA-based VDDK HotAdd.
[2013-02-12 20:30:57.286]: Using filter type(s) change block and active map for disk: vix:r:ap-xxx00-vc.xxx.lan:902:[na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:33:28.683]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: 3201 - can't open [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:33:28.699]: The failed backup task will be retried.
[2013-02-12 20:36:03.387]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: 3201 - can't open [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:36:03.387]: The failed backup task will be retried.
[2013-02-12 20:38:49.635]: Backup task using VA-based VDDK HotAdd failed: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: 3201 - can't open [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:38:49.651]: Check the manual for compatibility issues when attempting Lan-free operations.
[2013-02-12 20:38:49.651]: Backup task will be attempted using a VA-based VDDK network connection.
[2013-02-12 20:38:49.651]: Windows Server 2008 OS detected, application-level quiescing is Disabled during the VDDK backup.
[2013-02-12 20:39:14.954]: Using filter type(s) change block and active map for disk: vix:r:ap-xxx00-vc.xxx.lan:902:[na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:39:24.251]: Beginning Cataloging of [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:39:55.108]: Catalog data for [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 1 was queued to save successfully.
[2013-02-12 20:39:55.124]: Catalog data for [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 2 was queued to save successfully.
[2013-02-12 20:39:55.124]: Disk [na-xxx01-data2] ap-xxx01-sql/ap-xxx01-sql_1.vmdk is skipped per backup. Cataloging of disk is skipped.
[2013-02-12 20:40:14.218]: Backing up disk 'vix:r:ap-xxx00-vc.xxx.lan:902:[na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk:moref=vm-375330:snapshot-519895:6' completed.
[2013-02-12 20:40:14.234]: Checking and enforcing retention policy completed.
[2013-02-12 20:40:38.195]: Removing snapshot for vRanger completed.
[2013-02-12 20:40:38.819]: Commiting savepoint data to Database Servers completed.
[2013-02-12 20:40:40.597]: Verifying the content of the repository completed.
[2013-02-12 20:40:41.081]: Setting VM event completed.
[2013-02-12 20:40:41.377]: Catalog data for disk [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 1 has been queued to activate.
[2013-02-12 20:40:41.393]: Catalog data for disk [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 2 has been queued to activate.

Non-official script! Provided on 'as-is' basis.

It is recommended to have vRangerPro DB backup before running the script!

Features:

1. Scans CIFS (only!) repository for existing Savepoints.

2. Generates new Global Manifest. Can be used to re-create missing Global Manifest.

3. Synchronizes DB records with actual repo content.

4. Can be executed from any PC with Powershell 2 installed.

5. Should work for non-USA customers. Tested on SpanishServer 2008 and Spanish SQL Express 2008.

Pros:

It fixes situation when imported SPs can not be deleted through GUI (Remove button disabled).

Re-scans/verifies existing repo. In theory some check procedure can be added, e.g. var is missing or unreasonably small var created.

Lets completely avoid ‘Restore from Manifest’.

Customer can create own set of SPs. For example, take following scenario. DR site. Repo exists, admin brings set of SPs from different locations and drops them into the repo share, runs script. Ranger displays both old (if still exist) and new SPs in restore grid. Regular restore job can be created from SP Grid.

Cons:

Requires version 2 of Powershell

Does not perform thorough check of backup content. Presence of 2 metadata files in SP directory is sufficient to consider SP existing.

SP directory should follow original naming convention: root_of_the_repo\<ObjectName>_<ObjectUUID>\<ObjectName>_<Date>_<Time>_<JobTemplate UUID>.

Instructions:

1. Launch Powershell, execute “Set-ExecutionPolicy Unrestricted” if necessary

2. run script

3. select SQL instance, provide credentials if necessary

4. select existing repo you would like to sync

5. provide credentials to access repo share if necessary

6. refresh Repo view in Ranger.

Old GlobalManifest and script log are saved in the root of the repository.

================ update. 03/09/2012 ==================

Some of you may have seen a following error when executing original version of a script.

Exception calling "ExecuteNonQuery" with "0" argument(s): "Conversion failed when converting from a character string to uniqueidentifier."

It happens due to a broken link between BackupTask and SavePoint tables. When backup task is completed successfully, the row in the BackupTask table should have a pointer to the corresponding savepoint. For some reason there are successful tasks with pointer set to NULL.

Attached new version (reposync02) of the script can handle this situation properly and will re-establish link between tables if necessary.

I also recommend to run following sql command to find if there are any broken links between 2 tables. Check 4th (Table_Link) column for NULL value.

This issue could be a reason for malfunctioning retention. SPs with broken link will most probably be ignored by retention mechanism.

SELECT t.TaskId, t.VmName, t.StartTime, bt.SavePointId AS Table_Link, sx.SavePointId

FROM Task t, BackupTask bt, SavePoint s, SavePointXml sx

WHERE t.TaskId = bt.TaskId

AND s.SavePointId = sx.SavePointId

AND bt.TaskId = sx.ManifestXml.value('/*[1]/JobTaskID[1]', 'uniqueidentifier')

AND s.IsDeleted = 0

ORDER BY t.StartTime

P.S. This script has been used in multiple support cases and proved to be very helpful. Especially taking into consideration some recent glitches with "FLR from Manifest".

The post is open for vote, questions and comments.

Hi,

     I received an error on a backup job I had enabled CBT on a few days earlier (daily backups).

An internal error occurred during execution, please contact Vizioncore support if the error persists. Error Message: The DTOBase.MarkToBeDeleted() method does not support deleting items that are already deleted.

I have not come across it nor found any reference when searching on the Quest site.

Does anybody have any information on this error and a fix.  I have just noticed the v5.2.1 upgrade and will be doing that but would like to know what this error means.

cheers

I cannot find where it says you cannot do it, but I want to add a second virtual appliance to a Virtual Center cluster. When I go to the add screen, the NEXT is greyed out. Is there a limitation of one VA per cluster? If so, will this limitation be addressed in next release.

We do a lot of image taking with vRanger and while the introduction of the virtual appliance has helped, it cannot handle the load. I would hate to go back to having many vRanger servers as did in 5.3. I tried increased the load of the VA to 4 from 2 but that is causing problems as disk are not bein released from the hot-add and cutting back to 2 seems to help a little. Even at 4 it was still not completing all the imaging in a timely manner. Also tech told me not to do more than 2 per VA. I don't want to have to manage 20 VAs thus why will not assing one per VM Host.

I am running vRanger PRO 6.02 and VA 1.8.

vRanger server

in VMWARE (running vSphere 5.1 on about 20 VM Host)

Windows 2008 R2 ENT

4 vCPU

4 GB RAM

About 16 TB of storage (4 TB is via NAS and 12 TB is SATA via SAN/Fiber)

About 1.5 TB of new images a night (mostly incrementals) coming from on average about 120 systems a night

1 GB NIC

VA

version 1.8

4 vCPU (it will chew up about 8-10 GHz when running)

2 GB RAM

1 GB NC

default storage

Hello,

This morning i try to restore a VM from manifest file but vRanger says "check credentials" when i browse from manifest path.

The credentials i 've tried are goods ... I don't know what is the problem.

Thank you for your help.

I am backing up roughly a dozen VMs using vRanger B&R 5.5.0.25454.  Four of them are Windows Server 2008R2 SP1 VMs.  vRanger is installed on a physical machine and is saving its backup data to a Samba-based CIFS share exported from a physical SAN.

One of these VMs is a file server with ~1.5 TB of storage in Lazy Zeroed Thick Provisioned vmdisks.  It is hosted on a ESXi 4.1u2 host; it is running the current VMware Tools with a default install and McAfee 8.8i Enterprise AV.

When trying to back up this server, vRanger throws the following error on every incremental backup except the first one:

VM Name: BRLNT027
Result: Failed
Start Time: 9/11/2012 2:54:43 AM
End Time: 9/11/2012 3:00:20 AM
Duration (minutes): 6
Archive Size: 0 GB
Message: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 2268 - Out of memory condition

Originally all the VMs were set to Quiesce File System as many of them contain databases.  I moved this VM to a separate backup group with Quiesce File System turned off, but the problem persists.  The other ten VMs backup successfully without error consistently.

I was unable to find anything relevant in the Knowledge Base.  We are currently evaluating vRanger for purchase and this is a blocking issue.

Hi Everyone,

I have a short Question about vRanger 5.5 and the new VMware ESXi 5.1 Servers.

I have one new ESXi 5.1 Server and migrated a VM on this new System. I also upgraded the Hardware of the VM from Hardware-Version 8 to Hardware-Version vmx-09.

It seems that since that upgrade i can not backup my VM any more with the current vRanger Version (5.5). I also tried to delet the backup job and made a new one, but this didn't help.

Is there a compatonolity issue? Are vmx-09 not supported at the moment? Will it just work with vRagner 6? And if yes, when will be vRanger 6 released? =)

Thanks for your help!

Hi,

I have a vRanger backup from a ESX4 VM that I wish to restore to a completely different system and not located in anything managed or accessible by the vRanger that did the backup. Is it possible to restore from this vmdk.var file to .vmdk or at least something VMware workstation and ultimately ESXi 5 can run?

On the forums it appears that some extraction scripts/command line tools exist but the links are all to visioncore and those are broken. Could I use a trial version of VRanger 6 and do something here.

There are 3 files I can see in the vRanger backup copied to an external HD. It appears to be from vRanger v 4.5.2.16370

EMC_20121021_010007_F.Manifest.metadata

EMC_20121021_010007_F.VmConfig.metadata

EMC_20121021_010007_F_1_EMC-flat_vmdk.var

Part of the vmconfig follows

vRangerVersion>4.5.2.16370</vRangerVersion><CurrentSnapshot /><SnapshotLayouts /><VMConfig><changeVersion xmlns="urn:vim25">2012-10-13T23:53:41.168746Z</changeVersion><modified xmlns="urn:vim25">1970-01-01T00:00:00Z</modified><name xmlns="urn:vim25">EMC</name><guestFullName xmlns="urn:vim25">Ubuntu Linux (64-bit)</guestFullName><version xmlns="urn:vim25">vmx-07</version><uuid xmlns="urn:vim25">4230e631-b23b-01cd-83ed-2afd031cc393</uuid><instanceUuid xmlns="urn:vim25">50304715-cdbe-c5a1-11d2-bfc18080fd53</instanceUuid><npivWorldWideNameType xmlns="urn:vim25" /><npivTemporaryDisabled xmlns="urn:vim25">true</npivTemporaryDisabled><locationId xmlns="urn:vim25">564da9e8-622e-6303-3fc3-b6863b83e34a</locationId><template xmlns="urn:vim25">false</template><guestId xmlns="urn:vim25">ubuntu64Guest</guestId><alternateGuestName xmlns="urn:vim25">Ubuntu Linux (64-bit)</alternateGuestName><annotation xmlns="urn:vim25">vRanger Pro Backup: Type [Full] Result [Success] Time [2012/10/14 01:52:16 AM]

Hello,

i am evaluating vRanger. During this i tried to replicate a Linux-Gentoo VM. After some time after start of the replication i get the following error message:

An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: API Call failed with message: The device or operation specified at index '9' is not supported for the existing virtual machine platform.

In between i get this message also if i restore a Windows Server VM. This was working one time and then no more.

How can i solve this issue?

Best regards

Mathias

Hi,

have inherited an environment which i believe is not 100% right with regards to the backup of the virtualised mailbox servers.

setup is .

1x Exchange DAG

2 x mailbox servers hosted locally within the same data center

vRanger 5.3.1

When using vRanger, I find there are a number of cluster entries within the event logs, the databases are failed over to the DAG partner. The second server then starts its backup and the process starts failing over again to the first server. Aside from this generating calls for myself out of hours, confidence in being able to restore these maildatabases in a consistent state is not very high.

vzshadow64 is on the mbx Servers,

Looking at the KB93858 it doesnt really address the question around DAG environments. If there is such a document could you let me know please?

I will be looking at upgrading to version 6.x in the near future, sooner if this fixes my above issue.

Many thanks

Richard

d if we try to replicate a vm wich has a RAW volume we get this error

the RAW Volume is NOT SELECTED in the Replication Job

Meldung:Failed to take a memory snapshot, since the virtual machine is configured with independent disks.

is it possible to deselect the memory snapshot in vranger?

the message comes from the VCenter! it is not possible to make snapshots from machines with a 2nd HDD(RAW Physical)

Hi,

I have just gone through and tried to upgrade from 5.0 to 6.0.2 and got the error of "Catalog database failed to install - Reason: -1" when trying to install/upgrade the catalogue DB.

Everything goes through with out a hitch until we get to the catalogue error and then it roles it all back.

the log is below for the catalogue upgrade

Install Started: 15/04/2013 (Monday) 9:33:42

...Initializing Installation

Installation Start: 15

CatalogManager Version 1.0.520.22810 is already installed on your system. Upgrading to Version 6.0.0.33307

...Upgrading CatalogManager to Version 6.0.0.33307.

..Quest Catalog Service stopped.

..Copying files to temp folder

...Installing CatalogManager files.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\Config\Files

Extracted ..\..\Service\Release\Config\Files\BulkImportMap.fmt successfully.

Extracted ..\..\Service\Release\Config\Files\FileFilterTokens.txt successfully.

Extracted ..\..\Service\Release\Config\Files\ActivateWorkflowConfig.xml successfully.

Extracted ..\..\Service\Release\Config\Files\DeleteWorkflowConfig.xml successfully.

Extracted ..\..\Service\Release\Config\Files\SaveWorkflowConfig.xml successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager

Extracted ..\..\Service\Release\Vizioncore.CatalogManager.WCF.Service.exe successfully.

Extracted ..\..\Service\Release\Vizioncore.CatalogManager.WCF.Service.exe.config successfully.

Extracted ..\..\Service\Release\Autofac.dll successfully.

Extracted ..\..\Service\Release\Gurock.SmartInspect.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.CatalogManager.CoreLibrary.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.CatalogManager.DataAccess.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.CatalogManager.WCF.Library.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.CatalogManager.Workflow.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.Common.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.Cryptography.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.DataAccessExt.dll successfully.

Extracted ..\..\Service\Release\Vizioncore.Logging.dll successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller

Extracted ..\..\Setup\DatabaseInstaller\Autofac.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Gurock.SmartInspect.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.CatalogManager.CoreLibrary.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.CatalogManager.DataAccess.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.CatalogManager.DatabaseInstaller.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.Common.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.vRangerExternals.Localization.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.Cryptography.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.DataAccessExt.dll successfully.

Extracted ..\..\Setup\DatabaseInstaller\Vizioncore.Logging.dll successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller\zh-CN

Extracted ..\..\Setup\DatabaseInstaller\zh-CN\Vizioncore.vRangerExternals.Localization.resources.dll successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller\ja-JP

Extracted ..\..\Setup\DatabaseInstaller\ja-JP\Vizioncore.vRangerExternals.Localization.resources.dll successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller\de-DE

Extracted ..\..\Setup\DatabaseInstaller\de-DE\Vizioncore.vRangerExternals.Localization.resources.dll successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller\fr-FR

Extracted ..\..\Setup\DatabaseInstaller\fr-FR\Vizioncore.vRangerExternals.Localization.resources.dll successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller\Scripts\SchemaManager

Extracted ..\..\Setup\DataAccess\Scripts\SchemaManager\Create.sql successfully.

...Extracting Files to C:\Program Files (x86)\Quest Software\CatalogManager\DatabaseInstaller\Scripts\Catalog

Extracted ..\..\Setup\DataAccess\Scripts\Catalog\UserAdmin\CreateMixedModeUser.sql successfully.

Extracted ..\..\Setup\DataAccess\Scripts\Catalog\Upgrades\201008160922.sql successfully.

Extracted ..\..\Setup\DataAccess\Scripts\Catalog\Upgrades\201107211110.sql successfully.

Extracted ..\..\Setup\DataAccess\Scripts\Catalog\Upgrades\201110311124.sql successfully.

Extracted ..\..\Setup\DataAccess\Scripts\Catalog\Upgrades\201201191000.sql successfully.

CatalogManager Installation Completed.

...Installing Catalog Database

Installing Database Loudly

Catalog database failed to install - Reason: -1

...CatalogManager Installation failed. Rolling back changes.

...CatalogManager Installation failed. Rollback completed.

any help would be appreciated

Thanks

Hello!

Upgraded from 6.0 to 6.01 and for the first time I am able to do quiesced snapshots on my ESXi 5.1 hosts.  This is great.

However, I am noticing not only that these snapshots are slow, but that snapshots, quiesced or not, on my 4.1 hosts are very very painfully slower than before.

Snapshots on Linux hosts, which used to take seconds, are now taking 5-6 minutes.

What is odd is that taking a snapshot (whether quiesced or not) from vCenter takes the same amount of time for a given VM that it always has, it is only the snapshots taken by vRanger that are taking so long.

I had to change the inventory load timeout in the service config to 30 minutes to get all of my nightly backups to reliably complete.  Yes, some snapshots are taking over 20 minutes to complete--I have never had one take over 10 before.

So is this a bug, or a feature?