Migration Email Security Gateway from physical ESAs to a virtual ESAs

[kyawkyawnaing]

Objective

Transforming SMA and ESAs from physical instances to virtual instances while minimising disruptions.

Scenario

We have one SMA and two ESA Clusters, deployed across two different locations. Our on-premise MS Exchange setup involves both inbound and outbound email traffic. Location A serves as the primary outbound location, while Location B acts as the backup, becoming active only in the event of Location A's failure.

Pre-migration
1. Syn existing SMA to vSMA
2. Add existing ESA to vSMA
3. To join vESA existing cluster
4. Sync configuration existing ESA and vESA

note: Smoothly up to this point, utilising a cluster of four instances consisting of both Physical ESA and virtual vESA.

Questions
1. What is the recommended approach for removing an existing physical ESA from the cluster?
2. Is there a method to redirect traffic to the virtual vESA?
3. If I disconnect the existing ESA from the network, will the traffic automatically be redirected to the vESA?

I appreciate your valuable input.

[Ken Stieers]

1. What is the recommended approach for removing an existing physical ESA from the cluster?

In the cli, 

clusterconfig removemachine

Then power the one you're removing off.

2. Is there a method to redirect traffic to the virtual vESA?

Traffic flow is not controlled by the cluster at all.  For your outbound mail from exchange, you add the new vESAs to the send connector that sends mail out exchange and remove the physical ESAs.  For incoming mail, you'll want to NAT the new vESA public interfaces to an external address on the firewall, allow port 25 to them, then register A records and MX records to point at the new A records.

(That all assumes you have the ESAv on new ip.addresses)

3. If I disconnect the existing ESA from the network, will the traffic automatically be redirected to the vESA?

No, see number 2.

One way to do it would be (conservitive, testing at each step):

1. make sure the vESAs can send mail out. NAT them to the outside, access rules for port 25 on the firewall, A records in external DNS, SPF record updated, etc.   TEST THIS.  I do it by using a command line tool called BLAT to send mail to the "outbound" ip to my personal account to make sure all everything is lined up.

2. Add the new new vESAs to the Exchange outbound Send connector.  Check that mail is flowing out through them (Mail Reporting/Delivery Status).  Once you know mail flow is working as expected when it hits the vms, you can pull the physical boxes out of the send connector.

3. Add MX records for new ESAv, you should start to see some inbound flow... make sure that mail flow looks right.

4. Remove old MX records, A records, clean up SPF, remove old nat/access rules

5. Suspend delivery on the old boxes so they empty their queues remove cluster, shutdown