Moving CMA from one MDS env to a different one

[jflemingeds]

Hi all, i'm starting a project where i'll be moving a CMA out of one MDS into a completely different MDS. The source CMA has global policy the destination MDS has no global policy.

IP will change
Hostname will not.

Any gotchas i should be aware of? Someone else has run through the process once already but i haven't. This is a bit new to me but everything is VMed so we'll be trying it there first.

[Yonathan]

Disable Global policy prior to migration

[cciesec2006]

Disable Global policy prior to migration

I've done quite a bit of these on NGx R65 and R70 but not since. It is a very simple process, not got-cha.

yes, you have to remove global policy from the existing prior to the migration. In other words, remove global policy from the CMA before you stop the CMA and get those 4 directories, tar them up and move them over the new MDS and begin your cma_migrate process.

[northlandboy]

I did lots of these around the R60(ish) days. Always worked pretty well, and thankfully I never had to deal with Global Policy.

So if they had it working well back then, you should be OK now.

The only other thing that might be relevant is making sure you handle that changed IP, since the policy on the managed firewalls probably won't allow connections from those systems. I used to create dummy objects in the old CMA with the new IPs, and give that same access as the existing management IP. Push policy from old system, then when you switch to the new system, it will allow management connections from the new IPs.

[cciesec2006]

I did lots of these around the R60(ish) days. Always worked pretty well, and thankfully I never had to deal with Global Policy.

So if they had it working well back then, you should be OK now.

The only other thing that might be relevant is making sure you handle that changed IP, since the policy on the managed firewalls probably won't allow connections from those systems. I used to create dummy objects in the old CMA with the new IPs, and give that same access as the existing management IP. Push policy from old system, then when you switch to the new system, it will allow management connections from the new IPs.

When you change the IP address of the CMA, don't you have to break SIC on the gateways anyway and re-SIC with the new CMA?

[Bob_Zimmerman]

When you change the IP address of the CMA, don't you have to break SIC on the gateways anyway and re-SIC with the new CMA?

That's a good question. If the CMA is moving to a completely different SIC domain (i.e., a whole separate MDS with no trust relationship with the original MDS), you would probably need to reestablish SIC. I'd expect that to work like an 'fwm sic_reset' on a SmartCenter.

Moving a CMA between MDSs in the same SIC domain (e.g., moving CMAs from a manager+container into a separate container) shouldn't require that, though. That should be more like changing the IP of a SmartCenter without resetting the ICA.

[cciesec2006]

That's a good question. If the CMA is moving to a completely different SIC domain (i.e., a whole separate MDS with no trust relationship with the original MDS), you would probably need to reestablish SIC. I'd expect that to work like an 'fwm sic_reset' on a SmartCenter.

Moving a CMA between MDSs in the same SIC domain (e.g., moving CMAs from a manager+container into a separate container) shouldn't require that, though. That should be more like changing the IP of a SmartCenter without resetting the ICA.

Completely agreed with your above statement. However, the OP said "Hi all, i'm starting a project where i'll be moving a CMA out of one MDS into a completely different MDS"

Based on that statement, I say it is a different SIC domain :-)

[jflemingeds]

Completely agreed with your above statement. However, the OP said "Hi all, i'm starting a project where i'll be moving a CMA out of one MDS into a completely different MDS"

Based on that statement, I say it is a different SIC domain :-)

Completed testing this morning. Well... can never have too much testing...

Did not remove global policy first.

Kept hostname of cma the same. Created a dummy vm firewall in pre move lab replication. Set sic on gateway. Added new cma ip to local policy for all checkpoint services both directions ( what north said basically ).

Exported cma
Exported global policy
Backed up lab firewall
Restored lab firewall in new lab (so many labs!)
Created cma (didn’t start it)
Imported cma
Major complaints about invalid licenses. Shell script loop to delete those
Import global policy (dst mds has no global policy)
Add new cma license
Open dashboard test sic to restored gateway. Works ( no sic reset needed)
Install policy goes without issue.
No logs.
Restart fwd
Now have logs

[msjouw]

Last year at this time I finished moving a set of 110 R77.30 CMA's and 50 more form 2 sets of different (VM and physical) servers to a new set of 3 MDS servers. Only snags I had was that sometimes after a policy push a VPN would die and would only come back after another policy push. But normally always after pushing the policy the logs started coming in without doing anything else.

The only problem is and remains the embedded boxes, even though you can update the ones with a fixed IP, the ones with a DAIP will not reconnect to the new management, so you need to update them from the device itself. So check for those IP's in Smatview Monitor before you migrate and updat them once the migration has worked out fine.
If you really want I can even give you all the steps I normally did for each CMA.

[jflemingeds]

Thanks for all the replies everyone. No smb firewall so no worries there.

[may_path]

Last year at this time I finished moving a set of 110 R77.30 CMA's and 50 more form 2 sets of different (VM and physical) servers to a new set of 3 MDS servers. Only snags I had was that sometimes after a policy push a VPN would die and would only come back after another policy push. But normally always after pushing the policy the logs started coming in without doing anything else.

