Admins can enable/disable the required modules from General Settings. You can take a module tour to get started with each modules from the Product Tours section. Code versions of the Core, UI, and Database are displayed here. You can also edit the email of the account.
Plugin Updates
The Periodically check for plugin updates toggle periodically checks every plugin repository for updates and notifies you when migrations are available for plugins.
If the toggle is enabled, Cloud Exchange will automatically check for and retrieve plugin updates from GitHub. Ensure your environment has network connectivity to github.com for automatic update fetching.
Run Diagnose and Download
Admins can generate and download a diagnostic bundle from Settings > General Settings > Other Settings to help with troubleshooting.
- Click Run Diagnose to start collecting diagnostic logs.
- While the diagnosis is running, the Run Diagnose button shows Running… and remains disabled.
- The Download File button is enabled only when the diagnostic bundle is ready.
- Click Download File to open a confirmation dialog.
- Optionally, you can select Remove diagnose file from the cloud exchange after successful download to delete the generated bundle from Cloud Exchange storage after download.
- If no diagnostic job exists, or the diagnosis is still in progress, Cloud Exchange shows a status message and prompts to run or wait before downloading.
- The diagnostic file name is automatically derived from the server response and is downloaded as a
.zipfile.
Run Upgrade/Migrate Check and Download Report
Admins can validate a host against the prerequisites for a target Cloud Exchange version from Settings > General Settings > Other Settings before upgrading or migrating. The check is read-only; nothing on the host is changed.
Click play to watch a video.
For versions 7.0.0 and later
- Click Run Upgrade/Migrate Check to open the check dialog.
- Select the Deployment Type. Standalone (SA) runs the check on this single host. High Availability (HA) runs it across every node in the cluster, and each reachable node is reported separately.
- Select the Target Cloud Exchange Version, that is, the version whose prerequisites you want to validate. You can also select the currently installed version to validate the host as it is today.
- Click Run to start the check.
- When the check completes, the results appear in the dialog, grouped by category, with failed and warning items listed first.
- Click Download Report to download a shareable HTML report, or Download JSON to download the detailed report in JSON format.
- Click Run Again to rerun the check after you have addressed the reported items.
- The results of the last run are retained, so you can reopen them later from the same page. When a completed report exists, the button shows View Upgrade/Migrate Check.
A clean result confirms that the host meets the prerequisites for the selected version. It is not a guarantee that an upgrade or migration will succeed.
For versions prior to 7.0.0
- Copy the
ce_healthcheckfile fromta_cloud_exchangerepository to the host. - Run it as an administrator:
sudo python3 ./ce_healthcheck - Review the results on screen. A detailed report is saved as
ce_healthcheck_report.jsonin the current folder. - The run context, deployment type, and installed version are detected from the host and printed before the checks run. Nothing is prompted for.
You can override any detected value with the following options.
| Option | Description |
|---|---|
--deployment SA|HA | Set the deployment type instead of detecting it. |
--target-version | Set the Cloud Exchange version to validate against. |
--mode install|upgrade|migrate | Set the run context instead of detecting it. |
--list-versions | List the Cloud Exchange versions that can be selected. |
--html <path> | Save a shareable HTML report. |
--report <path> | Save the detailed JSON report to a specific location. |
--manifest-path <path> | Use a locally supplied set of check definitions, for a host with no outbound internet access. |
--quiet | Suppress the detected-value notes. |
- The check must be run with
sudo. Without administrator rights it cannot read everything it needs, and a healthy host can be reported incorrectly. The check stops with an explanatory message rather than reporting a result it cannot stand behind.On a host where Cloud Exchange is not installed yet, there is no UI from which to run the check. In that case, run the same check from the command line using thece_healthcheckscript, which is a single self-contained file with no packages or dependencies to install.
When to Run the Upgrade/Migrate Check
- Before you upgrade or migrate a deployment, and again after you have addressed any reported item.
- After a change to the host, such as resizing the machine, adding disk, or a change to firewall or proxy rules.
- Before you open a support case about a failed install or upgrade, so that Netskope Support can see the state of the host.
Understand the Results
Every check reports one of five results.
| Result | Meaning | What to do |
|---|---|---|
| Pass | The host meets this requirement. | No action required. |
| Warning | The requirement is met, but something needs your attention. For example, a value is below the recommended level rather than below the required minimum, or a required port is already in use by the Cloud Exchange service that is meant to own it. | Review the item and the corrective measure shown with it. A warning does not block an upgrade. |
| Failed | The host does not meet a mandatory requirement. The install or upgrade is expected to fail, or to leave the deployment in a poor state. | Fix the item using the corrective measure shown with it, then run the check again. |
| Not applicable | The check does not apply to this host, such as the High Availability cluster checks on a standalone deployment, or the Podman checks on a host that runs Docker. | No action required. |
| Not verified | The check could not be completed on this host, so the requirement is neither confirmed nor ruled out. For example, a version could not be read, or a command could not be run. | Review the reason listed with the item. Treat it as unconfirmed, not as a pass. |
A count of each result is shown with the results, followed by an overall verdict.
| Verdict | Meaning |
|---|---|
| This host meets the prerequisites for the selected Cloud Exchange version. | Every applicable check passed. You can proceed. |
| This host meets the mandatory prerequisites. Review the warnings before proceeding. | Nothing mandatory failed, but some items need your attention. |
| Verified some of the checks; the rest could not be verified. | Nothing mandatory failed, but part of the host was not assessed. Review the unverified items before proceeding. |
| One or more prerequisite checks have failed. Please ensure the minimum system requirements are met to proceed further. | Do not proceed. Address every failed item and run the check again. |
| None of the prerequisite checks could be verified on this host. | This is not a pass. Nothing was actually assessed. Run the check again after the conditions needed to perform it are in place. |
In a High Availability deployment, nodes that could not be reached are called out separately and are not included in the totals.
Reports
- The HTML report is a readable summary of the run that opens in any browser, listing every check, its result, and its corrective measure. In a High Availability deployment, all nodes are merged into a single report. Use this to share results with your team.
- The JSON report is the detailed record of the run, including the measured values collected from the host. Attach this to a support case.
- Both reports include details about the host. Store and share them with the same care as any other system record.
If the Check Cannot Run
| Message | What to do |
|---|---|
| This check must run as root. | Run the check again with sudo. |
| The check definitions could not be downloaded. | The host has no outbound internet access, or it is blocked by a proxy or firewall. Obtain the check definitions file separately and supply it with --manifest-path. |
| The selected Cloud Exchange version does not exist in these check definitions. | Select a version that is covered. Use the version list in the UI, or --list-versions from the command line, to see which versions are available. |
Renew Certificates
You can renew SSL certificates on Cloud Exchange servers before they expire. The UI shows a banner when a certificate is about to be expired in less than 30 days, and the Renew Certificates button will be enabled under Settings > General Settings.
- A Warning banner appears in Cloud Exchange when the certificates are within 30 days of expiration.
- By default the Renew Certificate toggle is disabled; it becomes enabled only when the certificates are within 30 days of expiry.
- Cloud Exchange generates certificates with a validity of 365 days.
- Cloud Exchange regenerates only those certificates that were originally generated by Cloud Exchange.
- After you click Regenerate Certificate, Cloud Exchange will restart with the newly generated certificates and you might see a Network Error. After a few minutes Cloud Exchange will be up and running again.