5.2 SmartConsole Central Deployment Tasks & CDT XML Batch Plans

SmartConsole Central Deployment Task Flow

For most CCSE lab and exam scenarios, start with Central Deployment in SmartConsole:

1. Confirm packages exist in the Management Server Package Repository (or are available from Check Point Cloud).
2. Select one or more Security Gateway / Cluster Member targets.
3. Launch Central Deployment to install the hotfix or upgrade package.
4. Monitor the SmartConsole task until all targets report success.
5. Validate versions and reinstall policy if a major release changed.

ClusterXL HA / MVC behavior

On supported ClusterXL HA topologies, Central Deployment:

1. Upgrades Standby members first
2. Enables Multi-Version Cluster (MVC) so current connections can synchronize between members on different versions
3. Fails traffic over as needed and upgrades remaining members
4. Completes when the cluster is fully on the target package/version

This is the connection-preserving path called out in R82 Release Notes for Central Deployment in SmartConsole.

---

Advanced Path: CDT CLI Execution Modes

CDT Execution Modes

When using the CLI tool, CDT operates in one of three functional execution modes depending on the management infrastructure topology and administrative objective:

1. Primary Mode (Default): Executed on the main Security Management Server (SMS) or Multi-Domain Management Server (MDS). In Primary mode, CDT parses the XML deployment plan, connects to all target Security Gateways, distributes packages, manages execution phases, orchestrates cluster failovers, and compiles central logs.
2. Secondary Mode: Used in complex Multi-Domain Management (MDS) topologies with distributed Domain Management Servers (DMSs). A Secondary CDT instance runs on a subordinate DMS to assist the Primary MDS engine by handling local domain gateway pre-checks and package transfers.
3. Standalone Mode: Executed directly on a single target Security Gateway in Expert mode. Standalone mode allows an administrator to run a standardized CDT XML plan locally on one appliance without initiating management-wide orchestration.

---

XML Deployment Plan Architecture (deployment_plan.xml)

At the core of CDT's automation is the XML Deployment Plan. This structured configuration file defines what packages to deploy, which gateways to target, what pre-checks and post-checks to run, and how reboots and cluster failovers should be handled.

Key XML Elements & Hierarchy

An XML deployment plan consists of several key sections defined within the root <deployment_plan> tag:

• <plan_settings>: Defines global parameters such as logging levels, parallel execution thread limits, and global reboot behavior.
• <target_gateways>: Lists target gateways by object name (as defined in SmartConsole) or IP address.
• <packages>: Specifies the exact CPUSE package file name or build number located in the SMS repository.
• <pre_checks>: Defines system validation tasks executed before package installation (e.g., disk space checks, active connection thresholds, interface status checks).
• <execute_script>: Specifies custom shell or Gaia Clish scripts to run on target gateways before or after package installation.
• <post_checks>: Specifies health verification tests executed after package installation and reboot (e.g., verifying cluster sync, checking process daemons).

Detailed Structure of CDT XML Tags

Complete Example: deployment_plan.xml

The following complete XML deployment plan demonstrates an enterprise-grade upgrade workflow for deploying a Jumbo Hotfix Accumulator to a pair of Security Gateways with custom pre/post scripts and automated rebooting:

<?xml version="1.0" encoding="UTF-8"?>
<deployment_plan>
    <plan_settings>
        <name>R82_JHA_Take25_Batch_Deployment</name>
        <description>Automated upgrade of production gateways to R82 JHA Take 25</description>
        <type>JHA</type>
        <max_parallel_gateways>5</max_parallel_gateways>
        <log_file>/var/log/cdt/R82_JHA_Take25.log</log_file>
    </plan_settings>

    <target_gateways>
        <gateway>Corporate_GW_VSX</gateway>
        <gateway>Branch_GW_01</gateway>
        <gateway>Branch_GW_02</gateway>
    </target_gateways>

    <packages>
        <package>
            <package_file>Check_Point_R82_JHF_Take_25_main.tgz</package_file>
            <reboot_gateway>true</reboot_gateway>
        </package>
    </packages>

    <pre_checks>
        <check_disk_space path="/var/log" min_free_gb="30"/>
        <check_sic_status/>
        <check_cluster_state required_status="OK"/>
    </pre_checks>

    <custom_scripts>
        <execute_script stage="pre-install" path="/var/log/cdt/scripts/backup_routing.sh"/>
        <execute_script stage="post-install" path="/var/log/cdt/scripts/verify_services.sh"/>
    </custom_scripts>

    <post_checks>
        <check_process_running process_name="fwk"/>
        <check_cluster_state required_status="OK"/>
        <compare_routing_table reference_file="/tmp/routing_pre.txt"/>
    </post_checks>
</deployment_plan>

---

Cluster-Aware Batch Upgrades & Zero-Downtime Algorithms

Upgrading Security Gateway clusters (ClusterXL High Availability or Load Sharing) requires strict orchestration to prevent network outages and drop active user sessions. CDT contains built-in cluster intelligence that executes upgrades using a staggered zero-downtime workflow:

Sequence of ClusterXL Upgrade via CDT:

[Step 1: Identify Members] ---> Primary Active (GW-A)  |  Secondary Standby (GW-B)
                                        |
[Step 2: Upgrade Standby]  ---> GW-B receives package, installs, and reboots.
                                        |
[Step 3: Health Verification]--> CDT verifies GW-B state is 'Standby' and synced.
                                        |
[Step 4: Controlled Failover]-> CDT executes 'cphastop' on GW-A.
                                GW-B transitions to 'Active' (Traffic shifts).
                                        |
[Step 5: Upgrade Former Active]->GW-A receives package, installs, and reboots.
                                        |
[Step 6: Cluster Stabilization]->GW-A joins as 'Standby'. Cluster fully upgraded!

When <zero_downtime>true</zero_downtime> is set in the XML plan for a cluster target:

1. CDT inspects cluster health via cphaprob stat to confirm both members are fully synchronized.
2. CDT targets the Standby member first while the Active member continues forwarding production traffic.
3. Package installation and reboot occur on the Standby member.
4. Post-reboot, CDT verifies that the upgraded member has rejoined the cluster in a healthy state.
5. CDT initiates a controlled cluster failover (gracefully stopping cluster services on the active node using cphastop or clusterXL_admin down). Traffic seamlessly transitions to the upgraded node.
6. CDT then upgrades the former Active member, bringing the entire cluster to the target release without dropping established connection state tables.

---

Executing CDT Plans via CLI

To run a CDT deployment plan, the administrator executes the CentralDeploymentTool binary (aliased as cdt) from Expert mode on the Security Management Server.

Primary Syntax & Options

cdt -action <action_type> -plan <plan_xml_file> [optional_flags]

Common Execution Examples

1. Executing a Complete Upgrade Plan:

[Expert@SMS:0]# cdt -action execute -plan /var/log/cdt/plans/deployment_plan.xml

1. Executing Pre-Checks Only (Dry Run):

Before performing an actual installation during a maintenance window, administrators can execute a dry run that runs pre-checks without pushing software packages:

[Expert@SMS:0]# cdt -action check_prerequisites -plan /var/log/cdt/plans/deployment_plan.xml

1. Overriding Target Gateways from CLI:

To execute an existing XML plan against a specific subset of gateways without editing the XML file:

[Expert@SMS:0]# cdt -action execute -plan deployment_plan.xml -gateways Branch_GW_01,Branch_GW_02

1. Monitoring Live Status:

[Expert@SMS:0]# cdt -action status -plan deployment_plan.xml