Hello,

I messed up the vRanger installation during the upgrade from version 5.5.0 to version 6.1. The upgrade failed during the installation of the catalog database and services.

the services are not running correctly cause I made a misstake during the installation.

I tried to deinstall vRanger with the default Windows routine in the control panel, which failed in the middle. vRanger is still showing up in the Windows Software pane, but I can't deinstall it again with the normal deinstall button. it simply fails.

I tried to install vRanger again, but it tells me, that vRanger is already installed with version 6.1.

I can't boot the vRanger user interface, cause it still tries to boot my previous version 5.5.0. and stops, when it comes to the database connection.

the vRangers services are also not showing up in the windows services list.

So I stuck in the middle of nowhere.

Is there an instruction to manually deinstall vRanger (remove registry, files, services,...)

I still have the vRangerPro database and of course also a backup of it. The vRanger SQL server, that is hosted on an own sql server, was already upgraded to the 6.1 version during the initial upgrade before it got messed up.

I won't loose anything, if someone could tell me to cleanly deinstall the vRanger Pro version from the Server and do a reinstall.

By the way I host the vRangerPro software on a Windows 2008R2 server. The VRanger version is now somenthing between 5.5.0 and 6.1. :-)

I'd be very gratefull for any advice,

thanks in advance,

e.g.

Hello

Our vRanger 5.3 is backing up multiple VMs on multiple hosts without problems. Only one Linux VM on an ESXi 5.0 fails every time.

The messages in the log are:

[2012-02-22 09:10:49.425]: Gathering data for Srv03_Linux from API completed.

[2012-02-22 09:10:49.425]: Backup task will be attempted using a VDDK network connection.

[2012-02-22 09:54:26.269]: Backing up disk 'vix:r:192.168.145.51:902:[esx05_datastore2] Srv03_Linux/Srv03_Linux.vmdk:moref=vm-39253:snapshot-39727:3' completed.

[2012-02-22 09:54:28.675]: Checking and enforcing retention policy completed.

[2012-02-22 09:54:37.003]: Removing snapshot for vRanger completed.

[2012-02-22 09:54:43.769]: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: The database trasaction was rolled back.

The machine is copied over the network, but at the end something fails and the backup is deleted from the repository. I think the error message is misleading, as I have run SQL Profiler and could not see an SQL error.

Thank you very much for your help!

We run a vRanger 6.0.1 nightly job to back up approximately 180 VMs residing across 4 vSphere 5.1 hosts.  Every morning there are several VMs in vCenter that show up with the "virtual machine disks consolidation is needed" yellow exclamation warning on them.  It is not always the same VMs, just a random handful every night.  Manual consolidation is needed on them as the delta files are left on the VMs.  The vRanger task log for a problem VM indicates no problems, "Removing snapshot for vRanger completed."  There isn't a single error throughout the task log.  So from the vRanger standpoint, it thinks it completed correctly.  I assume this is because of poor error handling however as if you look at the events for the VM in question in vCenter, coinciding at the same time as vRanger removing the snapshot line in its log, you see events for "Task: Remove snapshot" followed within seconds by "Virtual machine disks consolidation is needed" followed immediately by "Virtual machine disks consolidation failed."  So the reference to the snapshot is being removed but consolidation fails leaving the snapshot in an orphanned ghosted state and growing until manual consolidation is performed.

All of these VMs that experience this problem are using Machine-based VDDK SAN "HotAdd" so I am assuming that the physical server that runs vRanger is not letting go of the VMDK before consolidation is attempted so the VMDK lock is preventing the consolidation from occurring.  The SANs in question are a pair of EqualLogics connected via iSCSI to both the vSphere hosts and the physical server that runs vRanger.

Any ideas how to prevent this from happening?

Hello,

I messed up the vRanger installation during the upgrade from version 5.5.0 to version 6.1. The upgrade failed during the installation of the catalog database and services.

the services are not running correctly cause I made a misstake during the installation.

I tried to deinstall vRanger with the default Windows routine in the control panel, which failed in the middle. vRanger is still showing up in the Windows Software pane, but I can't deinstall it again with the normal deinstall button. it simply fails.

I tried to install vRanger again, but it tells me, that vRanger is already installed with version 6.1.

I can't boot the vRanger user interface, cause it still tries to boot my previous version 5.5.0. and stops, when it comes to the database connection.

the vRangers services are also not showing up in the windows services list.

So I stuck in the middle of nowhere.

Is there an instruction to manually deinstall vRanger (remove registry, files, services,...)

I still have the vRangerPro database and of course also a backup of it. The vRanger SQL server, that is hosted on an own sql server, was already upgraded to the 6.1 version during the initial upgrade before it got messed up.

I won't loose anything, if someone could tell me to cleanly deinstall the vRanger Pro version from the Server and do a reinstall.

By the way I host the vRangerPro software on a Windows 2008R2 server. The VRanger version is now somenthing between 5.5.0 and 6.1. :-)

I'd be very gratefull for any advice,

thanks in advance,

e.g.

Hello everyone.

On a two node vsphere 5.1 cluster I've created two new vm windows 2012. i created two replication jobs and two backup jobs.

the replication jobs worked at the first run but the backup job fail every time.

The source vm is 50 GB and there is plenty of space in destination folder.

On both esxi datastores i have aproximately 45 GB free

i tried to unregister & register the vm, restart vranger server, restart esxi managment service to no avail.

i have another backup job with other vm on the same vranger server that runs successfully.

Could anyone help with that issue ?

here is the failed job log that is generated:

Thanks

[2013-05-23 23:52:24.913]: vRanger Backup & Replication - v6.0.1.31606

[2013-05-23 23:52:24.944]: Selected Options: Compress backed up files. | Update notes with the latest backup results. | Enable Active Block Mapping (ABM). | Selected SpaceSavingTech: None | Included Disks [27, 2, 19, 13, 20, 55, 60, 3, 17, 58, 21, 25, 9, 23, 14, 4, 11, 38, 29, 7, 54, 34, 33, 26, 35, 31, 49, 5, 51, 37, 56, 12, 28, 32, 62, 61, 48, 45, 43, 15, 47, 52, 53, 30, 16, 1, 41, 50, 36, 24, 22, 63, 46, 10, 59, 39, 18, 8, 44, 64, 57, 6, 40, 42].

[2013-05-23 23:52:24.944]: Task for virtual machine SRVSQL was queued.

[2013-05-23 23:53:08.127]: SourceVm:SRVSQL | Uuid:4207eb6f-668a-17a0-e3f3-3c018716c4d9 | VC:192.168.1.171, Host:srvesx1.local [ESXi 5.1.0]

[2013-05-23 23:53:08.127]: Beginning backup task for SRVSQL

[2013-05-23 23:53:08.127]: Starting task validation.

[2013-05-23 23:53:08.127]: Connection to srvesx1.local was properly validated.

[2013-05-23 23:53:08.143]: srvesx1.local is properly licensed.

[2013-05-23 23:53:08.143]: Test connection to repository Daily Backup starting...

[2013-05-23 23:53:09.753]: Test connection to repository Daily Backup successful!

[2013-05-23 23:53:09.862]: Ending task validation... success!

[2013-05-23 23:53:09.862]: Beginning initialization of backup information.

[2013-05-23 23:53:09.862]: Retrieving the tasks parent information.

[2013-05-23 23:53:09.987]: Retrieving save points for any full backups associated with this job.

[2013-05-23 23:53:10.003]: Finished initialization of backup information successfully.

[2013-05-23 23:53:10.003]: A Full backup will be run for this task.

[2013-05-23 23:53:10.050]: Gathering credentials for SRVSQL completed.

[2013-05-23 23:53:10.159]: Checking for VMotion completed.

[2013-05-23 23:53:10.565]: Gathering data for SRVSQL from API completed.

