Upgrading Multi-Domain Security Management

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

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

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

3. 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

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

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

The migrate export command exports the content of a single 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.

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 R76 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 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-R76/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

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.

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 Information

The original Certificate Authority and putkey information is maintained when using cma_migrate. This means that the Security Management server that was migrated using cma_migrate should not re-generate certificates to gateways and SIC should continue to work with gateways. However, if the IP of the Domain Management Server is different than that of the original management, then putkey should be repeated between the Domain Management Server and entities that connect to it using putkey information. Use putkey -n to re-establish trust. For additional information on putkey, refer to the Check Point Command Line Interface documentation.

If your intent is to split a Domain Management Server into two or more Domain Management Servers, reinitialize their Internal Certificate Authority so that only one of the new Domain Management Servers employs the original ICA:

To reinitialize a Domain Management Server Internal Certificate Authority:

1. Run: mdsstop_customer <Domain Management Server NAME>
2. Run: mdsenv <Domain Management Server NAME>
3. Remove the current Internal Certificate Authority by executing the fwm sic_reset command. This may require some preparation that is described in detail from the command prompt and also in the Secure Knowledge solution sk17197.
4. Create a new Internal Certificate Authority by executing:
   mdsconfig -ca <Domain Management Server NAME> <Domain Management Server IP>
5. Run the command: mdsstart_customer <Domain Management Server NAME>

For more about CA on Multi-Domain Security Management, see sk17197.

Resolving Issues with IKE Certificates

When migrating a management database that contains a gateway object that takes part in a VPN tunnel with an externally managed third-party gateway, an issue with the IKE certificates arises. After migration, when such a gateway presents its IKE certificate to its peer, the peer gateway uses the FQDN of the certificate to retrieve the host name and IP address of the Certificate Authority that issued the certificate. If the IKE certificate was issued by a Check Point Internal CA, the FQDN will contain the host name of the original management. In this case, the peer gateway will try to contact the original management for the CRL information, and failing to do so will not accept the certificate.

There are two ways to resolve this issue:

• Update the DNS server on the peer side to resolve the host name of the original management to the IP address of the relevant Domain Management Server.
• Revoke the IKE certificate for the gateway(s) and create a new one. The new certificate will contain the FQDN of the Domain Management Server.

migrate_global_policies

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

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.

Syntax:

migrate_global_policies <path to exported Multi-Domain Server tgz archive> 

<path to exported Multi-Domain Server tgz archive>: 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.

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 binaries and data from your Multi-Domain Server to the working directory. 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 mds_exclude.dat ($MDSDIR/conf) file. The collected information is stored in a single .tgz file. This .tgz file name consists of the backup date and time, which is saved in the current working directory. For example: 13Sep2002-141437.mdsbk.tgz

To perform a backup:

1. Execute mds_backup from any location outside the product directory tree to be backed up. This becomes the working directory.
2. Upon completion of the backup process, copy the backup .tgz file, together with the mds_restore, gtar and gzip command files, to your external backup location.

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

Comments When using the -g or -b options, make sure that no GUI clients or SmartReporter servers are connected. Otherwise, the backup file may contain inconsistencies due to database changes made during the backup process.

It is important not to run mds_backup from any of the directories that will be backed up. For example, when backing up a Multi-Domain Server, do not run mds_backup from /opt/CPmds-R70 since it is a circular reference (backing up directory that you need to write into).

Active log files are not backed up, in order to avoid read-during-write inconsistencies. It is recommended to perform a log switch prior to the backup procedure.

Further Info. The Multi-Domain Server configuration can be backed up without backing up the log files. Such a backup will usually be significantly smaller in size than a full backup with logs. To back up without log files, add the following line to the file $MDSDIR/conf/mds_exclude.dat:

