ā11-08-2022 01:34 AM - edited ā11-08-2022 03:09 AM
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
Solved! Go to Solution.
ā11-11-2022 07:09 AM
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.
ā11-08-2022 01:53 AM
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)
ā11-08-2022 03:07 AM
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 ?
ā11-08-2022 03:27 AM
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).
ā11-08-2022 03:33 AM
ā11-10-2022 04:04 AM
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
ā11-10-2022 05:31 AM
i do not recall you can export key, you can only export certificate.
ā11-10-2022 05:36 AM
ā11-10-2022 05:38 AM
I found this on community
https://community.cisco.com/t5/email-security/certificate-private-key/td-p/3203952
ā11-10-2022 06:02 AM
ā11-10-2022 06:11 AM - edited ā11-10-2022 07:19 AM
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.
ā11-11-2022 07:09 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide