Support Center > Search Results > SecureKnowledge Details
How to upgrade CloudGuard Management version in AWS, Azure, or GCP Technical Level
Solution

Table of Contents:

  • Introduction
  • Prerequisites
  • Procedure

Introduction

This guide explains how to upgrade SmartCenter Management (MGMT) server deployed in AWS, Azure, or GCP.

Note: To upgrade a Management Server deployed in AWS from R77.30 to R80.10 or higher, see sk118717.

Prerequisites

  • Source Machine: MGMT server version R80.10 and higher
  • Target Machine: MGMT server version R80.20 and higher
  • If you use a BYOL license not related to your elastic/public IP address, it is necessary to request a new license before proceeding with the instructions below.

Procedure

Click Here to Show the Entire Procedure

Note: Make sure that the target VM has connectivity to the Security Gateways it will manage.

Copy the Migration Tools to the source Management Server

Show / Hide this section

A. In the source machine, create a dedicated folder to extract the MGMT DB (do not extract or copy migration files to the folder /home/admin).

B. Go to the home page SecureKnowledge articles of the target version and download the migration tools to the source dedicated folder (created in step #1).

Note: You cannot copy the migration tools from the target machine.

Below is the location of the migration tools for R80.20 in sk122485.



Instructions for Migrate server ( R81 specifically )
  • Check Point introduced a new upgrade mechanism for the Security Management Server for upgrades between R8X versions (from R80.20 and higher)
  • A new command "migrate_server" is used, not the usual "migrate" command.
  • Even though the migrate server was available above R80.20, R81 specifically supports only migrate server commands and the Upgrade Tools package, rather than the Migration tool.
  • The tool package should strictly be installed through CPUSE and NOT extracted as an RPM. Refer to sk135172.

Export the DB on the source Management Server
Show / Hide this section

A. Log in to the Expert mode on the source machine.

B. Extract the migration tools:

tar -zxvf Check_point_XXX.tgz

C. Export the MGMT DB without the license files by running this command in the dedicated folder:

./migrate export --exclude-licenses <FULL_PATH_OF_DESTINATION>.tgz

Notes:

  • Excluding license flags is available only from R80.20 Jumbo Hotfix Take 73.
  • If you see PUV errors, look for these errors in Check Point Support Center.

#Migrate server instructions (R81) 

$MDS_FWDIR/scripts/migrate_server export -skip_upgrade_tools_check -v <version> --exclude-licenses <output tgz file>

Import the DB on the target Management Server

Show / Hide this section

A. Log in to the Expert mode on the target machine.

B. Create a temporary folder to extract the DB

For example:

mkdir /var/log/DB

Important - Do not extract or copy DB files to the folder /home/admin/

C. Copy the exported DB file to the Target machine to the temporary folder.

D. Go to this folder:

cd $FWDIR/bin/upgrade_tools

E. Import the DB:

./migrate import <FULL_PATH_to_TEMPORARY_FOLDER>.tgz



#Migrate server instructions (R81)


$MDS_FWDIR/scripts/migrate_server import -skip_upgrade_tools_check -v <version><export tgz file>




  1. Associate the source elastic/public IP address to the target server IP address

    Show / Hide this section

    Instructions for AWS

    Show / Hide this section

    A. Go to the AWS Management Console site of your account:

    B. Go to EC2:

    C. Stop the source machine in the navigation pane.

    1. Select Instances and select the instance.

    2. Select Actions, select Instance State, and then select Stop.

      If Stop is disabled, the instance is already stopped.

    3. In the confirmation dialog box, select Yes, Stop.

      It can take a few minutes for the instance to stop.

    D. Disassociate the elastic IP from the source.

    Note that Disassociation will access the MGMT from this point.

    a. In the navigation pane, select Elastic IPs.

    b. Select the Elastic IP address, Sselect Actions, and then select Disassociate address.

    E. Associate the EIP with the target:

    a. Select the address that you disassociated in the previous step.

    For Actions, select Associate address.

    b. Select the new instance from Instance, and then select Associate.

    F. Connect to the target machine through SSH.

    G. Log in to Gaia Clish on the target machine.

    H. Remove the old alias interface:

    delete interface eth0 alias eth0:1

    I. Add a new interface with the source EIP (mask must be /32):

    add interface eth0 alias source-public-ip/32

    J. Save your changes:

    save config

    Instructions for Azure

    Show / Hide this section

    A. Go to the Azure Portal.

    B. Navigate to the Virtual machines blade.

    C. Stop the source Management Server VM in the navigation pane.

    D. Disassociate the public IP from the source NIC.

    Note - disassociation will prevent access to the source Management Server through the public IP address.

    a. From the source VM resource, select the public IP address.

    b. From the navigation pane, select Overview.

    c. Select Disassociate.

    In the confirmation dialog box, Sselect Yes.

    Save the name of the public IP resource for the next steps.

    E. Associate the public IP address with target Management Server VM.

    a. Go to the target Management Server VM resource group.

    b. Select the network interface eth0.


    c. In the navigation pane select IP Configuration.

    d. Select the existing configuration (ipconfig1).

    e. Edit the configuration to use the public IP resource from step D and click Save.

    F. Connect to the target Management Server VM through SSH.

    G. Log in to Gaia Clish.

    H. Remove the old alias interface:

    delete interface eth0 alias eth0:1

    I. Add a new interface alias with the source public IP address (mask must be /32):

    add interface eth0 alias source-public-ip /32

    J. Save your changes:

    save config

    Instructions for GCP

    Show / Hide this section

    A. Go to the GCP Console.

    B. Navigate to the VM Instance page.

    C. Stop the source Management Server VM in the navigation pane by choosing the VM and clicking Stop in the navigation pane.

    D. Disassociate the External IP address from the source Management Server and associate it to the target Management Server.

    Note - Disassociation will prevent access to the source Management Server via the public IP address.

    a. Navigate to the External IP Addresses page.

    b. Locate the source Management Server address and select Change.

    c. In the Attach IP address pop-up menu, select the target Management Server in the drop- down list and clear the box for assigning a new ephemeral IP address to the VM.

    d. Release the Target Management Server address by checking its box and clicking Release Static Address.

    E. Connect to the Target Management Server VM through SSH.

    F. Log in to Gaia Clish.

    G. Remove the old alias interface:

    delete interface eth0 alias eth0:1

    H. Add a new interface alias with the source public IP address (mask must be /32):

    add interface eth0 alias source-public-ip /32

    I. Save your changes:

    save config



  2. Copy the CME from the source server to the target server

    Show / Hide this section
    1. Follow the instruction from sk157492 to install the latest version of CME on the target Management Server.

    2. Make sure that the service is registered on the target machine:

      service autoprovision status

      Make sure the service exists and, perhaps, is UP/DOWN.

      Note: When upgrading from R80.10 to a higher version, if the Management Server manages a scale set / auto scaling group, scale-in to 0 instances and scale-out. When upgrading a GCP Management Server that manages a GCP AutoScaling solution with outbound inspection use-case, make sure to adjust the routes according to the new instances.



  3. Attach the correct license on the target machine

    Show / Hide this section
    • PAYG: No need to attach the license.
    • BYOL: If the license is attached to a private IP, you will need to request a new license for the new private IP in the new MGMT. Otherwise, use the license from the source machine.


This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment