> Source: [sk111158](https://support.checkpoint.com/results/sk/sk111158) # sk111158 - Central Deployment Tool (CDT) | Property | Value | |----------|-------| | Solution ID | sk111158 | | Date Created | 2016-04-25 | | Last Modified | 2026-09-25 | | Technical Level | General | | Products | Security Management Server, Multi-Domain Security Management Server | | Versions | R82.10, R82, R81.20, R82.10, R81.10 (EOS), R81 (EOS), R81 (EOS), R81.10 (EOS), R81.20, R82 | | OS | Gaia | ## Solution |-------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------| | * **Introduction** * **Downloads and Documentation** * **List of improvements per CDT version** * **Known Limitations** | * **FAQ** * **Troubleshooting** * **Revision History** |
Click Here to Show the Entire Article ### Important: Effective July 31, 2025, Central Deployment Tool has been updated to v2.2. Introduction {#Introduction} ---------------------------- **Central Deployment Tool (CDT)** is a utility that runs on Security Management Servers and Multi-Domain Security Management Servers running Gaia OS. This utility lets you manage a deployment of software packages from your Management Server to multiple managed Security Gateways and Cluster Members at the same time: * Installation of software packages * Perform various actions - take snapshots, run shell scripts, push/pull files, etc. * Automate the RMA backup and restore process CDT handles cluster upgrades automatically, including Multi-Version Cluster (MVC) and Full Connectivity Upgrade (CU). Downloads and Documentation {#Downloads} ---------------------------------------- *[Software Subscription or Active Support plan](https://www.checkpoint.com/support-services/support-plans/) is required to download this package.* ![](https://sc1.checkpoint.com/sc/images/sk_images/Warning.png) **Warning:** CDT support for R82.20 Management Servers and R82.20 Security Gateways is planned. Currently, no CDT version supports the R82.20 release. |----------------------------------------|------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Package Version | Take | CDT package | CPUSE Offline package | | Central Deployment Tool (CDT) **v2.2** | 53 | [![](https://sc1.checkpoint.com/sc/images/download-m.png "Central Deployment Tool for Security Management Server / Multi-Domain Security Management Server")](https://support.checkpoint.com/results/download/139055) (TGZ) | [![](https://sc1.checkpoint.com/sc/images/download-m.png "Central Deployment Tool for Security Management Server / Multi-Domain Security Management Server")](https://support.checkpoint.com/results/download/139056) (TAR) | **Notes:** * For CPUSE Online Identifier, use: `Check_Point_CDT_Bundle_T<`*Take Number*`>_FULL.tgz` * This CDT package does *not* contain the RPM package of the CPUSE Deployment Agent. * CDT files can be copied to other locations (as long as they are all copied to a single location). * **To check what CDT build you are using, run in the Expert mode: `$CDTDIR/CentralDeploymentTool -v`** **Installation Instructions:** Show / Hide this section **CDT package** 1. Download the above CDT archive to your computer. 2. Transfer the CDT archive from your computer to your Management Server (into some directory, e.g., */some_path_to_CDT/*). 3. Connect to the command line on the Management Server. 4. Log in to the Expert mode. 5. Unpack the CDT archive: `[Expert@HostName:0]# cd /some_path_to_CDT/` ` [Expert@HostName:0]# tar -zxvf .tgz` 6. Install the CDT package: `[Expert@HostName:0]# rpm -Uhv --force CPcdt-00-00.i386.rpm` CDT files are located in the `/opt/CPcdt/` directory (`$CDTDIR`). **Warning** - You must **not** change the name of these files: `CentralDeploymentTool`, `RmaTool`, `CentralDeploymentTool.xml` **CPUSE Offline package** For detailed CPUSE installation instructions, refer to [sk92449 - Check Point Upgrade Service Engine (CPUSE) - Gaia Deployment Agent](https://support.checkpoint.com/results/sk/sk92449).
**Documentation:** * [Central Deployment Tool (CDT) Administration Guide](https://sc1.checkpoint.com/documents/CDT/Unified/Default.htm) [](https://sc1.checkpoint.com/documents/CDT/v1.9.1/Default.htm) * For cloud clusters, refer to [sk181606 - CloudGuard Network Security Clusters solutions upgrade using Central Deployment Tool](https://support.checkpoint.com/results/sk/sk181606) List of improvements per CDT version {#List} -------------------------------------------- Show / Hide this section Enter the string to filter this table: |-------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | CDT Version | Release Date | Description | | **v2.2** | 31 Jul 2025 | * Added support for Maestro Security Groups (Maestro Orchestrator is not supported) * Allow configurable timeout while waiting for the CPUSE Deployment Agent to be ready * Added new parameters for Debug Configuration: * `DaCliCommandRetry` * `DaCliCommandTimeout` | | **v2.1** | 22 Apr 2025 | * Added support for the R82.10 Security Gateways * Improved error handling and reporting * General code improvements and fixes | | **v2.0** | 03 Jun 2024 | * Allow CDT management commands when a non-default port is used * Fix the problem with CDT Basic Mode introduced in CDT v1.9.8 | | **v1.9.8** | 31 Oct 2023 | * Support for a cluster installed in a Public Cloud or a Private Cloud. * New CLI parameter to run several different CDT sessions at the same time: * Syntax in the Expert mode: `$CDTDIR/CentralDeploymentTool --session=` * Syntax in Gaia Clish: `set cdt candidates session ` and `start cdt session ` | | **v1.9.7** | 13 Jun 2023 | * Improved cluster failover during upgrade. * CDT now installs Threat Prevention policy at the end of installation. | | **v1.9.6** | 16 Apr 2023 | * Performance improvement of candidate list generation on large databases. * Performance improvement of VRRP cluster handling. * General Code improvements and fixes. | | **v1.9.5** | 24 May 2022 | * Performance improvement - CDT does not split packages while transferring to the Security Gateways (saves the time of split \& join). * Added the option to use a filter file in RMA backup * Transfer policy files to the Security Gateway before the upgrade. * General Code improvements and fixes. | | **v1.9.4** | 17 Jan 2022 | * General code improvements and fixes. | | **v1.9.3** | 4 Jul 2021 | * Added the ability to install CDT with CPUSE. * General code improvements and fixes. | | **v1.9.2** | 23 Mar 2021 | * Added an option to open SmartConsole during CDT execution. * General code improvements and fixes. | | **v1.9.1** | 03 Mar 2021 | * Added support for Blink packages in RMA restore. * General code improvements and fixes. | | **v1.9.0** | 29 Sep 2020 | * Added CDT Clish Integration. * General code improvements and fixes. | | **v1.8** | 07 Apr 2020 | * Added support for clusters with more than 2 cluster members. * General code improvements and fixes. | | **v1.7.1** | 16 Dec 2019 | * Allow to change the sender email address. * Allow to add an attribute to the User Script action to run it more than one time. * General code improvements and fixes. | | **v1.7** | 29 July 2019 | * Added support for upgrade with Gaia Fast Deployment images. * Added support for upgrading Security Gateways to a higher version than the Management Server, if the required Jumbo Hotfix Accumulator is installed in the Management Server. * CDT pulls the CPUSE RPM from the Management Server. The default CPUSE RPM path was changed to be: */sysimg/CPwrapper/linux/CPda/CPda-00-00.i386.rpm* The user does not need to add it manually and add a path to the *CentralDeploymentTool.xml* file. * General code improvements. | | **v1.6.1** | 24 Apr 2019 | * Added support for "vSEC for VMWware NSX" and "CloudGuard for VMWare NSX". * General code improvements. | | **v1.6** | 10 Jan 2019 | * CDT forces CPUSE to work offline. * Added support for VSX Gateways. * Added support for VSX Cluster in the VSLS mode. * Added the option to add custom backup files. * General code improvements. | | **v1.5.2** | 3 June 2018 | * Added support for Connectivity Upgrade of VRRP clusters (R80.10 and higher). * Added validations for cluster health during cluster upgrade. * Resolved issue: Running CDT on multiple Domain Management Servers in parallel could cause the instances to interfere with each other. * Resolved issue: CDT now uses the Security Gateway IP address as defined in the Management database, instead of the configuration on the Security Gateway. | | **v1.5.1** | 20 Feb 2018 | * General code improvements. | {#Unique_ID_ImprovementsTable}
Known Limitations {#Known Limitations} -------------------------------------- Show / Hide this Section Enter the string to filter this table: |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | General | | Running CDT is not supported on: * Standalone server * Security Management Server in the Backup state (in Management High Availability deployment) * Dedicated SmartEvent Server * Dedicated Log Server * Multi-Domain Log Server * Members of a Full High Availability cluster | | CDT does not support ClusterXL in the Load Sharing Multicast and Load Sharing Unicast modes. | | CDT does not support Scalable Chassis 40000 and 60000. | | CDT does not support Spark Firewalls. | | CDT does not support ROBO Gateways managed by SmartProvisioning. | | CDT does not support Security Gateways that run only IPv6 (without IPv4 address configured on the applicable management interface). | | CDT does not support Security Gateways / Clusters that are enabled for the Global use on a Multi-Domain Security Management Server. | | CDT does not support Maestro Orchestrators. | | CDT does not support Maestro Security Groups in Dual Site Active-Active configuration. | | CDT does not support Scalable Platform Security Groups in the VSNext mode. | | CDT does not support the RMA mode on Scalable Platforms. | | Before you upgrade a Security Gateway, or Cluster Members to a new target version, you must upgrade the Management Server and Log Servers to that target version, or higher.
Only if you installed the Jumbo Hotfix Accumulator on your Management Server that adds support for the new target version, you can add the " *SkipVerifySupportedByOS* " parameter in the Central Deployment Tool configuration file ( `CentralDeploymentTool.xml` ) as follows: `` `` | | You cannot run the CDT as a scheduled job in the Gaia OS on your Management Server. | | You must back up your Management Server before upgrading the Traditional VSX Gateways or Traditional VSX Clusters (see [sk100395](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100395)). | | RMA backup fails on VSX Cluster Members in the VSLS mode. | | Installation and Upgrade | | CDT does not support upgrading Security Gateways / Cluster Members from versions R80.30, R80.20, and R80.10 (Issue PMTR-104840). Note: To upgrade from these versions to a higher version, use the CPUSE in-place upgrade. | | Upgrading Maestro is possible only to version R82 and higher (upgrading to R81.20 is not supported). Note: If your current version is R81.10, [R81.10 Jumbo Hotfix](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) Take 152 or higher must be installed to use CDT. | | CDT does not support Clean Install of a Major version. Note: This does not apply to the RMA mode. | | CDT does not support the installation of packages that contain RPM files (for example, the CPInfo package). | | If you use the Connectivity Upgrade (CU) in ClusterXL, see the [Connectivity Upgrade R77.x and R80.x Versions Best Practices](https://sc1.checkpoint.com/documents/Best_Practices/Cluster_Connectivity_Upgrade/html_frameset.htm) - Chapter "Connectivity Upgrade Limitations". | | If a remote Security Gateway connects to the Management Server through another Security Gateway (managed by the same Management Server), do not use the same batch for these two Security Gateways. Otherwise, the remote Security Gateway loses connectivity to the Management Server, because the Security Gateway in the middle reboots as part of its installation. | | CDT does not support an upgrade of Security Gateways in the VSX mode if you run the CDT on [R80.20.M1 Management Server](https://support.checkpoint.com/results/sk/sk123473). | | CDT might fail to deploy a package on a remote Security Gateway, if there is high traffic load on that Security Gateway. | | CDT does not support RMA Backup and RMA Restore on computers with these packages installed: * A CPInfo hotfix was installed (a hotfix package that replaced the *$INFODIR/bin/cpinfo*) * Hotfix packages installed with the Legacy method (with the *./UnixInstallScript* command) | | Hotfix for disabling and removing Kaspersky Lab components ( [sk118539](https://support.checkpoint.com/results/sk/sk118539) ): * CDT does not support the installation of this hotfix. * CDT does not support RMA Backup on servers, on which this hotfix is installed. * CDT does not support RMA Restore on servers, on which this hotfix was installed. | | CDT does not support a major upgrade of Security Gateways that run a QoS Policy or a Desktop Policy. | | When the CDT deploys a package to a Security Gateway, it installs only the Access Control policy. If the Security Gateway also has a Threat Prevention policy, you must install it manually from SmartConsole. | | CloudGuard Network | | CDT only supports: * CloudGuard Network for Azure Management Servers, Security Gateways, and Virtual Machine Scale Sets (VMSS) R80.10 and higher * CloudGuard Network for AWS Management Servers, Security Gateways, and Auto Scaling Groups (ASG) R80.10 and higher * CloudGuard Network for GCP Management Servers and Security Gateways R80.10 and higher * CloudGuard Network for NSX Security Gateways R80.10 and higher Note: CDT recognizes each CloudGuard Network for NSX Security Gateway as a single Security Gateway. | | When deploying a Hotfix package on Azure Scale Set or AWS Auto Scaling Group: 1. Disable Auto Scaling in the Cloud portal (to prevent scale-in and scale-out events during the package deployment). 2. Deploy the Hotfix package with CDT. 3. Re-enable auto-scaling in the Cloud portal. | {#Unique_ID_LimitationsTable}
FAQ {#FAQ} ---------- Click Here to Show the Entire FAQ 1. What is the impact CDT has on CPU usage and traffic bandwidth of the Management Server? > The main bottleneck when using CDT for multiple Security Gateways in parallel is the delivery of the CPUSE Offline package to the Security Gateways. > CPU usage will be high on the Management Server during the first phases of Candidates List generation and validation, and during the delivery of CPUSE Offline package. > After delivering the CPUSE Offline package, the CDT will only monitor the process by querying the Security Gateways every few seconds - a process that does not consume a lot of traffic bandwidth. 2. What user permissions on the Management Server do I need to run the CDT? > CDT should be executed by a user with "admin" Gaia OS role (user with ID 0) in Expert mode. 3. What will happen if the CDT is executed over an SSH connection and that connection is disconnected? > The *CentralDeploymentTool* process will terminate without completing installations. > To prevent that, CDT should be executed using the '[`nohup`](https://en.wikipedia.org/wiki/Nohup)' command: > `[Expert@HostName:0]# nohup /path_to_CDT/CentralDeploymentTool [options]` 4. My maintenance window is short. How can CDT help me? > CDT can be executed in **Preparations mode** . > In this mode, CDT delivers the CPUSE Agent RPM and CPUSE Offline package to the Security Gateways, without installing them. > There will be no connectivity loss on the Security Gateways. > If Preparations mode is executed *before* the maintenance window, the "installation" process will be much faster. > > Alternatively, CDT can be executed in **Extended preparations mode** . > In this mode, in addition to everything that Preparations mode accomplishes, CDT will update the CPUSE Agent on the gateways, import and verify the CPUSE package without installing it. > > In addition you can use **Advance mode** for doing preparations / Extended preparations by creating a deployment plan without any installation actions. 5. What manual actions should I take on the Management Server before / after running the CDT? > CDT allows fully automatic upgrades on the Security Gateways, including security policy installation. > If you are using additional Software Blades (e.g., Threat Prevention, QoS), you should install their policies manually *after* the upgrade. 6. Why does the CDT query all the Network Objects in the database during the installation/preparation? > Each time the CDT is executed, it makes sure that nothing has changed since the Candidates List has been generated. > This is done to ensure that the information that the administrator had when generating the Candidates List is still valid. > > To save time while querying the database, you can use a filter file in Advance mode: > 1. You can specify a list of gateways and/or clusters (not cluster members) for which to generate the Candidates List. > 2. Prepare a plain-text filter file with a list of the object names of each gateway and cluster as they appear in SmartConsole. > 3. When you generate the Candidates List, specify the filter file as well: > **$CDTDIR/CentralDeploymentTool -generate -candidates= -deploymentplan= -filter=**` ` 7. Does the Preparations/Extended Preparations mode cause connectivity loss on the Security Gateways? > No. > Connectivity is not affected when running preparations (pre-installations). The Preparations mode only executes user pre-installation scripts and sends the CPUSE Agent package and the CPUSE Offline package to the Security Gateways. > Extended preparations however, can cause connectivity loss when updating CPUSE. 8. After generating the Candidates List, CDT marked some of the Security Gateways as "`N/A`" in the "`Upgrade order`" column. Should I replace that value with a hyphen ("`-`")? > No. > The "`N/A`" value should not be changed. > CDT will not install any packages on Security Gateways that were marked with such a value. 9. How can I execute a custom shell script on the Management Server before or after running the CDT? > It is possible to create a custom Bash shell script that will execute the CDT (with the required syntax). > Before or after executing the CDT, the custom shell script can run different commands on the Management Server (the *CentralDeploymentTool* process is blocking - meaning that if a Bash shell script executes the CDT, it will not continue to the next command until the CDT finishes all its operations; this way the user can perform Action A, execute the CDT, and after CDT finishes, perform Action B). 10. Why does the CPUSE Agent on Security Gateways become unavailable/disabled for short periods of time during a CDT installation process? > CDT temporarily disables the self-update capabilities of the CPUSE Agent in order to prevent it from searching for CPUSE packages in the Check Point Cloud and updating itself during a CDT package installation. > Once the CDT installation completes, the CPUSE self-update will be enabled again. > This behavior is normal and does not affect package installations. 11. Is it possible to run several CDT processes in parallel? > * **On single Security Management Server**: > > Running several CDT processes in parallel is *not* possible. > * **On Multi-Domain Security Management Server:** > > It is possible to run a different CDT process for each Domain Management Server and install a package on several Domain Management Servers in parallel. > * Make sure to use a different Candidates List file for each Domain Management Server. > * You can run different Deployment Plan file for each Domain Management Server. > >
> > Note: running multiple instances of CDT is also possible in **Retry mode** . 12. Is it possible to copy the package to the gateway manually to shorten CDT installation time? > Yes. > It is possible to manually copy the package to the remote Security Gateway to the `/var/log/upload/` directory. > When executing the installation via CDT, CDT will detect that the package is already on the remote Security Gateway, will verify the package MD5 signature, will skip the sending stage and will continue to importing and installing the package. > > This can be useful if the bandwidth between the Management Server and the remote Security Gateways is limited, and sending files via CDT installation/preparations is slower than placing the package file on the remote Security Gateway by pulling them from an FTP server or another location. 13. Does CDT support VSX? > Yes, CDT supports VSX gateway, VSX Virtual System Load Sharing cluster and VSX High Availability cluster. 14. Is Fast Deployment (Blink) supported with CDT and VRRP Clusters? > Yes, this is an officially supported use case. Troubleshooting {#Troubleshooting} ---------------------------------- Click Here to Show the Entire Section 1. Scenario 1: RMA restore fails on Multi-Domain Server with the "*The backup file for Object: \ does bot exist.*" error > **Cause** : there are two possible reasons: > 1. When executing RMA backup, you did not provide your CMA IP address. > 2. The Security Gateway was not backed up (either the backup failed, or the Security Gateway was not included in the backup operation). > >
> > **How to resolve** : > Check if the backup file exists in `/backups/_backup.tar` ( *repository_path* refers to the path defined in the *CentralDeploymentTool.txt* configuration file, under the *repository_path* element) > > If the file exists: > 1. Create the directory `` in `/backups/` directory (if this directory does not exist already) > 2. Move the backup file from `/backups/_backup.tar` to `/backups/` > 3. Perform the RMA restore again. 2. Scenario 2: CDT leaves the following files on the Management Server: *CKP_mutex\*, ICA_MDS\*, sysFilecdt_\*, RmaTool_\.xml_cdt.lock* > **Cause** : CDT does not clean all the files when the execution finishes. > > **How to resolve**: delete the created files manually. 3. Scenario 3: The gateway did not boot up after running RMA restore > **Cause** : Before running RMA restore on an appliance, it must be running for at least 8 minutes. > > **How to resolve** : Before running RMA restore, make sure that that uptime is greater than 480: > 1. Connect to the command line on the Security Gateway > 2. Log in to the Expert mode > 3. Run: > **/bin/cat /proc/uptime | awk -F' ' '{ print $1 }'** > 4. Make sure the output is greater than 480 4. Scenario 4: CDT failed in *pull_file* action due to wrong md5sum after pulling the file. > **Cause** : The file changed dynamically during the*pull_file* action, causing CDT to detect that the pulled file is invalid. > > **How to resolve** : Do not use the *pull_file* action on files which change in high frequency. 5. Scenario 5: Pull file action fails with "*Error code 32*" error message > Example: > > ``` > An error has occurred in stage pull file stage of machine > Error code 32 - Failed to pull file from remote machine. Manually copy the file from the remote machine and try again. > ``` > > **Cause** : The Remote_Path attribute for the *pull_file* action was set to a directory instead of a file. > > **How to resolve** : *Remote_path* should be path to a file instead of directory. 6. Scenario 6: Error: "*Member roles are not supported -- installation is not allowed"* > **Cause** : At least one of your cluster members (XL/VRRP) is invalid > > **How to resolve**: Make sure your cluster is stable (Active/Standby or backup/master). 7. Scenario 7: "*Error code XX*" Message from CDT > Example: > > ``` > An error has occurred in stage Cluster Validation of cluster Cluster4: > Error code 80 - Cluster validation failed. > > Details: > The cluster is in an invalid state, please manually check the cluster. > > ``` > > **Troubleshooting steps** : > 1. To make sure you have the latest version of CDT: > `[Expert@HostName:0]# cpvinfo /path_to/CentralDeploymentTool | grep -E "Build Number|Minor Release."` > 2. Check the build number. > 3. For the latest available version of CDT, see [sk111158](https://support.checkpoint.com/results/sk/sk111158) > >
> > **To enable debug logs for CDT** : > 1. Edit the *CentralDeploymentTool.xml* configuration file in Vi editor: > **[Expert@HostName:0]# cp -v /path_to/CentralDeploymentTool.xml{,_ORIGINAL} > [Expert@HostName:0]# vi /path_to/CentralDeploymentTool.xml** > 2. Set the value of FileLevel attribute to DEBUG: > ** 3. Save the changes in the file and exit from the Vi editor. > 4. Execute CDT again. > 5. Check the log files in the */var/log/CPcdt/* directory on the Security Management Server. > >
> > **If the root cause is still not identified** : > 1. Identify the Security Gateway, on which the error was encountered. At the beginning of each log created by CDT for the Security Gateway and Cluster Member, there is some basic information about the gateway. > > Example: > > ``` > Members information: > Cluster4_1 , Cluster4 , 192.168.68.231 , R75.40/339 , active , 1 > Cluster4_2 , Cluster4 , 192.168.68.232 , R75.40/339 , standby , 1 > ``` > > The Security Gateway's and the Cluster's name are displayed in square brackets "\[\]" in the CDT output. > > 2. Identify the stage that failed > The stage name is displayed as part of the error message (in the main example: "*Cluster validation failed* "). > Some of the stages can be performed manually (for example, manually importing a CPUSE Offline package on the remote Security Gateway and Cluster Member). > >
> > **For further investigation, send these files to [Check Point Support](https://www.checkpoint.com/support-services/contact-support/)** : > 1. Security Management Server or Multi-Domain Security Management Server Files to Collect: > 1. Candidates List file created by CDT. > 2. */path_to_CDT/CDT_status.txt* or > */path_to_CDT/CDT_status_CMA_\.txt* file. > 3. The entire*/var/log/CPcdt/*directory. > 4. The entire */var/log/CPda/* directory. > 5. CPInfo file. > 2. Security Gateway or Cluster Members Files to Collect: > 1. The entire */opt/CPInstLog/* directory. > 2. CPInfo file. > 3. */var/log/message\** files. 8. Scenario 8: "*Error code 39 - Package importation failed on the remote machine*" Message from CDT during major upgrade to R80.10 > Example: > > ``` > An error has occurred in stage Import Package of cluster Cluster4: > Error code 39 - Package importation failed on the remote machine. Manually import the package to the CPUSE and try again. > Details: > DAClient import completed with errors. > ``` > > **Cause** : the prerequisites for upgrade to R80.10 are: > * Central Deployment Tool (CDT) version 1.1.5 and higher. > * CPUSE Agent build 1283 and higher > > In this specific case, CDT is v1.1.5 and higher, but the used CPUSE Agent build is lower than 1283. > > **Next Step** : Download and configure the latest [CPUSE Agent RPM file](https://support.checkpoint.com/results/sk/sk92449) . 9. Scenario 9: "*Error code 50 - Package installation on the remote machine failed due to timeout*" message from CDT during major upgrade to R80.10 > Example: > > ``` > An error has occurred in stage Import Package of cluster Cluster4: > Error code 50 - Package installation on the remote machine failed due to timeout. > Reboot the remote machine and try again. Contact Check Point Support if this problem persists. > Details: > Package installation timeout. Last status: > ``` > > **Cause** : the prerequisites for upgrade to R80.10 are: > * Central Deployment Tool (CDT) version 1.1.5 and higher. > * CPUSE Agent build 1283 and higher > >
> > In this specific case, CDT version is lower than 1.1.5. > > **How to resolve** : > 1. Verify that the Security Gateway / Cluster Member was upgraded to R80.10: > Run the `show version product` and `fw ver` commands on the Security Gateway or Cluster Member. > 2. Connect with SmartConsole to Security Management Server or Domain Management Server. > 3. Install the Security policy on the upgraded Security Gateway or Cluster Member. > 4. In the case of a Cluster, verify that the version in the Cluster object was updated to "R80.10" and in the Install Policy window. > Clear the box indicating if installation on a cluster member fails, not to install on that cluster. > 5. Make sure to use Central Deployment Tool version 1.1.5 and higher. > 6. Download and configure the latest [CPUSE Agent RPM file](https://support.checkpoint.com/results/sk/sk92449). > 7. Manually execute any post-installation scripts on the Security Gateway / Cluster Member. > 8. If you upgrade a cluster, generate a new Candidates List and run CDT again to continue installation on the second cluster member. 10. Scenario 10: When CDT runs, it shows that the Candidates List file is invalid and should be regenerated > **Cause** : There are three possible reasons: > 1. Something might have changed in the Management database and the Candidates List does not contain the most up-to-date information. > 2. An invalid syntax is used when editing the Candidates List file. > 3. In the Basic Mode, the `PackageToInstall` element in the `CentralDeploymentTool.xml` was changed, or in Advanced mode, the deployment plan was changed after the candidates list generation. > >
> > Only hyphens (-) or numbers are allowed as user input in the upgrade order column. N/A is also acceptable. > No other changes should be made in the Candidates List. > > **How to resolve** : > 1. Regenerate the Candidates List. > 2. Edit it to mark or unmark candidates for installation and try again. 11. Scenario 11: Installation or preparations fail after CDT executes a user shell script on the Security Gateway. > **Cause** : The user shell script does not comply with the requirements of CDT. > > **How to resolve** : > 1. Check the user shell script independently of CDT to make sure that no connectivity loss or unexpected behavior occurs. > 2. In addition, make sure that there is no reboot operation within the user shell script. > 3. If you want CDT to reboot the Security Gateway after running the user shell script, the script must exit with a return code of "222." 12. Scenario 12: Problems with Candidates List generation occur due to the current licenses > **Cause** : Current licenses are expired and/or insufficient > > **How to resolve** : > 1. Make sure you have valid and sufficient licenses on all involved gateways. Run: > `[Expert@HostName:0]# cplic print` > 2. Refer to [sk92449](https://support.checkpoint.com/results/sk/sk92449) - subsection "A. License and contract": > * A valid license must be installed on the target gateway. > * A valid Software Subscription or Technical Support Contract has to be associated with the license. > * The Contract File must be installed on the target gateway. 13. Scenario 13: Importing and installation problems occur due to CPUSE requirements and limitations. > **How to resolve** : > 1. Refer to [sk92449](https://support.checkpoint.com/results/sk/sk92449) - section "(2) System requirements and limitations". > 2. Refer to `/opt/CPInstLog/DeploymentAgent.log.*` and `/opt/CPInstLog/install_*.log` files on the Security Gateway. 14. Scenario 14: Installation of a software package (Hotfix or upgrade) fails on one cluster member and succeeds on another. > **Cause** : The latest available build of the CPUSE Agent is deployed gradually to the Gaia systems that are connected to the Internet. > The CPUSE Agent on the cluster member which fails to install the package, already detects that a newer build of the CPUSE Agent is available. By design, before any package installation is allowed, the CPUSE Agent must be updated to the latest available build. > The CPUSE Agent on the cluster member which succeeds to install the package, does not yet detect that a newer build of the CPUSE Agent is available. Therefore, the package installation is allowed. > > **How to resolve** : > 1. Download the latest available build of the [CPUSE Agent](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449) > 2. Extract the CPUSE Agent RPM package and place it in the repository on the Management Server > 3. Using the CDT, start the package installation again on the cluster member, that failed. 15. Scenario 15: CDT does not perform the actions listed in a provided Deployment Plan file. Instead, it installs a single package. > **Cause** : The `PackageToInstall` element is defined in the `CentralDeploymentTool.xml` configuration file, leading CDT to run in the Basic Mode. > > **How to resolve** : Remove the `PackageToInstall` element from the configuration file and try again. 16. Scenario 16: After RMA restore, Gaia Portal is not accessible on the Security Gateway. > **Cause** : RMA restore changes the permissions of some directories like `/opt` or `/etc` , causing the Gaia Portal to stop functioning. > > **How to resolve** : > 1. Download the [fix_rma_restore.sh](https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/media-type/html?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=61010) script to your computer > 2. Copy the script from your computer to the Security Gateway > (for example, to `/var/log/fix_rma_restore.sh`) > 3. Connect to the command line on the Security Gateway > 4. Log in to the Expert mode > 5. Go to the directory with the script > In our example: > `cd /var/log/` > 6. Assig the "execute" permission to the script: > `chmod -v +x fix_rma_restore.sh` > 7. Run the script > `./fix_rma_restore.sh` 17. Scenario 17: "*Error code 22 - Error loading configurations from the configurations file*" message from CDT. > **Example** : > > ``` > > ************************************************ > Configuration error has occurred: > > Error code 22 - Error loading configurations from the configurations file. > Make sure that the configurations file is valid. Try to reinstall the tool and use a clean configurations file. > > Details: > -------- > Failed to load the configuration file: /opt/CPcdt/CentralDeploymentTool.xml > Cause: The configuration file CentralDeploymentTool.xml is invalid. > ************************************************ > > ``` > > **How to resolve** : Make sure that the configuration file is in a valid XML syntax. 18. Scenario 18: "*Cannot run multiple, simultaneous instances of CentralDeploymentTool \*" after stopping a previous instant of CentralDeploymentTool with Ctrl + C > **Cause** : The CentralDeploymentTool executable is in status ' *Terminated* ' and considered to be still running by the operating system. > > **How to resolve** : > 1. Connect to the command line on the Management Server. > 2. Log in to the Expert mode. > 3. Get the Process ID of the previous instance of CentralDeploymentTool: > `pidof CentralDeploymentTool` > 4. Kill the previous instance of CentralDeploymentTool: > `kill -9 ` 19. Scenario 19: *TDERROR* messages from *CPRID* appear in the active session of the Security Gateway while running CDT. > **Cause** : *TDERROR* is enabled by default for *CPRID* . > > **How to resolve**: Unless you encounter other issues on the Security Gateway, you can ignore these messages. They do not indicate a specific problem. 20. Scenario 20: RMA backup fails during the "*save configuration*" command due to Segmentation fault. > **Example** : > > ``` > An error has occurred in stage Run RMA tool: backup of machine GW-68.154: > Error code 93 - Failed to run RMA tool. > Details: > -------- > Execution of action: backup failed. > Additional Information: > ************************************************ > An error has occurred in stage Backup Machine Configurations of machine: > Error code 24 - Could not backup machine configuration file. > Details: > -------- > Failed to save configuration > Additional Information: > ----------------------- > /bin/bash: line 1: 24968 Segmentation fault clish -c "save configuration Machine_settings.conf" > > ``` > > **Cause** : The line " `snmp:mode default` " is missing from the Gaia Database. > This can be verified by running the command > `[Expert@Host]# cat /config/active | grep "snmp:mode"` > > **How to resolve** : Follow instructions in [sk123562](https://support.checkpoint.com/results/sk/sk123562) . 21. Scenario 21: ERROR: Cluster state of \ is invalid. To fix it, refer to the CDT SK. > **Cause** : The cleanup of *FwhaVersionStage* failed and the cluster member has an invalid state. > > **How to resolve** : To get the new *fwha_version* : > 1. Connect the command line on the Cluster Member, on which the updrade finished successfully. > 2. Run: > `fw ctl get int fwha_version` > The output is the "fwha_vesion" that must be configured on the problematic Cluster Member. > >
> > To configure the new *fwha_version* without connectivity loss: > 1. Stop the Delta synchronization: > * On a VSX Gateway / each VSX Cluster Member, run these commands in the Expert mode for each Virtual System: > 1. `vsenv ` > 2. `fw ctl setsync off` > * On a non-VSX Security Gateway / Cluster, run in the Expert mode: > `fw ctl setsync off` > 2. Configure the required "*fwha_version* " value: > `fw ctl set int fwha_version ` > 3. Start the Delta synchronization: > * On a VSX Gateway / each VSX Cluster Member, run these commands in the Expert mode for each Virtual System: > 1. `vsenv ` > 2. `fw ctl setsync start` > * On a non-VSX Security Gateway / Cluster, run in the Expert mode: > `fw ctl setsync start` > >
> >
> 22. Scenario 22: Error code 81 - The firewall policy on the remote machine is invalid. Make sure that the policy on the machine is installed. > Example: > > ``` > ************************************************ > An error has occurred in stage Validate policy installation of machine : > > Error code 81 - The firewall policy on the remote machine is invalid. Make sure that the policy on the machine is installed. > > Details: > -------- > Failed to get information on VS with id: 3. The installed firewall policy is: > ************************************************ > > ``` > > **Cause** : One or more VS failed to fetch the policy from the Management Server. > > **How to resolve** : Install policy from the SmartConsole or reboot the VSX Gateway / VSX Cluster Member. > 23. Scenario 23: "Failed to generate candidates list" error when using the "execute_command" action with CDT version 1.6 build 990180509. > Example: `"*E* [Main]: Failed to generate candidate list.`" error. > > **How to resolve** : To check what CDT build you are using, run: `$CDTDIR/CentralDeploymentTool -v` > > To resolve the problem, download build 990180511 of CDT version of 1.6. from the Downloads table above. > 24. Scenario 24: Error code 48 - Package installation on the remote machine failed due to timeout. Reboot the remote machine and try again. > Example: > > ``` > ************************************************ > An error has occurred in stage Install Package Check_Point_R80.20_T101_Fresh_Install_and_Upgrade_Security_Management.tgz of machine vsx_gw: > > Error code 48 - Package installation on the remote machine failed due to timeout. > Reboot the remote machine and try again. > Contact Check Point Support if this problem persists. > > > Additional Information: > -------- > The machine did not resume from reboot. > ************************************************ > > ``` > > **Cause** : There are 2 possible causes: > 1. If Security Gateway has the *InitialPolicy* installed: > * The Security Gateway does not have a valid license > * The Security Gateway tried to fetch the policy from the wrong directory / Management Server > 2. If the Security Gateway succeeded to fetch the new policy: > * The Security Gateway took a long time to boot > >
> >
> > **How to resolve** : > > 1. Check if the Security Gateway has policy other from *InitialPolicy* installed. > If there is another policy, increase the timeout of CDT using "*Debug Configuration* ": "*WaitForRebootCompletionTimeout* ". > See the CDT Administration Guide for information on how to add debug configuration to CDT. > > 2. Check if the Security Gateway has a valid license. If not, attach a new license and try to install policy from the SmartConsole. > > 3. Validate that the *masters* file on the Security Gateway contains the correct Security Management Server / Domain Management Server name: > 1. In the Expert mode, run: `cat /var/$FWDIR/conf/masters` > 2. In the section "*Policy*", make sure the name of the Security Management Server / Domain Management Server is correct. > 3. If it is not the correct name: > 1. In SmartConsole, open the Security Gateway object > 2. From the left, go to "Fetch Policy" > 3. Select the correct Management Server object > 4. Click OK > > For example: > ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk111158/TroublQ241901160524.png) > 4. Install policy from the SmartConsole. > >
> >
> 25. Scenario 25: "Error Code 85 -- Error retrieving package information" message during RMA Restore > **![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk111158/2520200326170918.png) > Cause:** this hotfix is part of R77.30 GA replacement version (included); it wasn't installed as independent package. > > **How to Resolve:** in this case (hotfixes are part of major version and not installed as independent packages), run a user script before running RMA backup which adds this hotfixes to the following file so CDT will ignore it when creating the backup file. > Add the Hotfix name (HOTFIX_GAIA_GEYSER_PINK8_HF in this case) to */sysimg/CPwrapper/linux/MiniWrapper/installation_list.conf* > Note: Create this file if it does not exist on your Security Gateway. > Revision History {#Revision History} ------------------------------------ Show / Hide revision history |-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Date | Description | | 25 Sep 2026 | Updated the Known Limitations section. | | 08 Jul 2026 | Updated the Known Limitations section. | | 05 Jul 2026 | Added High Level Flow \> Workflow for upgrading Maestro. | | 04 Sep 2025 | Updated the Known Limitations section. This limitation was removed as resolved: "CDT supports only Hotfix and Jumbo Hotfix Accumulator packages on CloudGuard Network machines. CDT does not support Minor and Major upgrade packages are not supported on CloudGuard Network machines." | | 31 Jul 2025 | Release of Central Deployment Tool v2.2 |

--- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content