M4rkA

Thanks for the detailed explanation Martin. In summary then, are you are saying that after the database pull / restoration had reported back as finished, and the VM was restarted, that the initial setup from the web console should not be run straight away, that up to an hour (ish) should be allowed for the server to finish upgrading? Or, should this period of waiting be after the initlal set up from the web console? Once the VM was restarted, the ERA was accessible over the network within a few seconds, else I wouldn’t have been able to log on to the initial setup page from its web console. How do you know how long to wait? Is there any visual indication of the server completing this at any point? If the recommended upgrade path is still a component upgrade task from within an existing server first (which does make sense), and then migration to a new VM, if desired, perhaps the ERA v6.5 upgrade / migration instructions on the following page should be altered to reflect this?: hxxp://help.eset.com/era_deploy_va/65/en-US/index.html?va_upgrade_migrate.htm Thanks again for taking the time to read my post.

In case anyone else runs into a similar issue, I'm now up and running, and the database has indeed been migrated to the new v6.5.31.0 VM. On restarting the new VM after the initial web configuration, and being given the "First time appliance configuration failed." error, I thought I'd log in to the Webmin web console for further investigation (enter the management mode of the VM, and choose "Enable/Disable Webmin interface" to toggle this on/off - by default it was disabled). Once in Webmin, there was an entry under Servers for ESET Remote Administrator, but this was blank, probably as to be expected. The Webmin Dashboard was flagging up that there were package updates available (290 of them), so I thought it was worth a try. I let these package updates download and install, and restarted the VM. After this, I logged back on to the web console for VA configuration (hxxp://help.eset.com/era_deploy_va/65/en-US/index.html?config_va.htm), choosing "ESET Remote Administrator Server Appliance" again, for the initial set up. I only entered something in the password field, as shown below, leaving all the network setting fields blank (as I have done previously). "Submit" was clicked, the VM restarted, and the VM console then loaded without the "First time appliance configuration failed." error, showing "Server version: 6.5.417.0, Agent version: 6.5.417.0, Rogue Detection Sensor version: 1.0.1079.0). Huzzah! On logging in to the new ERA web console (port 8443), the old database seems to be intact - computers and static groups are there, custom policies look to be copied across and in place, quarantine and threat logs seem to be there etc. The only thing I've seen so far that needed to be added, that wasn't present, was our license details under Admin -> License Management. In conclusion, it looks like the package updates in Webmin saved the day. 8)

In trying to upgrade our existing Eset RA virtual appliance (RA Server v6.2.200.0, Agent v6.2.200.0, Rogue Detection Sensor v1.0.880.0, CentOS x64 v6.7) to the latest version (v6.5.31.0), I'm not having much joy. I'm trying to migrate to the new server, as per here: hxxp://help.eset.com/era_deploy_va/65/en-US/index.html?va_upgrade_migrate.htm We use Hyper-V, running on Windows Server 2012 R2. Creating the VM using the ERA_Appliance_v6.5.31.0.vhd file works fine. Pulling the database across from the old appliance to the new, and restoring it seems to work fine. However, failure occurs after having set up the new appliance for the first time, from its web console. After this, the new appliance restarts and gives the error "First time appliance configuration failed". I've tried this first time configuration from the web console with domain / network settings fully populated, and these left blank with only a password set. Both scenarios fail with the same result. Migration via this method to v6.5.31.0 is listed as being supported on all previous 6.x versions of the VA, but it's not working for me. Backing up the old database from the v6.2.200.0 VM isn't listed as an option in its VM management mode console, unlike newer versions, else I'd try setting up the new server afresh and then restore the old database to it after it is completely up and running. Anyone have any ideas?