[2013-05-23 23:53:10.800]: Gathering data for srvesx1.local from API completed.

[2013-05-23 23:53:11.284]: Retrieving the VM BIOS configuration completed.

[2013-05-23 23:53:11.534]: Gathering credentials for srvesx1-vRangerVA completed.

[2013-05-23 23:53:11.816]: Gathering data for srvesx1-vRangerVA from API completed.

[2013-05-23 23:53:11.878]: Running a backup task completed.

[2013-05-23 23:53:11.925]: 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.

I recently upgraded from vReplicator 3 to vRanger 6.0.2 (or rather, stood up new service and created new jobs).

Ever since, the snapshot removal process takes at least 3x as long as it used to.  As a result some services that are picky are now stopping and/or losing connection to databases which is of course bad for the VMs that I'm replicating regardless of time of day.

I don't know what I can do to change this behavior unless it is the VA-HotAdd "feature" that is making it this extra slow.  The task 'Reconfigure Virtual Machine' isn't taking but 5 seconds, so that can't be it.

If this cannot be corrected I have no choice but to continue using vReplicator 3.x and re-enable all the old jobs.

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 there,

some weeks before we have uninstalled vRanger V5.x on a physical server and reinstalled it on a virtual Server. We had it running for at last a week and proofed everything is working, even FLR. Then we updated vRanger to version 6.1.0.35402 which is the current version on the server.

All backup jobs run fine and we can do a full restore also, but File Level Restore doesn't work on any machine. The attempt always ends with "Error: Mount failed".

According to KB article 83269 we started testing:

1) added everyone - full permissons to D:\Temp

2) added the Repository admin explicitely to D:\Temp

3) added it explicitely to the local Admin group

- non of that is working, by the way, the account we use to back up and restore is a member of the  Domain Admin group.

I tried to do FLR from the NAS device (NetApp) and local disc, both fails. Then I tried to do do a FLR from Manifest and when I use the service account we use, we also get the "Error: Mount failed". Using my own admin account (which is no Domain admin) I get two Exclamation marks in the dialogue.

As you can hopefully see on the screenshot, all folders are created, but the disks are not mounted, the folders are completely empty.

Can you help with that?

Regards

Matthias

Hello,

i want to backup physical clients. I have to stop a service on this clients because

the vRanger aborts the job with errors when this service remains active.

When the vRanger job is finished, the service must restarting again.

Is there a possibility to achieve this goal automatically - for example, by script?

If so, how can i implement this?

Thank you!

Ruediger

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]

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

