Welcome to this lesson on the Central Deployment Tool. By the end of this lesson, you will be able to: describe when should see the CDT be used, describe the prerequisites for the deploying with CDT, describe the process of deploying with CDT, use CDT to perform a common use case deployment, perform basic troubleshooting in the CDT deployment process, and you will be able to use CDT's RMA mode. When should we use CDT? CDT, the Central Deployment Tool, is a powerful command line utility, which runs on management servers and multi-domain management servers running iOS. Using a set of configuration files, it lets you manage an offline deployment of software packages from your management server or multi-domain server to multiple managed gateways and cluster members at the same time. This allows you to: install software packages, perform various actions such as taking snapshots, running shell scripts, and pushing and pulling files. It allows you to automate the RMA backup and restore process, and it handles cluster upgrades automatically including connectivity upgrade, so if you need to perform advanced automated actions on multiple gateways, you should definitely use CDT. Otherwise, for orchestrating the deployment on multiple gateways, you should use the Central Deployment in SmartConsole, which is our next lessons' topic. In terms of prerequisites, make sure to review sk111158, for the minimum requirements for management servers and multi-domain management servers, and for gateways, and cluster members. In general terms, deploying with CDT involves the following key steps: importing the deployment package to the server used for package distribution to the gateways, editing the Central Deployment Tool, which defines logging and notification settings for the deployment process, editing the deployment plan, which defines a sequence of deployment actions, generating the installation Candidate List to get a full list of deployable gateways and cluster members, and finally, running the deployment plan. Let's look at the following scenario, and see how we can accommodate its requirements. Bob, a Security Administrator, is in charge of maintaining an environment of 100 gateways. He would like to upgrade only 50 gateways and clusters form R80.30 to R80.40, and deploy the latest Jumbo Hotfix to all machines after their upgrade. In between those actions, Bob would like to perform additional actions, including running scripts, such as updating the DNS address and taking a snapshot of the system. This deployment will be conducted offline from a management server. Since his deployments targets requires an orchestration of the deployment on multiple gateways and include several advanced actions during the process, he chooses to use CDT. Before we begin to set up the deployment, we first need to import the deployment packages to the server used for package distribution. As we previously saw in the CPUSE lesson, we can download the packages from the user center to the local folder on our computer. Then, we transfer them to the designated server. This can be done, for example, via SFTP. To deploy with CDT in such a use case, we connect to the command line on the management server used for package distribution. We log in using the expert mode and make sure that there is no active session on SmartConsole, which is locking the management database. Now, we proceed to edit the Central Deployment Tool XML file. Bob would like to create a comprehensive log file for the process, so he keeps it on the default debug mode. He would also like to receive a summary of the deployment, so he defines his e-mail address under mail notification. This only applies if a valid mail server is configured on the management server or multi-domain server, otherwise, delete this element. After configuring the Central Deployment Tool XML, Bob turns to the second configuration file; the deployment plan, which runs a number of actions one after the other. Bob would like to avoid any traffic connectivity loss of cluster members within his deployment, so he sets the connectivity upgrade to two. This ensures the target clusters maintain a connection failover. At this stage of setting up your deployment, you can choose to perform various actions on your remote machines. Supported actions include: importing a package, executing a command, creating a snapshot, and installing a package. In Bob's case, he needs to deploy the latest Jumbo Hotfix to all machines after their upgrade. In between those actions, additional actions need to be performed. This includes running a script to update the DNS address on the gateways and taking a snapshot on each and every target gateway. Now that Bob has a deployment plan, he can create a candidate list, which is a comma-delimited CSV file generated by CDT, listing the gateways on which to install the CPU's packages. Remember, Bob needs to select 50 out of 100 gateways for deployment. Let's step aside for a minute and talk about how the candidate list works. When you generate the candidate list, CDT scans the management servers database for potential candidates and creates a list based on the gateways that are eligible for installation. CDT assigns a batch number to gateways that are eligible for package installation. It installs the packages, in parallel, on all batch members that have the same batch number. When installations on candidates in the same batch complete, the next batch is run. When all the batches are completed, the installation process is completed. Note that when working with clusters, all members of the same cluster must be in the same batch. During candidate list process, CDT also assigns a value of "N/A" to gateways that are not eligible for package installation. You should not change this value. Additionally, CDT assigns a value of "Installed" to gateways on which the requested package is already installed. This value should not be changed as well. Now that we are familiar with the configuration files, let's get back to Bob. He generates the candidate list by executing the generate command, using a filter handle to filter in only the 50 gateways currently installed with RAT.30. After this filtered list is created, Bob reviews it to finalize the list. He edits the list and divides the gateways into batches. Finally, he runs the deployment plan with the execute command. The installation starts. You can monitor the installation progress by watching the CDT_status.txt, which is updated every five seconds. Once the process is complete, an e-mail is sent to Bob, summarizing the installation. Now that we have seen how the CDT deployment process looks like, let's go over some use cases that may occur during the deployment. If there's a failure during an upgrade, it will revert automatically to the previous installed version. If any action in the deployment plan that is marked as "IsCritical" fails, the execution for that failed gateway stops. If you have set up your e-mail address in the Central Deployment tool file as Bob did, any failure during the deployment will trigger an e-mail message with the details and relevant logs. If the installation failed on some of the gateways but continued on the remaining gateways, CDT can try and continue the execution on the failed gateways and cluster members starting from the last failed stage. In regards to clusters, if an upgrade of a cluster member fails during the execution, the execution for the cluster will stop and the remaining members will not be upgraded. If an upgrade of the first member succeeded, but the upgrade of the second member failed, the first member will not be reverted to the previously installed version. Speaking of issues that may arise during the deployment, let's briefly touch upon the log files generated by CDT. All logs collected from the target machines and logs created by CDT are saved in one centralized location on the management server with the following path and format. For further read on troubleshooting CDT issues, please refer to the troubleshooting section of sk111158, which you have, of course, bookmarked by now. In this last section of the lesson, we're going to cover a different use of CDT called RMA Mode. This functionality is used to backup and restore gateway software and configuration information. This can be useful when you need to reconfigure a replacement to a malfunctioning gateway. Let's get back to Bob and examine his use of RMA. Being the responsible administrator he is, Bob would like to periodically backup the configuration information of the gateways he manages on a regular basis. He first added the central deployment tool XML file, and specify the location of the packages and backup files under the repository element. Once this is defined, Bob can go ahead and perform backups. He would like to backup all remote machines connected to the management server. Therefore, he runs the animate backup all command. A few months later on a rainy day, Bob discovers a malfunctioning with one of the gateways he manages. Luckily, he has an up-to-date RMA backup. He would like to restore it onto a new machine with a clean install. Before restoring, he wants to verify the backup info of his gateway. He does this by executing the following command. Bob must copy the same major version and hotfixes found in the info command to the RMA Repository. The path to this repository has already been defined by Bob in the central deployment tool XML. Before executing the restore command, he makes sure there is no active GUI Client that is locking the management's database such as smart console. Then, he executes the restore command, making sure to list the appropriate package name to install and the path to the packages license. Note that gateway_name represents the backed up gateway to be restored onto the new machine. At the end of the process, Bob needs to install policy on the newly restored gateway and that's it. From setting up the RMA definitions to backing up gateway configuration information, to restoring a backup onto a new target. For further read on RMA mode prerequisites, check out the Central Deployment Tool Admin Guide. With that, our lesson comes to a close. You should now be able to describe when should CDT be used, describe the prerequisites for deploying with CDT, describe the process of deploying with CDT, use CDT to perform a common use case deployment, perform basic troubleshooting in the CDT deployment process and you should be able to use CDTs RMA mode. Thank you for taking this lesson, and I will see you in the next one.
