Jump to content

ERA Virtual Appliance Migration / Upgrade v6.2 to v6.5


M4rkA
 Share

Recommended Posts

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?

EsetRA-MigrationBackupPull.png

EsetRA-MigrationError.png

Link to comment
Share on other sites

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)

config_server_va.png

Link to comment
Share on other sites

  • ESET Staff

Just to describe what is going on, even you found working workaround.

Once you initiated upgrade of whole appliance by pulling database from your older OVA, SERVER inside new OVA was installed, but once it started, it took some time until it was accessible from network, and that is reason why installation of AGENT failed, which resulted in OVA that was "optically" not working. It was actually almost ready for use, especially SERVER was already running. What actually helped in your case was re-configuration of new appliance, which technically executed "repair" over SERVER and finalized remaining operations. They were this time successful because SERVER was already upgraded and thus it took much less time to initialize. Updating system should not affect this issue. It is required to wait until SERVER is fully upgraded, which should not take more than an hour.

For those than experience this issue, there are few alternatives, where the easiest and recommended is to to upgrade SERVER inside old ova appliance (components upgrade task), and once this is done, and SERVER is running, migration to new OVA may be performed.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...