log/*

mds_restore

Description Restores a Multi-Domain Server that was previously backed up with mds_backup. For correct operation, mds_restore should be restored onto a clean Multi-Domain Server installation.

Syntax ./mds_restore <backup file>

Upgrade Best Practices

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.

Before doing an in-place upgrade to R76:

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.

Gaia to Gaia

Upgrade Requirements:

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

• Using the WebUI: 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.

Use the CLI to do the upgrade.

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_R76.Gaia.iso
2. Burn the ISO file on a DVD.
3. Connect an external DVD drive to a USB socket on the appliance or computer.
4. 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.

SecurePlatform to Gaia

Use this procedure to upgrade a Multi-Domain Server from SecurePlatform to R76 Gaia

Use the CLI to do the upgrade.

To upgrade a Multi-Domain Server from SecurePlatform to R76 Gaia:

1. Create an upgrade DVD:
   1. Download the R76 Multi-Domain Server ISO file for the operating system to which you want to upgrade.
   2. Burn the ISO file on a DVD.
2. Connect an external DVD drive to the USB socket on the server.

   Make sure that the DVD with the R76 ISO file is in the DVD drive.

3. Log in to SecurePlatform.
4. Run the following command(s) in expert mode:
   1. On Smart-1 appliances: mount /dev/cdrom
   2. patch add cd

   The upgrade package is installed.

5. Select the R76 Upgrade Package and press Enter.
6. Type yes to verify the MD5 checksum.
7. When prompted, create a backup image for automatic revert.

   The Multi-Domain Server is upgraded to R76.

8. Remove the DVD from the drive
9. Restart the server.
10. Run this command (in expert mode) to update the version of all Domain Management Server and Domain Log Server objects located on this server:

   /opt/CPmds-R76/scripts/mds_fix_cmas_clms_version -c ALL –n <Multi-Domain Server name>

SecurePlatform to SecurePlatform

Use a DVD to upgrade Multi-Domain Server on SecurePlatform.

Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it automatically reverts to the Safe Upgrade image.

When the Upgrade process is complete, upon reboot you are given the option to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.

To upgrade Multi-Domain Server on SecurePlatform:

1. If necessary, create the upgrade DVD and do these steps:
   1. Download the R76 Multi-Domain Server ISO file.
   2. Burn the ISO file on a DVD.
   3. Connect an external DVD drive to the USB socket on the server.

      Make sure that the DVD with the R76 ISO file is in the DVD drive.

2. Log in to SecurePlatform (expert mode is necessary only for Smart-1 appliances).
3. Run: patch add cd

   The SecurePlatform upgrade package is installed.

4. Select the SecurePlatform R76 Upgrade Package and press Enter.
5. Type yes to verify the MD5 checksum.
6. If necessary, type yes to do a Safe Upgrade.

   Multi-Domain Server is upgraded to R76.

7. Remove the DVD from the drive.
8. Restart the server.
9. Run this command to update the version of all Domain Management and Log Server objects located on this server: /opt/CPmds-R76/scripts/mds_fix_cmas_clms_version -c ALL -n <Multi-Domain Server name>

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 the UnixInstallScript command, 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.

Use the mds_import 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.

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 directory which has the name of the operating system of your Multi-Domain Server.
4. Run: UnixInstallScript
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.

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 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.

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.

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 uninterrupted management redundancy for all Domains. Multi-Domain Security Management High Availability operates at these levels:

• Multi-Domain Server High Availability - Multiple Multi-Domain Servers are, by default, automatically synchronized with each other. You can connect to any Multi-Domain Server to do Domain management tasks. One Multi-Domain Server is designated as the Active Multi-Domain Server. Other Multi-Domain Servers are designated as Standby Multi-Domain Servers.

  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.

Upgrading Multi-Domain Servers and Domain Management Servers

To upgrade Multi-Domain Server and 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 SmartDashboard, 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.

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.

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, run the mds_remove utility.
2. Run the mds_restore command with the backup file.
3. The original environment is restored.

   Important - In Gaia, run the mds_restore 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

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 R76, 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 R76, 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 R76 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:

1. Run:
   set ipv6-state on
2. Run:
save config
3. Run:
   reboot

To enable IPv6 using the WebUI:

1. In the WebUI navigation tree, select Advanced > System Configuration.
2. For IPv6 Support, select On.

Enabling IPv6 for the Multi-Domain Server and Domain Management Servers

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 is done automatically.

Before enabling IPv6 support for the Multi-Domain Server:

1. Enable IPv6 on 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.