The only problem is and remains the embedded boxes, even though you can update the ones with a fixed IP, the ones with a DAIP will not reconnect to the new management, so you need to update them from the device itself. So check for those IP's in Smatview Monitor before you migrate and updat them once the migration has worked out fine.
If you really want I can even give you all the steps I normally did for each CMA.

Hi,
I am working on exact same requirement, moving a CMA to another MDS, new hostname, new IP address. Never did this before, I will appreciate if you email me all the steps.

[msjouw]

For all the others as well, for a target R77.30 MDS these are the steps to migrate a CMA to another MDS, either with a higher version or with other name / IP. The migration towards R80.10 is quite similar but not all the way, the differences are in the creation of the new Domain, this needs to be done from the command line and also the import command is different. Also keep in mind that a Global Policy will also cause issues, unless you have exported and imported the global policy first it is better to remove it before migrating.
So here we go:

## All commands are executed on the Source MDS (Unless instructed otherwise)
mdsenv <Old-DomainName>
fw logswitch
mdsstop_customer <Old-DomainName>
cd $FWDIR/bin/upgrade_tools
./upgrade_export /var/log/export-<Old-DomainName>.tgz


export copy:
scp /home/admin/export-*.tgz admin@<IP Target MDS>:/home/admin/


## on target MDS create a new Domain with name <New-DomainName>, do not start!! and import file:
/home/admin/export-<Old-DomainName>.tgz


## As soon as the domain is created you can start below copying of the logfiles (incl Audit log) all on the Source MDS
mv /home/admin/export-*.tgz /home/admin/done/.
cd /opt/CPmds-R77/customers/<Old-DomainName>/CPsuite-R77/fw1/log
mv fw.adtlog 2018-04-16.adtlog
mv fw.adtlogaccount_ptr 2018-04-16.adtlogaccount_ptr
mv fw.adtloginitial_ptr 2018-04-16.adtloginitial_ptr
mv fw.adtlogptr 2018-04-16.adtlogptr
scp /opt/CPmds-R77/customers/<Old-DomainName>/CPsuite-R77/fw1/log/201* admin@<IP Target MDS>:/opt/CPmds-R77/customers/<New-DomainName>/CPsuite-R77/fw1/log/

[urziulian]

For all the others as well, for a target R77.30 MDS these are the steps to migrate a CMA to another MDS, either with a higher version or with other name / IP. The migration towards R80.10 is quite similar but not all the way, the differences are in the creation of the new Domain, this needs to be done from the command line and also the import command is different. Also keep in mind that a Global Policy will also cause issues, unless you have exported and imported the global policy first it is better to remove it before migrating.
So here we go:

## All commands are executed on the Source MDS (Unless instructed otherwise)
mdsenv <Old-DomainName>
fw logswitch
mdsstop_customer <Old-DomainName>
cd $FWDIR/bin/upgrade_tools
./upgrade_export /var/log/export-<Old-DomainName>.tgz


export copy:
scp /home/admin/export-*.tgz admin@<IP Target MDS>:/home/admin/


## on target MDS create a new Domain with name <New-DomainName>, do not start!! and import file:
/home/admin/export-<Old-DomainName>.tgz


## As soon as the domain is created you can start below copying of the logfiles (incl Audit log) all on the Source MDS
mv /home/admin/export-*.tgz /home/admin/done/.
cd /opt/CPmds-R77/customers/<Old-DomainName>/CPsuite-R77/fw1/log
mv fw.adtlog 2018-04-16.adtlog
mv fw.adtlogaccount_ptr 2018-04-16.adtlogaccount_ptr
mv fw.adtloginitial_ptr 2018-04-16.adtloginitial_ptr
mv fw.adtlogptr 2018-04-16.adtlogptr
scp /opt/CPmds-R77/customers/<Old-DomainName>/CPsuite-R77/fw1/log/201* admin@<IP Target MDS>:/opt/CPmds-R77/customers/<New-DomainName>/CPsuite-R77/fw1/log/

hi msjouw, great post

"...and also the import command is different."

what is the command to import the the database of the new Domain in R80.10, but(!) if the source database was exported still form R80.10 version?
we cand do the export with:
# /opt/CPsuite-R80/fw1/bin/upgrade_tools/migrate export /home/admin/Test_CMA-Export
create the new Domain with (without starting it):
# mgmt_cli --root true add domain name <my_domain_name> servers.ip-address <my_IP_address> servers.name <my_domain_server_name> servers.multi-domain-server <R80.10_multi-domain-server_Name> servers.skip-start-domain-server true
and finnaly we would have imported the exported database with :
# cma_migrate <source management tgz file> <target Domain Management Server $FWDIR directory>

but according to checkpoint, cma_migrate is supported when source database is exported from R77.xx, not form R80.10.
support says it might work, but not officially supported.
has anyone tested it?
otherwise, how can we import the Domain database in R80.10, if exported still from R80.10?

big THANKS!