Replacement of ESA C680 to C695

[Givara B]

Hi Team 

I am in the process of replacing the ESA (2) C680 appliance to (2) C695 appliance due to EOF and support for C680. So I would appreciate any suggestions or best practices on how-to-process with this appliance migration/replacement.

My Idea is to keep the current cluster configuration on OLD appliance, break the cluster and add one new C695 at a time, load the configuration so that configuration is synchronized on the new device, enable listener on it and check if is taking the message queue and continue with the second left C695 device.

Any suggestion/demo/vedio/links will be highly appreciated.

Thanks
Givara

[balaji.bandi]

Personally i build as below : (let me know if that works)

1. i will take the backup from exiting kit.

2. Build new kit with same version and restore the config from backup.

3. if any new stable version available, upgrade on the new kit (make sure if you managing using SMA, that is compatable and required upgrda SMA too)

4. build network connectivity for the new Appliance inline with old one.

5. change window cut over to new applaince (by shut interface old device and bring new applaice no shut)

6. Testing and monitoring required.

(your plan should work breaking the cluster - take which ever works for business)

[Givara B]

One other things is that C680 devices are on version 12.5.2-011 and C695 devices are on version 12.5.3-035 will it be an issue when adding C695 v12.5.3-035  to existing cluster that run on version 12.5.2-011 ?

[balaji.bandi]

i would suggest to have same version all time when you moving the config and migration taking.

what i suggest - try to import the config old to new see any errors.

for cluster always suggest all should be same version (some time hardware also same)

All ESAs MUST have the same AsyncOS versions (down to the revision).

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/200885-ESA-Cluster-Requirements-and-Setup.html

[Ken Stieers]

Versions have to match exactly upgrade the 680s to match the 695s first.

[Givara B]

Thanks for info.
Is there a way to expert the private key on ESA machine ? or where the location of the private key ? 

I have expert the Certificate from the old C680 but i was thinking or need to expert the private key as well 

[balaji.bandi]

i do not recall you can export key, you can only export certificate.

[Ken Stieers]

If you cluster them, or restore the config, the key comes over.

You could probably pull the key out of the config file too.

[Givara B]

I found this on community
https://community.cisco.com/t5/email-security/certificate-private-key/td-p/3203952

[Ken Stieers]

Confirmed on 14.2.1-015, if you export a cert, and set a password, the key comes with it.
The file it saved is a PFX even if you don't name it that.

[Givara B]

Well we have version 12.5.2-011 on C680, or at least we can upgrade it to 12.5.3-035. So should the private key by with the certificate as well as on these versions?
when I exported the certificate, the system requests to set a password for the certificate to be exported otherwise the certificate can't be exported. 

[Givara B · Accepted solution]

Well the plan worked:

"My Idea is to keep the current cluster configuration on OLD appliance, break the cluster and add one new C695 at a time, load the configuration so that configuration is synchronized on the new device, enable listener on it and check if is taking the message queue and continue with the second left C695 device."
Notes:
1. Machine level configuration can be set before the migration with respect to routing tables, spam quarantine and other stuff that can be find from the configuration file. And leave all cluster configuration which will be synchronized during the migration. 
2. Upgrade or make sure all devices (old and new ones) are on same versions.
3. As you add a new device (add one a time) to cluster - & check: Certificate, feature keys, AMP, SMTP routes, Listeners, LDAP, DNS, NTP, Proxy, Incoming/Outgoing Mail Policies, RAT table and Destination controls
And after resumelistener and check the Incoming Mail, System status and Delivery status.
4. If Step 3 goes well- delete an old device that you suspend it. and repeat step (3-4) for other new devices that needs to be added in existing cluster.
5. Take MX record on consideration if you want to use same on or / have new MX record before migration.