Upgrading an R77.xx Multi-Domain Security Management with Migration

You can upgrade R77.xx to R80.20 with a migration procedure. Versions higher than R77.30 cannot be migrated.

A basic migration is when you upgrade the database from a source Security Management Server to a target Security Management Server of the same version.

In an advanced upgrade, the database from an R77.xx Security Management Server is migrated to an R80.10 server. When you migrate, you are exporting the upgrade from the source server and importing it to the target server.

We recommend that you use database export/import to upgrade.

Note - There has to be a valid license on the Multi-Domain Servers before you import the database.

To make sure a valid license is installed, run:

mdsenv && cplic print

If it is not already installed, then install a valid license now.

Important! In R80.10, the order that you import servers is crucial:

First you must import the Primary Multi-Domain Server.
Then you can import the Secondary Multi-Domain Servers and Multi-Domain Log Servers. If there are active Domain Management Servers on the Secondary Multi-Domain Servers, they must be upgraded before you upgrade the Multi-Domain Log Servers.

If there is no Primary Multi-Domain Server, you must first promote a Secondary Multi-Domain Server to be the Primary. See R80.10 Multi-Domain Security Management Administration Guide.

Exporting the Multi-Domain Server Databases

Export current Multi-Domain Server extracts the database and configuration settings from a Multi-Domain Server and its associated Domain Management Servers. It then stores this data in a single TGZ file. You can import this TGZ file to a newly installed Multi-Domain Server.

Note - In a High Availability deployment, you must export the primary Multi-Domain Server. If the target Multi-Domain Server uses a different leading IP address than the source server, you must change the Multi-Domain Server IP address and the external interface.

You can include the log files in the exported TGZ file. These log files are likely to be very large.

Export one database at a time. Start with the Primary Multi-Domain Server.
Make sure the Global Domain Management Server is Active on the Primary Multi-Domain Server.

To create the export file on a source Multi-Domain Server:

Stop all Check Point services:
# mdsstop
Go to the Multi-Domain Server context:
# mdsenv

# mcd
Mount the ISO file:
# mount -o loop /path_to/Check_Point_R80.10_Gaia.iso /mnt/cdrom
Go to the installation folder:
# cd /mnt/cdrom/linux/p1_install
Run the installation script:
# ./mds_setup
Run the Pre-Upgrade Verifier > enter 1 when this menu shows:
(1) Run Pre-upgrade verification only [recommended before upgrade]

(2) Upgrade to R80.10

(3) Backup current Multi-Domain Server

(4) Export current Multi-Domain Server

Or 'Q' to quit.

The pre-upgrade verifier analyzes compatibility of the management database and its current configuration. A detailed report shows the steps to do before and after the upgrade.

Note - The pre-upgrade verification is required when you upgrade to a new version. You do not need to run the verification when you migrate to the same version (without upgrading).
Read the Pre-Upgrade Verifier output and fix all errors according to the instructions.
After fixing the errors, open SmartConsole and reassign the Global Policy on all Domains.
Stop the services again:
# mdsstop
Run the installation script:
# ./mds_setup
Export the current Multi-Domain Server configuration > enter 4 when this menu shows:
(1) Run Pre-upgrade verification only [recommended before upgrade]

(2) Upgrade to R80.10

(3) Backup current Multi-Domain Server

(4) Export current Multi-Domain Server

Or 'Q' to quit.
Answer the interactive questions:
Would you like to proceed with the export now [yes/no] ? yes
Please enter target directory for your Multi-Domain Server export (or 'Q' to quit): /var/log
Do you plan to import to a version newer than R80.10 [yes/no] ? no
Using migrate_tools from disk.
Do you wish to export the log database [yes/no] ? yes or no

If you enter no to export the logs, the configuration is still exported.
Make sure this export file is created.:
# ls -l /var/log/exported_mds.DDMMYYY-HHMMSS.tgz
Calculate the MD5 for this file:
# md5sum /var/log/exported_mds.DDMMYYY-HHMMSS.tgz

Importing the Database to the Primary Multi-Domain Server

Import the Multi-Domain Server configuration that you exported.