This is a new version of the popular reposync script. (http://communities.quest.com/thread/10839?tstart=0)

Thanks to collaboration with R&D the script works with all repo types. Based on support experience, few extra features have been included.

Features:

1. Supports all repo types.
2. Depending on immediate goal, synchronizes either whole repo or set of directories.
3. Thoroughly validates each SP. Practically what Ranger does while importing.
4. Imports both VM and physical server SPs.
5. Displays SP being processed at the moment, number of found SPs and processing time for each SP.
6. Revives retention if an original template (and corresponding job/task) that created imported SPs still exists.
7. Expires old SPs with given threshold date. Integrity of Incr/Diff set is preserved.
8. Creates/updates a GlobalManifest (for RW shares) and saves a copy into dump directory.
9. Keeps extensive log for deeper analysis.

Instructions:

1. Download archive.
2. Place it on any Windows machine with PowerShell ver. 2 or greater. Script is autonomous, BET are prepackaged. Thus there is no need to execute it from Ranger itself.
3. Extract files from archive.
4. Launch PowerShell console as administrator.
5. Allow script execution if necessary:
   Set-ExecutionPolicy unrestricted
6. Change directory to the script location, e.g. c:\BETreposync
7. Execute script
   .\reposync03

Note for users with DDBoost repositories.

DDBoost repos proved to be the slowest to import/sync. It does not mean though that this repo type shows bad performance during backup/restore.

The script reads 2 metadata files for each SP. Correspondingly BET metadata.exe is executed.

Just for comparison, single metadata call against CIFS repo takes less than a second. The best result for a single metadata call against DDBoost repo was 4.3 s.

Also there is an open bug for the case where metadata read takes 6 minutes. Devs are looking into the issue, there are few components to check: BET - cygwin - DDBoost API - Datadomain firmware.

Tested against vRanger 5.4/5.5 and 6.0.2. Script won't work for Ranger 5.3 or earlier version.

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.

================ update. 05/28/2013 ==================

New version of the script has been posted:
http://communities.quest.com/thread/23459?tstart=0

Hey guys.

I have a problem with the logs from Exchange 2010 VM after a Backupjob. Normaly the vRanger delete the logs automatically after the job is finished.

But since a few weeks the logs are not deleted. Have anyone an idea what will be happen or what is wrong??

Versions:

Exchange --> 2010 on 2008R2 Standard

vRanger --> 5.2.1

vSphere --> ESXi 4.1 Update 2

Thanks for help in advanced!

Greets, Matthias

Hi,

our customer is running vRanger 5.3.1 - since a couple of days we have the problem that the repository cannot be updated. Also adding a new repository is not working - error message that the credentials are wrong or have unsufficient priviliges. We can search for the CIFS share but cannot add it. Mounting the share with the credentials within Windows works without any problem.

We already tried to reinstall vRanger - the second time we completely removed vRanger before reinstalling it - problem still persists.

Could not find anything in the knowledge base - any hint?

Thanks, Benjamin

Hi all,

I’ve recently started looking after a vRanger server which is in US. All the machines in there are getting backed up as normal however onthree machines I get same message and they fail every time.

Message is “Backup failed: An internal error occurredduring execution, please contact Vizioncore support if the error persists.  Error Message: 2654 -  can't read phys:/vmfs/volumes/49a88c4e-d71a666c-2155-00237d22803a/hostname/hostname-000001-flat.vmdk[at io_size:125]”

I’ve rebooted the server and that did not help.

I found two links but I am confused which one is correct .......

http://www.lo0.ro/2011/vranger-5-cant-read-phys-vmfs-volumes/

http://quest-software.uat3.hosted.jivesoftware.com/thread/1927

Hostname changes in the error message forother machines. Here we are running vRanger backup and replication 5.0.0.19238.

Any suggestions on why this is failing?

Thank you in advance

Good day All.

Just changed my vRanger Server (w2k8X64 R2) from one domain to anoher and now I am unable to backup.The Dashboard shows vCenter and both ESXs as disconnected, if try to remove them they do not disappear. After a while a component error shows up and says "the application has stopped working, would you like to continue or quit"... I've changed all services that had the old domain account to the new one, they start fine. but still nothing.

Can you help me out?

Thanks a lot.

We are regulalry seeing this failure message and once it hits then all following backups fail (obviously). I'm guessing it's associated with the metadata.exe processes being stuck as I can guarantee I will see many of these whenever we see the failure message.

I'm at the point now where I have to reboot every other night to ensure success, which is crazy I'm sure you will agree. Does anyone have any idea when this will ever be resolved. This has got worse since upgrading to 5.5.

Thanks for any suggestions or pointers.

I had replication jobs in vRanger working properly while running vCenter Server 5.1 and vRanger 6.1.0.35402.  I then updated the vCenter Server and all five ESXi hosts to version 5.5 and added two clusters to my existing vCenter configuration, giving me a total of three clusters.  I then removed all jobs in vRanger and removed the inventory objects.  I re-added the VC instance in vRanger, added credentials for each of my five hosts, applied vRanger licensing to four of the five hosts (the host that is not vRanger-licensed is the host in my disaster recovery center), and successfully created and tested several backup jobs.

What is broken, however, are newly created replication jobs.  I cannot get replication jobs to run.  During the configuration of a replication job, I am met with a message stating "no credentialed hosts found".