vRanger Pro DPP error “Version string portion too short or too long”

2 10 2010

Got the above message after running a job for the first time in a version of Vizioncore vRanger upgraded to 4.5.3 DPP.

Couldn’t find the same error *in relation to vRanger* anywhere on the web, so raised a call with support. Thought I’d detail my findings here.

The exact scenario in my case:

A mixture of ESX OS versions, including 3.5, 4.1 and 4.2. Running a version of vRanger Pro around version 4.1.1. This had been working successfully for three of my virtual servers for around 6 months. Ideally, I’d have been backing up straight to external disk, ready for off-siting. However, although this worked fine on a number of external disk models in our other installation with an older version of vRanger, jobs failed repeatedly if I tried this on the installation in question.

Therefore, I had to run jobs direct to local disk, and then move the backup files to external disk after. Needless to say, this added a lot of time to the process, handholding to ensure sufficient free space on the disk / make sure the move process hadn’t failed, etc etc.

So having renewed my maintenence and bought some new licenses, I decided to install the latest version, to see if I’d now be able to back up straight to external disk. My chosen route was to uninstall the previous version, rather than upgrade, but to keep the existing database. This was upgraded during the install process, and generated no error messages.

However, upon running a job, I repeatedly got the error “Version string portion too short or too long”.  This was regardless of whether I backed up to extenal or internal disks.

Vizioncore support was very quick with the initial response, which was to remove all machines from the inventory (which moves jobs relating to them to “Disabled Jobs”), and re-add them. At this point, I did notice that the ESX host in question added itself to the inventory in a non fully qualified domain format, whereas the others were added as machinename.domain.extension.

I didn’t investigate this however, and attempted to re-run the job. This resulted in the same error message as before.

I emailed support again, and had to chase this time, as there was no response for a few hours, and it was getting close to the end of the week (hence carrying on and writing this up on a Saturday!). I suggested uninstalling the app, and choosing a different SQL instance for the DB location. Their response was that this should work, because the root cause was a difference between the actual host name of the ESX server, and the name of the server according to the inventory.

This reminded me of the fact that the machine had been pulled in to the inventory as machine name without FQDN, so I tried backing up another machine.

This worked perfectly, so the error is now narrowed down to the specific machine, which I’m about to remove / re-add to the inventory and re-test.

So, look out for any differences in server name in the inventory if you experience this error.

UPDATE: Found the actual cause for the difference in DNS name / entry in Inventory – ensure that the “Domain Name” value in “Configuration” –> “DNS Routing” is filled in. In my case, this was the reason for the machine name not including the FQDN in the entry

On a related note, I mentioned above the VM backups are moved to external disk for offsiting. I have a True Crypt encrypted volume on each of the external disks, so that the VM backups are encrypted. vRanger did not list the drive letter mapped to this volume as a drive when I tried backing up directly to the volume. It worked fine however, when I tried doing so to the internal disk.

I noticed that there is an “Encryption” option in this version of DPP, which I’ve just tested on an ESX server hosting 2 VMs, directly after carrying out a standard backup. The time taken was 22 minutes instead of 18. This is a 22% difference, so a fair increase, but I’m going to experiment implementing this for all of my servers, to see what the results are. If I can back up direct to disk, in an encrypted format, that’ll be a massive time saving overall.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: