Upgrading Multi-Domain Security Management

In This Section: Upgrade Multi-Domain Security Management Tools Upgrading Multi-Domain Security Management on Smart-1 and Open Servers Upgrading a High Availability Deployment Restarting Domain Management Servers Restoring Your Original Environment Removing Earlier Version Multi-Domain Server Installations Changing the Multi-Domain Server Interfaces IPS with Multi-Domain Security Management Enabling IPv6 on Gaia

This section includes procedures for upgrading Multi-Domain Security Management to R77.

Upgrade Multi-Domain Security Management Tools

This section describes the different upgrade and migrate utilities, and explains when and how each of them is used.

Pre-Upgrade Verifiers and Correction Utilities

Before performing the upgrade the Multi-Domain Security Management upgrade script, UnixInstallScript, runs a list of pre-upgrade utilities. The utilities search for well-known upgrade problems that might be present in your existing installation. The output of the utilities is also saved to a log file. Three types of messages are generated by the pre-upgrade utilities:

• Action items before the upgrade: These include errors and warnings. Errors have to be repaired before the upgrade. Warnings are left for the user to check and conclude whether they should be fixed or not. In some cases, it is suggested that fixing utilities should be run during the pre-upgrade check, but in most cases the fixes are done manually from SmartDashboard. An example of an error to be fixed before the upgrade is when an invalid policy name is found in your existing installation. In this case, you must rename the policy.
• Action items after the upgrade: These include errors and warnings, which are to be handled after the upgrade.
• Information messages: This section includes items to be noted. For example, when a specific object type that is no longer supported is found in your database and is converted during the upgrade process, a message indicates that this change is going to occur.

Container2MultiDomain Tool

In versions prior to Multi-Domain Security Management R75, you had the option of dividing functionality between two physical Multi-Domain Server platforms:

• Multi-Domain Server Containers hosted the Domain Management Server (formerly CMA) databases.
• Multi-Domain Server Managers hosted the system and Global Object databases.

The current version no longer uses this architecture. All Multi-Domain Servers host all management databases.

Versions R75 and later use a different licensing model. All converted Multi-Domain Servers must have the appropriate new licenses.

Check Point developed the Container2MultiDomain utility to help administrators convert their old Multi-Domain Server Containers to the new single platform architecture.

• You can still use your old Multi-Domain Server Containers in a R75 deployment without conversion. Appropriate licenses are required.
• You must attach the appropriate R75 licenses to the upgraded Multi-Domain Server Container before using the Container2MultiDomain utility.
• Container2MultiDomain is applicable only to versions R75 and later.
• You can only use Container2MultiDomain if all of these conditions are true:
  • The Multi-Domain Server must have a license that includes the CPSB-GLBP or CPSB-BASE blades.
  • The Multi-Domain Server must be a Container.
  • The Multi-Domain Server must be running.
• You must restart all Multi-Domain Servers in your deployment after using Container2MultiDomain. You do not need to restart your Domain Management Servers.

Running Container2MultiDomain

After upgrading an old Multi-Domain Server Container, this message shows to remind you that you can use Container2MultiDomain to do the conversion.

The installation has indicated that this server is a Container MDS. When converting this server to a Multi-Domain Server, after logging in again to the shell, please add the required Software Blade.   Run the Container2MultiDomain utility and follow the instructions.

Converting a Multi-Domain Server is optional.

To use the utility:

1. Run Container2MultiDomain from the Multi-Domain Server command line.
2. When this message opens, enter yes.

   This utility will convert a Container MDS to a Multi-Domain Server. Please make sure the server is up before continuing. Would you like to continue [yes/no] ? yes

   This message opens when the process completes.

   This server will be converted from a Container MDS to a Multi-Domain Server. Registry has been updated. mdss::sight Updated Successfully Multi-Domain Server database has been updated. Please restart ALL the Multi-Domain Servers in your environment for changes to take effect.

Export Tool

The Export current Multi-Domain Server option in mds_setup 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.

Run mds_setup from the DVD, from the linux/p1_install/ directory

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.

migrate export Command

The migrate export command exports the content of one Domain Management Server or Security Management Server database into a TGZ archive file. This archive file serves as the source for the migration tools described below. The migrate utility is included on the Multi-Domain Security Management distribution DVD.

Note - Before you migrate using migrate export, in a Management High Availability environment: In Security Management - In SmartDashboard, delete all secondary management objects from the primary Security Management Server. In Multi-Domain Security Management - When you migrate Domain Management Servers one at a time, in the SmartDashboard of the primary Domain Management Server, delete the secondary Management Server object.

To install the migrate utility:

1. Locate the p1_upgrade_tools.tgz archive file in the upgrade_tools subdirectory under the relevant operating system parent directory.
2. Extract the contents of the archive into a folder on the source computer (the computer hosting the Domain Management Server or Security Management Server).

Installation 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

The database to import is the database belonging to the primary Domain Management Server/Security Management Server. Before you import, make sure that the database is synchronized.

If you want to migrate your current High Availability environment to a Domain Management Server High Availability on a different Multi-Domain Server, export the database. Then continue with a High Availability deployment (see the High Availability chapter in the R77 Multi-Domain Security Management Administration Guide).

To export the management database:

<fully qualified path to command> migrate export [-l] <output file>

The optional –l flag includes closed log files and SmartLog data from the source Domain Management Server in the output archive.

• The migrate command works on the current Domain Management Server. You must use the mdsenv <Domain Management Server name> command to set environment to the current Domain Management Server (or to the Multi-Domain Server environment for the global policy) before you run the migrate command.
• The output file must be specified with the fully qualified path. Make sure there is sufficient disk space for the output file.
• Run a "log switch" immediately before you export the Domain Management Server to export the log files.

Example:

# cd /opt/CPsuite-R77/fw1/bin/upgrade_tools/

# mdsenv dms1

# migrate export -l /var/opt/dms1_exported.tgz

This example assumes that you are upgrading using the distribution CD or DVD.

cma_migrate Command

The cma_migrate command imports an existing Domain Management Server management database into a Multi-Domain Server. If the imported Domain Management Server is from a version earlier than that of the Multi-Domain Server, the upgrade process occurs automatically during the import.

You must run cma_migrate to import Domain Management Servers exported using the migrate export command. Copy the exported management database archive file to target Multi-Domain Server prior to using the cma_migrate command. Bear in mind that the source and target platforms may be different.

Before running cma_migrate, create a new Domain and a new Domain Management Server. Do not start the Domain Management Server.

If you are migrating a Domain Management Server to a new Domain Management Server with a different IP address, it is a different procedure.

Syntax:

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

Example:

# cma_migrate /tmp/exported_smc.tgz /opt/CPmds-r71/domains/dms2/CPsuite-R71/fw1

The first argument (<source management tgz>) specifies the path, on the Multi-Domain Server, to the source management data as obtained by the migrate utility. The second argument (<target Domain Management Server FWDIR directory>) is the FWDIR of the newly created Domain Management Server.

Note - You can run mdscmd migratecma to import files to a Domain Management Server, or you can use the SmartDomain Manager.

To run the cma_migrate utility from the SmartDomain Manager:

1. Right-click a Domain Management Server and select Options > Import Domain Management Server.
2. When you enter the path to the exported database file, include the name of the exported database file at the end of the path.

cma_migrate and Certificates

When running cma_migrate, pre-upgrade verification takes place. If no errors are found, then the migration continues. If errors are found, certain modifications must be implemented on the original Security Management Server, after which you must re-export the source.

Certificate Authority Data

The cma_migrate process does not change the Certificate Authority or key data. The R77 Domain Management Server has SIC with Security Gateways. If the IP address of the R77 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:

1. Remove the current Internal Certificate Authority for the specified environment, run:

   # mdsstop_customer <DomainServer Name or IP>
# mdsenv <DomainServer Name or IP>
# fwm sic_reset

2. Create a new Internal Certificate Authority, run:

   # mdsconfig -ca <DomainServer Name> <DomainServer IP>
# mdsstart_customer <DomainServer Name or IP>

Resolving Issues with IKE Certificates

With a VPN tunnel that has an externally managed, third-party gateway and a Check Point Security Gateway, sometimes there is 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.

migrate_global_policies Command

The migrate_global_policies command imports (and upgrades, if necessary) a global policies database from one Multi-Domain Server to another.

Note - migrate_global_policies is blocked if there are global policies assigned to Domains. Do not assign any Global Policy to Domains before you run migrate_global_policies.

If the global policy database on the target Multi-Domain Server contains polices that are assigned to Domains, the migrate_global_policies command stops. This is to make sure that the Global Policy used by those Domains is not deleted.

Note - When executing the migrate_global_policies utility, the Multi-Domain Server will be stopped. The Domain Management Server can remain up and running.

Syntax:

migrate_global_policies <path to exported tgz>

<path to exported tgz>: specifies the fully qualified path to the archive file created by the migrate export command.

Backup and Restore

The purpose of the backup/restore utility is to back up a whole Multi-Domain Server, including all the Domain Management Servers that it maintains, and to restore it when necessary. The restoration procedure brings the Multi-Domain Server to the state it was when the backup procedure was executed. The backup saves both user data and binaries.

Note - Backup and restore cannot be used to move the Multi-Domain Server installation between platforms.

Restoration can be performed on the original machine or, if your intention is to upgrade by replicating your Multi-Domain Server for testing purposes, to another machine. When performing a restoration to another machine, if the machine's IP address or interface has changed, refer to Changing the Multi-Domain Server IP Address and External Interface for instructions on how to adjust the restored Multi-Domain Server to the new machine.

During backup, you can view data but cannot make changes. If the Multi-Domain Security Management system consists of several Multi-Domain Servers, the backup procedure takes place manually on all the Multi-Domain Servers concurrently. Likewise, when the restoration procedure takes place, it should be performed on all Multi-Domain Servers concurrently.

mds_backup

The mds_backup command backs up the complete Multi-Domain Server, including all the Domain Management Servers, binaries, and user data. If the Multi-Domain Security Management environment has multiple Multi-Domain Servers, backup runs on all of them at the same time.

This command requires Superuser privileges.

mds_backup executes the gtar command on product root directories containing data and binaries, and backs up all files, except those specified in the $MDSDIR/conf/mds_exclude.dat file. The collected data is stored in a single .tgz file, in the current working directory, named with the date-time. For example: 13Sep2002-141437.mdsbk.tgz

To back up a Multi-Domain Server:

1. Go to a path outside the product directory. This is the working directory.

   It is important that you not run mds_backup from a directory that will be backed up, to avoid a circular reference. For example, do not run mds_backup from /opt/CPmds-R77.

2. Run: mds_backup
3. When the process is done, copy the .tgz file, with the mds_restore, gtar and gzip command files, to an external backup location.

Syntax mds_backup [-g -b {-d <target dir name>} -v -h]

Parameter	Description
-g	Executes without prompting to disconnect GUI clients.
-b	Batch mode - executes without asking anything (-g is implied).
-d	Specifies a directory store for the backup file. When not specified, the backup file is stored in the current directory. You cannot store the backup file in any location inside the product root directory tree.
-v	Verbose mode - lists all files to be backed up, but do not perform the backup operation.
-l	Exclude logs from the backup.
-h	Help - displays help text.

Comments When using the -g or -b options, make sure that no GUI clients or log servers are connected. If there are client connections, the backup can be corrupted if changes are made during the backup process.

Active log files are not backed up, to avoid read-during-write inconsistencies. It is best practice to run a log switch before backup.

You can back up the Multi-Domain Server without log files. The .tgz will be must smaller. To make sure all logs are excluded:

