Solved: Moving ESAs to a new SMA

scott.hutchings1 · ‎10-11-2016

We have several ESAs, both physical (8.5) and Virtual (9.6), and a 9.5 SMA. We've encountered an issue, as well as a future upgrade path, which requires that we migrate the SMA to the 9.7 code base. Unfortunately, we can't upgrade the Physical ESAs and due to version incompatibility and the 8.5 Physical boxes won't be able to communicate to the new 9.7 SMA.

Our solution is to introduce a new 9.5 SMA (SMA2), which will be used solely by the existing 8.5 physical boxes, while we migrate the existing SMA (SMA1) and rest of the environment to 9.7 and eventually 10.x.

The new SMA2 is already up and running, and we just need to break the connections from the 8.5 machines, and reassociate them to SMA2.

The question is, how?

Has anybody done this before, and what hurdles did you face?

dmccabej · ‎10-11-2016

Hello Scott,

Yes, that's exactly what I was looking for. Thanks!

From reading through your initial message, I'm going to assume you have two clusters setup, one for the virtual ESA/s and one for the physical ESA/s.

(NOTE: You will probably want to suspend the listeners on the physical ESA/s during this process so that nothing gets sent to the wrong SMA. Once the steps are completed, you can resume)

+++

We should be able to accomplish this request in a few steps :

1) Log into SMA1 and remove the physical ESA/s under Centralized Services --> Security Appliances --> Commit Changes.

2) Log into SMA2 and add the same physical ESA/s under Centralized Services --> Security Appliances --> Submit --> Commit Changes.

1) Log into the clustered set of physical ESA/s and confirm the PVO quarantine settings reflect the new SMA2 under Security Services --> Policy, Virus and Outbreak Quarantines.

2) Then, while still on the clustered physical ESA/s, navigate to Security Services --> Spam Quarantine and update to use the new SMA2 IP address --> Submit --> Commit Changes.

+++

After that, everything should now be officially moved over. If not, I would recommend opening up a TAC case for immediate assistance so we can help confirm the configuration.

Hope that helps!

Thanks!

-Dennis M.

View solution in original post

dmccabej · ‎10-11-2016

Hello Scott,

The needed steps would depend on what services you're centralizing over to the SMA. You can confirm this on the SMA by navigating to Centralized Services --> Security Appliances and by noticing which services are checked. (IE: Reporting / Tracking / PVO / Spam Quarantine)

Can you provide that information?

Thanks!

-Dennis M.

scott.hutchings1 · ‎10-11-2016

That page isn't coming up for me. I suspect it uses an externally hosted page to render data so our firewalls are going to block it.

That said, I did go in through the CLI on the SMA and ran:

Config
Appliance Config

And these are the current settings listed there. (IPs redacted)

Name - Policy Quarantine - Safelist Block list - Email Reporting - Tracking
=============== ================ ============= ========== =========
App_CC_c160 - Enabled - Disabled - Enabled - Enabled
UAT_APP_CC - Enabled - Disabled - Enabled - Enabled
App_EP_c160 - Enabled - Disabled - Enabled - Enabled

Is that what you're asking for?

dmccabej · ‎10-11-2016

Hello Scott,

Yes, that's exactly what I was looking for. Thanks!

From reading through your initial message, I'm going to assume you have two clusters setup, one for the virtual ESA/s and one for the physical ESA/s.

(NOTE: You will probably want to suspend the listeners on the physical ESA/s during this process so that nothing gets sent to the wrong SMA. Once the steps are completed, you can resume)

+++

We should be able to accomplish this request in a few steps :

1) Log into SMA1 and remove the physical ESA/s under Centralized Services --> Security Appliances --> Commit Changes.

2) Log into SMA2 and add the same physical ESA/s under Centralized Services --> Security Appliances --> Submit --> Commit Changes.

1) Log into the clustered set of physical ESA/s and confirm the PVO quarantine settings reflect the new SMA2 under Security Services --> Policy, Virus and Outbreak Quarantines.

2) Then, while still on the clustered physical ESA/s, navigate to Security Services --> Spam Quarantine and update to use the new SMA2 IP address --> Submit --> Commit Changes.

+++

After that, everything should now be officially moved over. If not, I would recommend opening up a TAC case for immediate assistance so we can help confirm the configuration.

Hope that helps!

Thanks!

-Dennis M.

dmccabej · ‎10-11-2016

(ALSO NOTE: You may receive an error when trying to remove the physical ESA/s from SMA1 during step 1 (Error - Can't delete the appliance because PVO service is enabled remotely). In this case, you'll want to disable Centralized PVO on the physical ESA/s, then remove from SMA1 and add to SMA2, and then re-enable Centralized PVO.)

scott.hutchings1 · ‎11-23-2016

Dennis,

The instructions they were a great help!

Due to some firewall issues, the Security Appliances pages don't work on our SMA. (It's been broken since enabling Advanced Malware). but I was able to work through these instructions using the Command Line and the migration went off without a hitch!

Thanks for your assistance!

dmccabej · ‎11-23-2016

Hello Scott,

You're very welcome! I'm glad it helped! :)

As for the Security Appliances page issue, that's related to a known defect and you'll need to allow SMA access to panacea.threatgrid.com over port 443. It seems like you already figured out the workaround though. :)

Happy holidays!

-Dennis M.