Important - When you transfer the exported database from the source to the target, use binary mode during the transfer.

To import the Multi-Domain Server configuration:

Install R80.10 Multi-Domain Security Management on the target Multi-Domain Server.
When you complete the upgrade process for the Primary Multi-Domain Server, the Multi-Site upgrade is not finished. You can only access objects that are stored on other Multi-Domain Servers when the upgrade process for the other Multi-Domain Servers is complete.
Log in to Expert Mode.
Transfer (with FTP, SCP, or similar) the exported configuration file collected from the source to the new server:
exported_mds.DDMMYYY-HHMMSS.tgz
Calculate the MD5 for the transferred file and compare to the MD5 that was calculated on original server:
# md5sum /<directory>/exported_mds.DDMMYYY-HHMMSS.tgz
Make sure a valid license is installed:
# mdsenv

# cplic print

If it is not already installed, then install a valid license now.
Import the configuration:
$MDSDIR/scripts/mds_import.sh <path_exported_database>/exported_mds.DDMMYYY-HHMMSS.tgz
Test the target installation.
Disconnect the source server from the network.
Connect the target server to the network.
On the target server, run: mdsstart

Importing the Database to Secondary Multi-Domain Servers and Multi-Domain Log Servers

Import the Multi-Domain Server configuration that you exported to a Secondary Multi-Domain Server or Multi-Domain Log Server. If you have multiple servers, import the database to one server at a time.

Important - When you transfer the exported database from the source to the target, use binary mode during the transfer.

Before you begin:

In the Primary Multi-Domain Server.
Log into Expert Mode.
Back it up:
# mds_backup -b –d /var/log
Install R80.10 Multi-Domain Security Management on the target Multi-Domain Server.
Make sure the Primary Multi-Domain Server is running.
Make sure that the Primary Multi-Domain Server has the correct license to work in Multi-Site environment.
Make sure that there is good connectivity between all the Multi-Domain Servers. System databases, logs, and Global Domains are upgraded only on the Primary Multi-Domain Server. The connection is necessary to synchronize the other Multi-Domain Servers and Multi-Domain Log Servers.
The IP address of the source and target Secondary Multi-Domain Servers and Multi-Domain Log Servers must be the same.
Make sure a valid license is installed on the Secondary Multi-Domain Server:
# mdsenv

# cplic print

If it is not already installed, then install a valid license now.

To import the Multi-Domain Server configuration:

Log in to Expert Mode.
Transfer (with FTP, SCP, or similar) the exported configuration file collected from the source to the new server:
exported_mds.DDMMYYY-HHMMSS.tgz
Make sure the transferred file is not corrupted. Calculate the MD5 for the transferred file and compare to the MD5 that was calculated on the source Multi-Domain Server:
# md5sum /<directory>/exported_mds.DDMMYYY-HHMMSS.tgz
Make sure that there is connectivity to the newly upgraded Primary Multi-Domain Server.
Import the configuration:
# $MDSDIR/scripts/mds_import.sh -primaryip <IP_primary_server> <path_to_exported_database>/exported_mds.DDMMYYYY-HHMMSS.tgz
On the Primary Multi-Domain Server, make sure that the Full Sync task completes successfully.
Test the target installation.
Disconnect the source server from the network.
Connect the target server to the network and run the mdsstart command on it.

After you complete the upgrade of all secondary Multi-Domain Servers and the Multi-Domain Log Servers, you must update the version of the Domain Management Server and the Domain Log Server objects.

To update the version of the Domain Management Server and Domain Log Server objects on the Multi-Domain Servers:

Connect to the command line on the Primary Multi-Domain Server, and make sure that all the Domain Management Servers are up. Run:
# mdsstat
Make sure to disconnect all SmartConsoles.
Go to the main Multi-Domain Server context:
# mdsenv
On each Domain Management Server and Domain Log Server that you import, upgrade the attributes of all managed objects:
# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <Name of Domain Management Server or Domain Log Server>

Note - Because the command prompts you for a 'yes/no' for each Domain and each object in the Domain, you can explicitly provide the 'yes' answer to all questions with this command:

# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <Name of Domain Management Server or Domain Log Server>
Open SmartConsole and make sure that the version for each of the upgraded objects is R80.10.

Migrating Each Domain Management Server Gradually

Attention:

This upgrade method is supported only when you upgrade from R7x versions.

We recommend to upgrade the entire Multi-Domain Server at once with one of these methods:

Because upgrade of the entire Multi-Domain Server at once is the default recommended method, use the Gradual Migration of Domain Management Servers only in these cases:

The entire Multi-Domain Server cannot be upgraded at once because of a business impact.
During the upgrade, you need to rename some or all of the Domain Management Servers.
In Multi-Domain Server High Availability deployment, you need to change the number of Domain Management Servers on Multi-Domain Servers.

If you use the Gradual Migration method:

You must migrate the Global Policies before you migrate the databases from other Domains.
You can migrate the Global Policies only one time from the R7x Multi-Domain Server.
Until the entire migration procedure is completed, you cannot make changes in the Global Policies on the source Multi-Domain Servers.
If you need to make changes on the source Multi-Domain Servers, follow these guidelines:
- If you deleted or modified a global object in the source R7x Multi-Domain Server database, you must make the same changes in the migrated Global Policies on the target R80.10 Multi-Domain Server.
- If you added a global object in the source R7x Multi-Domain Server database, you must delete that global object before you export the databases from other Domains.

Notes:

In a gradual upgrade, you export each Domain Management Server one at a time from the source Multi-Domain Server to a target Multi-Domain Server of the latest version.

The gradual upgrade does not keep all data.

Data that is not exported	To get this data in the new environment
Multi-Domain Server administrators and management consoles	Redefine and reassign to Domains after the upgrade.
Status of global communities	Run these commands: `mdsenv` `fwm mds rebuild_global_communities_status all`

Data that is not exported

To get this data in the new environment

Multi-Domain Server administrators and management consoles

Redefine and reassign to Domains after the upgrade.

Status of global communities

Run these commands:

mdsenv

fwm mds rebuild_global_communities_status all

Migrating Global Policies

You can migrate the global policy only one time. We recommend that you do not change the global policy on R77.xx until you move all the Domain Management Servers to the R80.10 Multi-Domain Server.

If you have to change the global policy after you have migrated it, follow these guidelines:

If the global object was deleted or edited on the source Multi-Domain Server, you have to make the same change manually on the R80.10 Multi-Domain Server.
If you added new objects to the global policy, you have to remove them from the policy before you export the Domain Management Servers. Otherwise, cma_migrate on the target Multi-Domain Server fails.

migrate_global_policies upgrades a global policy database from a Multi-Domain Server and imports it to an R80.10 Multi-Domain Server.

Note - When you execute the migrate_global_policies utility, the Multi-Domain Server is stopped.

Before you run the migrate_global_policies utility, make sure that you remove all the data from the global database of the R80.10 Multi-Domain Server.

Upgrading Global Policy from R77.xx to R80.10

Upgrading the global policy is supported for R77.xx only. You cannot upgrade the global policy when the source is R80.xx.

To upgrade Global Policies from R77.xx to R80.10:

On the R77.xx Multi-Domain Server, extract the Management Server Migration Tool from the R80.10 ISO, if you did not do this already.
Go to the main Multi-Domain Server context:
# mdsenv
Run:
# cd <full path to migrate command>

# ./migrate export <output file>
Copy the TGZ file from the R77.xx server to the R80.10 Multi-Domain Server.
On the R80.10 Multi-Domain Server, g to the main Multi-Domain Server context:
# mdsenv
Make sure a valid license is installed:
mdsenv

cplic print

If it is not already installed, then install a valid license now.
Migrate the Global Policies:
# migrate_global_policies <full_path_exported_tgz>
Start the Multi-Domain Server:
# mdsstart
If there is a Secondary Multi-Domain Server, synchronize the global databases in SmartConsole.

Migrating an R77.xx Domain Management Server Database

This procedure exports, updates, and imports the database of an R77.xx Domain Management Server to an R80.10 Domain Management Server.

Important - This procedure is not supported for migration of versions R80 and above.

Before you begin:

