This post will be a collection of thoughts and my own experiences when migrating from a physical C160 to a virtual C100V appliance. Other IronPort ESA P2V appliances may be similar so it’s worth reading on!
Firstly let’s talk about the Configuration Migration Tool that Cisco developed. Unfortunately it has not been maintained or developed over the years so it probably won’t be very helpful for you… it certainly wasn’t for me. The latest version (last updated in 2013) can only support the following models:
“For ESA migration from hardware to virtual, version must be 7.6.x*
(for instance, 7.6.1 or 18.104.22.1684).
For ESA migration from virtual to hardware, version must be 8.0.0*
(for instance, 8.0.0 or 22.214.171.1241).”
Also, don’t even bother trying to migrate from a physical appliance running AsyncOS 8.x to a virtual appliance running 9.X unless you want to know how it feels to go insane.
The best way to perform the migration is to have both physical and virtual appliances on the same version.
As of this post, you can download two versions of the virtual appliance. 8.5.6 and 9.0. The aim is to get the physical and virtual appliances on the same version so that the configuration backup and restore can be as pain free as possible (and maintain our sanity).
Note that in my case, AsyncOS 9.X will not be supported on the C160 hardware so I made sure my physical appliance was on the most up to date 8.5.6 release and downloaded the 8.5.6 virtual appliance.
Matching up the physical and virtual interfaces
Now, on the virtual appliance, you’ll have three interfaces. Management, Data 1 and Data 2. On the C160 you only have Data 1 and Data 2 so you won’t be able to just import your config without making some (really easy) modifications.
What I did was:
- export the configuration from the virtual appliance and find the sections labelled <interface_name>Management</interface_name> and
- Export the physical appliance config
- Replace the sections listed above in the physical config from the ones in the virtual config
Note that if you are bringing up the virtual appliance in the same network as the currently live physical appliance then you will want to change the hostname and IP addresses (in the config file or after the restore but before the commit) or you’re going to have a bad time. In my case, I changed the management address but kept the other interfaces the same but disconnected in VMWare.
Correcting the update server
Before continuing, you will also need to make a change to the update server on the virtual appliance as it will not be correct.
You will know if your update server needs fixing if you cannot download the latest anti-spam definitions, feature keys or get any of the following errors:
Web UI: Failure downloading upgrade list
CLI: Failure downloading upgrade list: Received invalid update manifest response
To fix the issue:
- Log in to CLI
- Run the command updateconfig then subcommand dynamichost
- Make sure the server is update−manifests.sco.cisco.com:443
See this URL for more information @ http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118065-maintainandoperate-esa-00.pdf
I generated and imported the license keys after the config restore so it probably doesn’t matter which way you do this.
Note that you need to import the licence file via the CLI using the command loadlicence
Dormant Feature Keys
If you see ‘Dormant’ in the ‘Status’ column in the feature keys section then you will need to click in to those sections in the web interface and accept the EULA otherwise those features will remain disabled – annoying but that’s the way it’s done.
For example, if Sophos Anti-Virus is dormant then you need to go to:
- Security Services
- Edit Global Settings…
- Accept EULA
That’s it as far as my notes go – I will update this post if I come across anything else that could be useful.
Feel free to comment using the comment section below.