The CME package should be installed only one time on your Management Server. After the first installation, the CME package is updated automatically with the release of any new version (as long there is Internet connectivity).
Use the installation script for the first-time installation of CME.
Automatic Updates support - CME now has the ability to update itself with the release of any new version automatically without interfering with the customers' work.
Take 83 (19 Mar 2020)
Migration from Py2 to Py3
With this new CME take, CME requires Jumbo Hotfix installed with minimum version
R80.10 - Jumbo HFA Take 249
R80.20 - Jumbo HFA Take 117
Take 79 (5 Jan 2020)
Minor code improvements.
Take 76 (18 Dec 2019)
Added support for NSX-T 2.5
CME service does not come up after reboot.
Take 66 (22 Oct 2019)
For all platforms:
Set a prefix to all SmartConsole objects created by the CME. For more information run 'autoprov_cfg set template -h' and look under '-pn'.
Added the CME take number to version's information (through 'autoprov-cfg -v' and cme_menu).
For Azure: Improved handling of API request throttling
Autoscaling: integration with Network Load Balancer new listeners: UDP and UDP_TCP
Transit VPC: spoke-routes and export-routes are now configured via the autoprov_cfg tool.
TGW: The Gateway can be configured to re-advertise desired spoke routes over BGP back to the TGW (for Direct Connect).
TGW: Gateways can be configured to automatically set static routes on their instance route table.
Fixed degradation inserted in Take 55 - Custom Gateway script (-cg Flag) is now supported on AWS and GCP, not just Azure.
Take 55 (06 Aug 2019)
Added support for Security Management Servers and Multi-Domain Security Management Servers deployed in Azure and AWS.
Added support for NSX-T. For more information, refer to sk139213.
First release of Automatic Hotfix Deployment for autoscaling solutions in Azure, AWS, and GCP. CME Automatic Hotfix Deployment allows automatic deployment of Hotfixes and Jumbo Hotfix Accumulators on scaled-out instances. Refer to the Cloud Management Extension Administration Guide for more information.
Minor fixes and stability improvements.
Take 45 (05 Jul 2019)
First release of CME (Cloud Management Extension).
Supports only GCP MIG (Multi Instance Group) solution.
Supports Security Management Servers deployed in Google Cloud Platform only.
CME cannot work in parallel to Autoprovision Add-On. When you install CME on a Security Management Server with Autoprovision Add-On deployed, the Autoprovision Add-On is disabled. The configuration for the old service remains the same, and the new CME service uses it. Reverting to the Autoprovision Add-On is not supported.
On a Multi-Domain Server, CME works on the configured Domains sequentially (and not on all Domains in parallel).
When you install a new CME package on the Security Management Server, you might need to re-log into the shell before you can use the package.
Automatic Hotfix deployment and setting a prefix to all SmartConsole objects features cannot be activated in parallel for the same controller.
CME cannot be installed on a Multi-Domain Log Server.
In Management High Availability environments, future installation does not happen automatically. You must run the script cme_installation.sh each time you wish to install a new version of CME. Refer to Installation Procedure for Online Package.
Issues described below may occur when you run the CME installation script. Error messages may be similar to those listed below.
Solution: CME has already been installed for the first time and is configured to receive updates automatically. If you have no internet access, follow the instructions for offline installation as described in the solution to Issue # 1 above.
Solution: Install the correct Jumbo Hotfix Accumulator as described in the beginning of the Known Limitations section. If the correct Jumbo Hotfix Accumulator is installed, but the issue persists, the follow these steps and then try again:
Symptoms: 1) "Starting cme: failed to run" error appears during CME revert. 2) CME installation fails after CME revert-completely. 3) CME fail to start, and /var/log/CPcme/cme.log contains "bad decrypt" or "Failed to load CME configuration due to incompatible schema" error. 4) CME from take 212 or higher is installed only on the active server, and CME on the standby member fails to start.
Cause: 1) Starting CME take 212 CME configuration has a schema version 2) The schema version attribute ensures that only compatible CME runs with the given CME configuration. 3) CME does not run when the CME configuration schema version is incompatible. 4) Example scenarios that can cause incompatibility:
a. Revert to older CME take. b. Upgrade – export configuration and import it on a server with an older CME take. c. High Availability Management/Multi-Domain servers where the CME on the two members is not from the same take.
Note - CME configuration file is not reverted.
High Availability Scenario:
1) CME configuration file is synchronized between the members. 2) CME loads the configuration during CME boot. 3) If the CME on the standby member is from an older take, it will fail to start because CME is not compatible with the schema version.
Because CME configurations are stored in $MDSDIR/conf, the active server is the member with the active global domain.
CME must not run on the standby member of a Security Management Server.
Downgrade scenario: When reverting to old CME take (revert or revert-completely + install) and the old CME is not compatible with the schema version, CME does not start.
High Availability scenario: Install the same CME take in all the High Availability servers.
Option 1 - install supported CME take (recommended):
Run "autoprov_cfg show all" and examine the schema version value.
Install a CME that supports the existing schema version value.