Make sure that there is one Active Domain Management Server in each Domain to be migrated.
If you want to import logs with the database, run a log switch before you export.
Make sure that you migrate the database only on one Domain Management Server. If you migrate a database to more than one Domain Management Server, the import fails and shows an error message.
Initialize the ICA.

To import from R77.xx Domain Management Server to R80.10:

On the Multi-Domain Server with the active global policy, get the Management Server Migration Tool from the R80.10 CD or ISO.
Extract the tools.
Extraction makes the upgrade_tools subdirectory.

In this path, extract the Multi-Domain Security Management tools - p1_upgrade_tools.tgz

For example:

Install from CD:

# gtar xvfz /mnt/cdrom/linux/upgrade_tools/linux/p1_upgrade_tools.tgz -C /var/opt/export_tools

Install from DVD:

# gtar xvfz /mnt/cdrom/Linux/linux/upgrade_tools/linux/p1_upgrade_tools.tgz -C /var/opt/export_tools
Go to the context of the Domain Management Server. Run:
# mdsenv <IP address or Name of Domain Management Server>
Run:
# cd <full path to migrate command>

# ./migrate export [-l] <output file>
- The migrate export command exports one Domain Management Server database to a TGZ file.
- The output file must be specified with the fully qualified path. Make sure there is sufficient disk space for the output file.
- The optional –l flag includes closed log files and SmartLog data from the source Domain Management Server in the output archive.

