Consolidating unmounted and open snapshots after virtual machine backup

At times, one or more disks from a virtual machine will remain mounted and snapshots will remain following the backup of a virtual machine. The cause of this is generally due to their not being enough time to unmount the disks and consolidate the snapshots when the job completes.

This would require user interaction to firstly unmount the virtual machine disks and then perform a consolidation of the virtual machine virtual disks. As we can agree, this is a manual task that is perfect to be automated.

The below solution has a number of caveats, the backup solution/appliance is a virtual machine and the virtual machine contains no hard disks that are of the disk type ‘Independent – Nonpersistent’.

The script in its entirety can be downloaded from here. However, the below will describe the logic to remove the virtual machine hard disks and consolidate the virtual machines.

Once we have established a connection to the vCenter Server and specified the virtual machine running the backup appliance/solution we will retrieve a collection of virtual machines where the ‘RunTime.ConsolidatedNeeded’ value is equal to ‘True’.

$VMs = Get-View -ViewType VirtualMachine -Property Name, RunTime | Where-Object {$_.RunTime.ConsolidationNeeded -eq $True}

Then we will connect to the virtual machine hosting the backup appliance/solution and retrieve all the virtual machine hard disks where the persistence value is equal to ‘IndependentNonPersistent’.

$HardDisks = Get-VM $ComputerName | Get-HardDisk | Where-Object {$_.Persistence -eq 'IndependentNonPersistent'} 

We will then invoke the Remove-HardDisk cmdlet to remove the filtered virtual machine hard disks. In this instance we are only removing the hard disks and not deleting them permanently.

Get-HardDisk -VM $ComputerName -Name $HardDisks.Name | Remove-HardDisk -Confirm:$False

Once the virtual machine hard disks have been removed, we will now consolidate the virtual machine disks on each of the virtual machines returned in the collection.

(Get-VM $VM.Name).ExtensionData.ConsolidateVMDisks() | Out-Null

The above script will provide console output to report the status of the invocation and can be triggered as a scheduled task returning an exit return code dependant on the status of the invocation.

Configure vRanger Date Format to use system locale

The date format within the vRanger Backup & Replication product, does not use the system locale and by default is configured to use ‘en-US’ .

In order for the date format to use the system locale, you will need to remove the default ‘ForceCulture’ value in the ‘C:\Program Files\Dell\vRanger\Vizioncore.vRanger.Client.Shell.exe.config’ file.

The default value is as below:

 <add key="ForceCulture" value="en-US"/></appSettings>

By removing the value, and restarting the Dell vRanger service, this will now use the system locale.

 <add key="ForceCulture" value=""/></appSettings>

Using a least privilege user account for vRanger

I was recently configuring a vRanger deployment to which I wanted to configure the service account running the various services to run under the context of a least privelage user.

The service account will require log on as a service permissions, db_owner permissions to the vRanger database on the SQL Server instance and also write access to the repositories you have configured.

For reference of the required privelages for the vCenter installation, the following was obtained from the Dell support site (


vRanger Pro Powershell: Could not connect to http://localhost:2480/VAPIHost.svc

I recently compiled a number of powershell scripts (  with the vRanger Pro Powershell snap-in which queried the job status, using the Get-JobTemplate cmdlet.

I have since noticed I have received an error message on a number of occasions where the status is failed to be retrieved with the following:

Get-JobTemplate : Could not connect to http://localhost:2480/VAPIHost.svc. TCP

In order to resolve this issue and have the status information be returned, I made the following change to the configuration file ‘C:\Program Files (x86)\Quest Software\vRanger\PowerShell\vRanger.API.PowerShell.dll.config’ to increase the openTimeout value from the original configuration of 00:01:00 to 00:03:00 and restarted the vRanger API service and the cmdlet to retrieve the job status no seems to be more stable.

openTimeout="00:03:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"


vRanger backup jobs fail with host could not be identified

I recently was investigating an issue where backup jobs in vRanger failed for all VMs with the following error message:

An internal error occurred during execution, please contact Quest support if the error persists. Error Message: <VM>'s host could not be identified

This appears to be an inventory issue between vRanger and the vCenter server which was caused by the VMware VirtualCenter Server service not responding and requiring a restart prior to the jobs being invoked.

The above issue may be resolved by performing the following from the vRanger server:

1) Stop the vRanger API and FLR services.

2) Restart the vRanger service.

3) Start the vRanger API service.

4) Start the vRanger FLR service.

After performing the above I was able to successfully run a backup job which had previously failed.