1. Open: $MDSDIR/conf/mds_exclude.dat
2. Add: log/*
3. Save the file.

mds_restore

Use this command to restore a Multi-Domain Server that was backed up with mds_backup. It is best practice to restore to a clean install of the previous version. Use the Installation and Upgrade Guide for major versions, or the Release Notes for minor versions or hotfixes.

If the Multi-Domain Security Management environment has multiple Multi-Domain Servers, restore all Multi-Domain Servers at the same time.

To restore a Multi-Domain Server:

1. Go to the directory where the backup was created.
2. Log in to expert mode.
3. Run: ./mds_restore <backup_file>
4. If you restore a Multi-Domain Server to a new IP address, configure the new address.

Upgrading Multi-Domain Security Management on Smart-1 and Open Servers

You can upgrade Smart-1 appliances and open servers.

Multi-Domain Server In-Place Upgrade

The in-place upgrade process takes place on an existing Multi-Domain Server machine. The Multi-Domain Server, together with all Domain Management Servers, are upgraded in one procedure.

Note - When upgrading Multi-Domain Security Management, all SmartUpdate packages on the Multi-Domain Server (excluding Edge firmware packages) are deleted from the SmartUpdate Repository.

Before doing an in-place upgrade to R77:

1. Run the Pre-upgrade verification only option from UnixInstallScript. In a multi-Multi-Domain Server environment, do this on all Multi-Domain Servers.
2. Make the changes required by the pre-upgrade verification, and if you have High Availability, start synchronizations.
3. Test your changes:
   1. Assign the global policy
   2. Install policies to Domain Management Servers
   3. Verify logging using SmartView Tracker
   4. View status using the SmartDomain Manager or SmartView Monitor
4. Run mds_backup to back up your system.

Upgrade Requirements:

Ensure you have at least 6 GB of disk space available to do the upgrade.

• Using the Portal: Check the space available for images in the Maintenance > Image Management page.
• Using the CLI: In expert mode, run the df -h command and check the available space in /var/log.

To Upgrade Using Upgrades (CPUSE)

See Upgrading Using Gaia Upgrades (CPUSE).

To upgrade using an ISO image on a DVD:

1. Download the Gaia ISO image from the Check Point Support Center.
   Check_Point_Install_and_Upgrade_R77.Gaia.iso
2. Burn the ISO file on a DVD.
3. Connect an external DVD drive to a USB socket on the appliance or open server.
4. From Clish, run: upgrade cd
5. You are asked if you want to save a snapshot of the system before upgrade. We recommend that you answer Yes.
6. You are asked if you want to start the upgrade. Select Yes.

   The upgrade takes place.

7. After the upgrade, before rebooting, remove the DVD from the drive.
8. Type OK to reboot.

To upgrade using the upgrade package, with CLI:

You can upload the TGZ to the Portal, and upgrade Gaia with CLI commands.

1. Download the Gaia upgrade package from the Check Point Support Center.
   Check_Point_upg_Portal_and_SmartUpdate_R77.Gaia.tgz
2. In the Gaia CLI, enter expert mode.
3. Use FTP, SCP or similar to transfer the upgrade package to the Gaia appliance or computer. We recommend that you place the package in /var/log/upload.
4. Exit expert mode.
5. In Clish, register the file as an upgrade package. Run the command:
   add upgrade <version> package file <full path>
6. Run:
   upgrade local <version>

   For example:
   upgrade local R77

   You are asked if you want to save a snapshot of the system before upgrade. We recommend that you answer Yes.

7. The pre-upgrade verifier runs. The output is stored in a text file at /tmp/pre_upgrade_out.txt.
8. If you see the error: "Pre-upgrade verification failed" we recommend that you review the file, fix the problems, and restart the upgrade. Do not take another system snapshot.
9. You are asked if you want to start the upgrade. Select Yes.

Exporting and Importing a Multi-Domain Server

You can upgrade to the current version by replicating a deployment from existing (source) Multi-Domain Servers to target Multi-Domain Servers. This process combines a simplified methodology for upgrading a Multi-Domain Security Management deployment with the ability to thoroughly test the deployment prior to implementation.

Use mds_setup with the Export option, to extract database and configuration settings from a Multi-Domain Server, together with its Domain Management Servers, and then stores this data in a single TGZ file. If you are working with a High Availability deployment, you must export the primary Multi-Domain Server.

Run mds_setup from the DVD, from the linux/p1_install/ directory

Use the mds_import.sh command to import the contents of a saved TGZ file to a separate, newly installed Multi-Domain Server.

These commands export and import the following information:

• Global Multi-Domain Server database
• All Domain Management Servers
• GUI Clients
• Administrators and permissions
• Licenses
• Log files (optional)

Planning the Upgrade

Before you start the upgrade, consider these points:

• Make sure that the target Multi-Domain Server meets the minimum hardware and operating system requirements and is configured identically to the source Multi-Domain Server.
• If the target Multi-Domain Server uses a different leading IP address than the source Multi-Domain Server, you must change the Multi-Domain Server IP address and the external interface.
• You must upgrade all Multi-Domain Servers in your deployment, including High Availability and Load Sharing members.
• The target Multi-Domain Server should be on an isolated network segment so the Gateways associated with the source Multi-Domain Server are not affected until the process is complete and fully tested.

Exporting a Multi-Domain Server Deployment

After you begin to export from the source Multi-Domain Server, avoid making configuration changes on that Multi-Domain Server. Changes made after export starts are not included in the tgz file. You will need to make such changes manually on the target after you complete the upgrade.

Run mds_setup from the DVD, from the linux/p1_install/ directory

To export a Multi-Domain Server to a TGZ file:

1. Mount the Multi-Domain installation media to a subdirectory.
2. Change the directory to the mounted directory.
3. Browse to the linux/p1_install/ directory.
4. Run: mds_setup
5. Select the Export current Multi-Domain Server option.
6. Follow the instructions on the screen.
7. When prompted, choose whether or not you wish to save the log files to the tgz file.

Note - Exporting log files can significantly increase the tgz file size and the time required to complete the upgrade.

Importing a Multi-Domain Server deployment

To import a Multi-Domain Server deployment onto a target machine:

1. Perform a clean Multi-Domain Server installation on the target machine, according to the instructions for your specific platform.
2. Copy the appropriate exported tgz file from the source Multi-Domain Server to the new target Multi-Domain Server. The tgz file conforms to the following naming convention: exported_mds_<time & date stamp>.tgz
3. Run the mds_import.sh command on the target Multi-Domain Server. Follow the instructions on the screen.
4. Run mdsstart on the target Multi-Domain Server.
5. Test to confirm that the replication has been successful:
   1. Start the Multi-Domain Server.
   2. Verify that all Domain Management Servers are running and that you can connect to the Multi-Domain Server using the SmartDomain Manager and Global SmartDashboard.
   3. Connect to the Domain Management Servers using SmartDashboard.

Replicate and Upgrade

Choose this type of upgrade if you intend to change hardware as part of the upgrade process, or if you want to test the upgrade process first. The existing Multi-Domain Server installation is copied to another machine (referred to as the target machine) by using the mds_backup and mds_restore commands.

To perform the Replicate and Upgrade process:

1. Back up your existing Multi-Domain Server. Run one of these:
   • mds_backup
   • UnixInstallScript and select the Backup option
2. Install a fresh Multi-Domain Server on the target machine.
   To restore your existing Multi-Domain Server, first install a fresh Multi-Domain Server on the target machine that is the same version as the existing Multi-Domain Server.

   Note - Make sure the target machine is on an isolated network segment, so that Gateways connected to the original Multi-Domain Server are not affected until you switch to the target machine.

3. Restore the Multi-Domain Server on the target machine. Copy the files created by the backup process to the target machine and run: mds_restore.

   Important - In Gaia, run this command from expert mode and exit after running the command. You must run this command from the folder that contains the backup file. 1. Go to the folder that contains the backup file. 2. Enter ./mds_restore

4. If your target machine and the source machine have different IP addresses, change the IP Address of the restored Multi-Domain Server to the new IP address. If your target machine and the source machine have different interface names (for example: hme0 and hme1), change the interface of the restored Multi-Domain Server to the new interface name.
5. Test to confirm that the replication is successful:
   1. Start the Multi-Domain Server.
   2. Make sure that all Domain Management Servers are running and that you can connect to the Multi-Domain Server with SmartDomain Manager and Global SmartDashboard.
   3. Connect to Domain Management Servers using SmartDashboard.
6. Stop the Multi-Domain Server on the target machine and upgrade.
7. Run: Container2MultiDomain.
8. Start the Multi-Domain Server.

Gradual Upgrade to Another Computer

In a gradual upgrade, you export Domain Management Servers 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 Not Exported	To get this data in the new environment:
Multi-Domain Security Management Administrators and management consoles	Redefine and reassign to Domains after the upgrade.
Status of global communities	Run: mdsenv; fwm mds rebuild_global_communities_status all

To run a gradual upgrade:

1. Install the Multi-Domain Server on the target machine.
2. On the target Multi-Domain Server, create a Domain and Domain Management Server. Do not start the Domain Management Server.
3. Run: migrate export

   The migrate export command exports the Domain Management Server database to a .tgz file on the Multi-Domain Server. It also transfers the licenses for the Domain Management Server.

4. Run: cma_migrate <src tgz> <FWDIR on target>
5. The cma_migrate command imports the Domain Management Server database (using the TGZ created by the migrate export command) to the Multi-Domain Server.
6. Start the Domain Management Server.
7. Run: mdsenv; mdsstart
8. Use migrate_global_policies to import the global policies.

Gradual Upgrade with Global VPN Communities

The gradual upgrade process for a Multi-Domain Server using Global VPN Communities is not fundamentally different from the gradual upgrade process described above, with the following exceptions:

1. Global VPN community setup involves the Global database and the Domain Management Servers that are managing Gateways participating in the global communities. When gradually upgrading a GVC environment, split the upgrade into two parts:
   • one for all Domain Management Servers that do not participate in the Global VPN Community
   • one for Domain Management Servers that do participate with the Global VPN Community
2. If some of your Domain Management Servers have already been migrated and some have not and you would like to use the Global Policy, make sure that it does not contain Gateways of non-existing Domains. To test for non-existing Domains, assign this Global Policy to a Domain. If the assignment operation fails and the error message lists problematic Gateways, you have at least one non-existing Domain. If this occurs:
   1. Run the where used query from the Global SmartDashboard > Manage > Network Objects > Actions to identify where the problematic Gateways are used in the Global Policy. Review the result set, and edit or delete list items as necessary. Make sure that no problematic Gateways are in use.
   2. The Gateways must be disabled from global use:
      1. From the General View, right-click a gateway and select Disable Global Use.
      2. If the globally used gateway refers to a gateway of a Domain that was not migrated, you can remove the gateway from the global database by issuing a command line command. First, make sure that the Global SmartDashboard is not running, and then execute the command:
         mdsenv; remove_globally_used_gw <Global name of the gateway>
3. When issuing the command: migrate_global_policies where the existing Global Policy contains Global Communities, the resulting Global Policy contains:
   • Global Gateways from the existing database
   • Global Gateways from the migrated database

   As a result of the migration, the Global Communities are overridden by the migrated database.

4. The gradual upgrade does not restore the Global Communities statuses, therefore, if either the existing or the migrated Global Policy contains Global Communities, reset the statuses from the command line with the Multi-Domain Server started.

   mdsenv; fwm mds rebuild_global_communities_status all

Migrating from Security Management Server to Domain Management Server

This section describes how to migrate the Security Management Server product of a standalone deployment to a Domain Management Server. Then you manage the former-standalone computer as a Security Gateway only from the Domain Management Server.

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

Before migrating:

1. Make sure that the target Domain Management Server IP address can communicate with all Gateways.
2. Add an object representing the Domain Management Server (name and IP address) and define it as a Secondary Security Management Server.
3. Install policy on all managed Gateways.
4. Delete all objects or access rules created in steps 1 and 2.
5. 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.
6. Save and close SmartDashboard. Do not install policy.

To migrate the management database to the Domain Management Server:

1. Go to the fully qualified path of the migrate export command.
2. Run: migrate export [-l] <output file>
3. Create a new Domain Management Server on the Multi-Domain Server, but do not start it.
4. Migrate the exported database into the Domain Management Server. Use the cma_migrate command or the import operation from the SmartDomain Manager, specifying as an argument the database location you specified in step 2.

   Note - To run the cma_migrate utility from the SmartDomain Manager, right-click a Domain Management Server and select Options > Import Domain Management Server. In the Import window, when you enter the path to the exported database file, include the name of the exported database file at the end of the path. You can also run mdscmd migratecma to import files to a Domain Management Server.

5. Restart the Domain Management Server and launch SmartDashboard.
6. In SmartDashboard, under Network Objects, 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 gateway managed previously by Security Management Server.
7. Edit the Primary Management Object and remove all interfaces (Network Object > Topology > Remove).
8. Create an object for the Security Gateway on the standalone machine (from New > Check Point > Gateway), and:
   • Assign a Name and IP address for the gateway.
   • Select the appropriate Check Point version.
   • Enabled the installed Software Blades.
   • If the Security Gateway belonged to a VPN Community, add it back.
   • Do not initialize communication.
9. Run Domain Management Server on the primary management object and, in each location, consider changing to the new gateway object.
10. Install the policy on all other Gateways, not the new one. If you see warning messages about this gateway because it is not yet configured, ignore them.
11. Uninstall the standalone deployment.
12. Install a Security Gateway on the previous standalone machine.
13. From the Domain Management Server SmartDashboard, edit the gateway object, define its topology, and establish trust between the Domain Management Server and the Security Gateway.
14. Install the policy on the Security Gateway.

Upgrading a High Availability Deployment

Multi-Domain Security Management High Availability gives you management redundancy for all Domains. Multi-Domain Security Management High Availability operates at these levels:

• Multi-Domain Server High Availability - By default, Multi-Domain Servers are automatically synchronized with each other. One Multi-Domain Server is always defined as the Active Multi-Domain Server and all other Multi-Domain Servers are Standby Multi-Domain Servers. You can connect to an Active or Standby Multi-Domain Server to work on Domain management tasks.

  You can only do Global policy and global object management tasks using the active Multi-Domain Server. In the event that the active Multi-Domain Server is unavailable, you must change one of the standby Multi-Domain Servers to active.

• Domain Management Server High Availability - Multiple Domain Management Servers give Active/Standby redundancy for Domain management. One Domain Management Server for each Domain is Active. The other, fully synchronized Domain Management Servers for that Domain, are standbys. In the event that the Active Domain Management Server becomes unavailable, you must change one of the standby Domain Management Servers to active.

You can also use ClusterXL to give High Availability redundancy to your Domain Security Gateways. You use SmartDashboard to configure and manage Security Gateway High Availability for Domain Management Servers.

Pre-Upgrade Verification and Tools

Run the pre-upgrade verification on all Multi-Domain Servers before upgrading any Multi-Domain Servers. Select the Pre-Upgrade Verification Only option from UnixInstallScript. Upgrade the primary Multi-Domain Server only after you have fixed all errors and reviewed all warnings for all Multi-Domain Servers.

Multi-Domain Server High Availability

Multi-Domain Servers can only communicate and synchronize with other Multi-Domain Servers running the same version. If your deployment has more than one Multi-Domain Server, make sure they are upgraded to the same version.

To upgrade multiple Multi-Domain Servers:

1. Upgrade the primary Multi-Domain Server.
2. Upgrade the other Multi-Domain Servers.

During the upgrade process, we recommend that you do not use any of the Multi-Domain Servers to make changes to the databases. This can cause inconsistent synchronization between Multi-Domain Servers.

Note - You must upgrade your Multi-Domain Log Servers to the same version as the Multi-Domain Servers.

Upgrading Multi-Domain Servers and Domain Management Servers

To upgrade a Multi-Domain Server and a Domain Management Server:

1. Run pre-upgrade verification for all Multi-Domain Servers.
2. If a change to the global database is necessary, synchronize the Multi-Domain Servers immediately after making these changes. Update the database on one Multi-Domain Server and start synchronization. The other Multi-Domain Servers will get the database changes automatically.
3. If global database changes affect a global policy assigned to a Domain, assign the global policy again to all affected Domains.
4. If the verification command finds Domain Management Server level errors (for example, Gateways that are no longer supported by the new version):
   1. Make the required changes on the Active Domain Management Server.
   2. Synchronize the Active Domain Management Server with all Standby Domain Management Servers.
5. If a Domain has Log Servers:
   1. In the Domain SmartConsole, manually install the new database: select Policy > Install Database.
   2. Select all Log Servers.
   3. Make sure that the change to the Domain Log Server is successful.

Note - When synchronizing, make sure that you have only one active Multi-Domain Server and one active Domain Management Server for each Domain.

Change the active Multi-Domain Server and Domain Management Server, and then synchronize the Standby computers.

Updating Objects in the Domain Management Server Databases

After upgrading the Multi-Domain Servers and Domain Management Servers, you must update the objects in all Domain Management Server databases. This is necessary because upgrade does not automatically update the object versions attribute in the databases. If you do not manually update the objects, the standby Domain Management Servers and Log Servers will show the outdated versions.

Update the objects with these steps on each Multi-Domain Server.

To update Domain Management Server and Domain Log Server objects:

1. Make sure that all Domain Management Servers are up: mdsstat

   If a Domain Management Server is down, resolve the issue, and start the Domain Management Server: mds_startcustomer

2. Go to the top-level CLI: mdsenv
3. Run: $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL

   Optional: Update one Domain Management Server or Domain Log Server at a time with this command:
   $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <server_name>

4. Synchronize all standby Domain Management Servers.
5. Install the database in SmartDashboard for the applicable Domain Management Server.

Managing Domain Management Servers During the Upgrade Process

The best practice is to avoid making any changes to Domain Management Server databases during the upgrade process. If your business model cannot support management down-time during the upgrade, you can continue to manage Domain Management Servers during the upgrade process.

This creates a risk of inconsistent Domain Management Server database content between instances on different Multi-Domain Servers. The synchronization process cannot resolve these inconsistencies.

After successfully upgrading one Multi-Domain Server, you can set its Domain Management Servers to Active while you upgrade the others. Synchronization between the Domain Management Servers occurs after all Multi-Domain Servers are upgraded.

If, during the upgrade process, you make changes to the Domain Management Server database using different Multi-Domain Servers, the contents of the two (or more) databases will be different. Because you cannot synchronize these databases, some of these changes will be lost. The Domain Management Server High Availability status appears as Collision.

You must decide which database version to retain and synchronize it to the other Domain Management Servers. You then must re-enter the lost changes to the synchronized database.

Restarting Domain Management Servers

After completing the upgrade process, start Domain Management Servers: mdsstart

Restoring Your Original Environment

Before the upgrade:

Pre-upgrade utilities are an integral part of the upgrade process. In some cases, you are required to change your database before the actual upgrade can take place or the Pre-Upgrade Verifier suggests you execute utilities that perform the required changes automatically. Even if you decide to restore your original environment, keep the changes you made as a result of the pre-upgrade verification.

Prepare a backup of your current configuration using the mds_backup utility from the currently installed version. Prepare a backup as the first step of the upgrade process and prepare a second backup right after the Pre-Upgrade Verifier successfully completes with no further suggestions.

To restore your original environment:

1. Remove the new installation:
   1. For a SecurePlatform server, manually remove the new software packages. It can be easier to remove all installed Check Point packages and install the original version.
   2. For all other servers, log in to expert mode and run the mds_remove utility.
2. Go to the folder that contains the backup file.
3. Run: ./mds_restore

   The original environment is restored.

4. Exit expert mode.

Removing Earlier Version Multi-Domain Server Installations

After upgrading your Multi-Domain Server to the latest version, earlier version files are not automatically deleted from the disk. This lets you revert to the old version in the event there are problems with the upgrade. These files can take up a lot of disk space and cause performance degradation.

After you complete testing your upgrade, we recommend that remove these earlier version files. You can use the mds_remove_version tool to automatically remove old installations with no effect on the installed version.

To remove old installations:

1. Backup your system.
2. Download the tool.
3. Copy the mds_remove_version.sh script to the Multi-Domain Server
4. Run mds_remove_version.sh.
   There are no parameters or arguments.
5. Confirm when prompted.
6. Make sure that the old files were successfully removed.

   Important - This tool removes major releases and all minor releases installed over a major release. For example, if R71.50 is installed on your Multi-Domain Server, and you upgraded to R77, the tool removes R71 and R71.50 files.

Changing the Multi-Domain Server Interfaces

If your target machine and the source machine have different IP addresses, follow the steps listed below it to change the restored Multi-Domain Server to the new IP address.

To change the IP address:

1. Stop the Multi-Domain Server by running mdsstop.
2. Change the IP address in $MDSDIR/conf/LeadingIP file to the new IP address.
3. Edit the $MDSDIR/conf/mdsdb/mdss.C file. Find the Multi-Domain Server object that has the source Multi-Domain Server IP address and change its IP address to the new IP address. Do not change the Multi-Domain Server name.
4. Install a new license on the target Multi-Domain Server with the new Multi-Domain Server IP address.
5. For multiple Multi-Domain Server environments, repeat steps 1 to 4 for each Multi-Domain Server that has a changed IP address.

If your target machine and the source machine have different interface names (e.g., hme0 and hme1), follow the steps listed below to adjust the restored Multi-Domain Server to the new interface name.

To change the interface:

1. Change the interface name in file $MDSDIR/conf/external.if to the new interface name.
2. For each Domain Management Server, replace the interface name in $FWDIR/conf/vip_index.conf.

IPS with Multi-Domain Security Management

• When upgrading to R77, the previous Domain IPS configuration is overridden when you first assign a Global Policy.

  We recommend that you save each Domain policy, so that you can restore the settings after the upgrade. To do so, go to the Domain Configuration window > Assign Global Policy tab, and enable Create database version.

• If you manage IPS globally, you must reassign the global policy before installing the policy on Security Gateways.
• Customers upgrading to the current version should note that the IPS subscription has changed.
• All Domains subscribed to IPS are automatically assigned to an "Exclusive" subscription
• "Override" and "Merge" subscriptions are no longer supported.

  See the Global Policy Chapter in the R77 Multi-Domain Security Management Administration Guide for detailed information.

Enabling IPv6 on Gaia

IPv6 is automatically enabled if you configure IPv6 addresses in the First Time Configuration Wizard.

If you did not do this, enable IPv6 in one of the following ways:

To enable IPv6 using Clish:

# set ipv6-state on

# save config

# reboot

To enable IPv6 using the Portal:

1. In the Portal navigation tree, select System Management > system Configuration.
2. For IPv6 Support, select On.
3. When prompted, select Yes to reboot.

Enabling IPv6 on Multi-Domain Security Management

If your environment uses IPv6 addresses, you first must enable IPv6 support for the Multi-Domain Server and for any existing Domain Management Servers. It is not necessary to enable IPv6 support for Domain Management Servers that are created after IPv6 is enabled on the Multi-Domain Server, because this occurs automatically.

Before enabling IPv6 support for the Multi-Domain Server:

1. Enable IPv6 in Gaia and assign an IPv6 address to the management interface.
2. Write down the Multi-Domain Server IPv6 address and the names and IPv6 address for all Domain Management Servers. This is necessary because the procedures disconnect the SmartDomain Manager.

To enable IPv6 support for the Multi-Domain Server:

1. From the Multi-Domain Server command line, run > mdsconfig.
2. Select IPv6 Support for Domain Management Server.
3. Press y when asked to change the IPv6 preferences for the Multi-Domain Server.

   Press y again to confirm.

4. Enter the management interface name (typically eth0).
5. Enter the Multi-Domain Server IPv6 address.
6. Press y to start Check Point services.

   After a few moments, the mdsconfig menu shows.

To enable IPv6 support for all existing Domain Management Servers:

1. From the mdsconfig menu, select IPv6 Support for Existing Domain Management Servers.
2. Press y when asked to change the IPv6 preferences for Domain Management Servers.
3. Press a to add support to an existing Domain Management Server.
4. Press y to add Support to all Domain Management Servers at once.
5. Press m to manually add IPv6 addresses

   Or

   Press r to automatically assign IPv6 address from a specified range.

6. Do the instructions on the screen to enter the IPv6 address or a range of IPv6 addresses when prompted.

To manually enable IPv6 support for specified Domain Management Servers.

1. From the mdsconfig menu, select IPv6 Support for Existing Domain Management Servers.
2. At the prompt, press y to change the IPv6 preferences for Domain Management Servers.
3. Press a to add support to an existing Domain Management Server.
4. Press n when asked to enable IPv6 support for all Domain Management Servers at once.

   Press y to confirm.

5. At the prompt, enter the Domain Management Server name.

   The available Domain Management Servers show above prompt. You can copy and paste the name.

6. Enter the IPv6 address.