On the R80.10 Multi-Domain Server, run this (long) API command to create a new Domain and a new Domain Management Server (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

Important! - After you create the new Domain with this command, do not change the Domain IP address until you run the cma_migrate command.

Copy the TGZ file from the source Domain Management Server to the R80.10 Multi-Domain Server. Import the exported database:

# unset TMOUT

# cma_migrate <source management tgz file> <target Domain Management Server $FWDIR directory>

For example:

# cma_migrate tmp/orig_mgmt.tgz /opt/CPmds-R80/customers/cma1/CPsuite-R80/fw1

This command updates the database schema before it imports. First, the command runs pre-upgrade verification. If no errors are found, migration continues. If there are errors, you must change the source Domain Management Server according to instructions in the error messages. Then do this procedure again.

Upgrade the attributes of all managed objects in each target Domain Management Server:

# mdsenv

# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <Name of Domain Management Server>

Note - Because the command prompts you for a 'yes/no' for each Domain and each object in the Domain, you can explicitly provide the 'yes' answer to all questions with this command:

# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <Name of Domain Management Server>
If the R80.10 server has a different IP address than the R77.xx server, establish trust with the Security Gateways.
If the R77.xx server managed VPN gateways, configure the keys.

Important - To do a Domain Management Server migration on a Secondary Multi-Domain Server, you must set the state of its Global Domain to Active.

Procedure:

Connect to the command line on the Secondary Multi-Domain Server.
Log in to Expert Mode.
Run this command before you perform the first migration on the Secondary Multi-Domain Server:
# mdsenv && $CPDIR/bin/cpprod_util CPPROD_SetValue FW1 LastIpsUpdate 1 `date +%s` 1
Connect with SmartConsole to the Secondary Multi-Domain Server.
From the left Navigation Toolbar, click Multi Domain > Domains.
Right-click the global domain of the Secondary Multi-Domain Server and click Connect to Domain.
A window shows for the global domain.
Click Menu > Management High Availability.
In the Management High Availability status window, select Actions > Set Active for the Connected Domain.

Certificate Authority Data

The cma_migrate process does not change the Certificate Authority or key data. The R80.10 Domain Management Server has SIC with Security Gateways. If the IP address of the R80.10 server is not the same as the IP address of the R77.xx server, you must establish trust between the new server and the gateways.

Before you begin, see sk17197 to make sure the environment is prepared.

To initialize a Domain Management Server Internal Certificate Authority:

Remove the current Internal Certificate Authority for the specified environment, run:
# mdsstop_customer <IP address or Name of Domain Management Server>
# mdsenv <IP address or Name of Domain Management Server>
# fwm sic_reset
Create a new Internal Certificate Authority, run:
# mdsconfig -ca <Name of Domain Management Server> <IP address f Domain Management Server>
# mdsstart_customer <IP address or Name of Domain Management Server>

Resolving Issues with IKE Certificates

With a VPN tunnel that has an externally managed, third-party gateway and a Check Point Security Gateway, there can be an issue with the IKE certificates after you migrate the management database.

The Security Gateway presents its IKE certificate to its peer. The third-party gateway uses the FQDN of the certificate to retrieve the host name and IP address of the Certificate Authority. If the IKE certificate was issued by a Check Point Internal CA, the FQDN contains the host name of the original management server. The peer gateway will fail to contact the original server and will not accept the certificate.

To fix:

Update the external DNS server to resolve the host name to the IP address of the relevant Domain Management Server.
Revoke the IKE certificate for the gateway and create a new one.

Migrating from Standalone to Domain Management Server

Migration from Standalone to R80.10 Domain Management Server is supported only from R77.30 and lower versions. You need to separate the Security Management Server and Security Gateway on the Standalone. Then you manage the former-Standalone computer as a Security Gateway from the R80.10 Domain Management Server.

Note - To undo the separation of the Security Management Server and Security Gateway on the Standalone, back up the Standalone computer before you migrate.

Before migrating:

Make sure that the target Domain Management Server IP address can communicate with all Gateways.
Add an object to represent the Domain Management Server (name and IP address) and define it as a Secondary Security Management Server.
Install policy on all managed Gateways.
Delete all objects or access rules created in Steps 1 and 2.
If the Standalone computer already has Security Gateway installed:
- Clear the Firewall option in the Check Point Products section of the gateway object. You may have to first remove it from the Install On column of your Rule Base (and then add it again).
- If the gateway participates in a VPN community, remove it from the community and erase its certificate. Note these changes, to undo them after the migration.
Save and close SmartConsole. Do not install policy.

To migrate the management database to the Domain Management Server:

Go to the fully qualified path of the migrate export command.
Run:
# ./migrate export [-l] <output file>
On the R80.10 Multi-Domain Server, run these API commands to create a new Domain and a new Domain Management Server (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

Important! After you create the new domain with this command, do not change the domain IP address until you run the cma_migrate command.
Migrate the TGZ file from the source Domain Management Server to the R80.10 Multi-Domain Server.
Import the exported database:
# unset TMOUT

# cma_migrate <source management tgz file> <target Domain Management Server $FWDIR directory>

For example:

# cma_migrate tmp/orig_mgmt.tgz /opt/CPmds-R80/customers/cma1/CPsuite-R80/fw1

This command updates the database schema before it imports. First, the command runs pre-upgrade verification. If no errors are found, migration continues. If there are errors, you must change the source Domain Management Server according to instructions in the error messages. Then do this procedure again.
If the R80.10 server has a different IP address than the R77.xx server, establish trust with the Security Gateways.
If the R77.xx server managed VPN gateways, configure the keys.
In SmartConsole, from the left navigation panel, click Gateways & Servers and locate:
- An object with the Name and IP address of the Domain Management Server primary management object (migrated).
  Previous references to the Standalone management object now refer to this object.
- An object for each Security Gateway managed previously by Security Management Server.
Edit the object of the Primary Management Server and remove all interfaces (Network Management > Topology > select an interface > Remove).
Create an object for the Security Gateway on the Standalone machine (from New > Gateway), and:
- Assign a Name and IP address for the Security Gateway.
- Select the appropriate Check Point version.
- Enable the installed Software Blades.
- If the Security Gateway belonged to a VPN Community, add it back.
- Do not initialize the Secure Internal Communication (SIC).
Run Domain Management Server on the Primary management object. In each location, consider changing to the new Security Gateway object.
Install the policy on all other Security Gateways, not the new one.
Note - If you see warning messages about this Security Gateway because it is not yet configured, ignore them.
Uninstall the Standalone deployment.
Install a Security Gateway on the previous Standalone machine.
From the Domain Management Server SmartConsole, edit the Security Gateway object, define its topology, and establish trust between the Domain Management Server and the Security Gateway.
Install the policy on the Security Gateway.