Understanding Deployment
A deployment job defines how configuration changes are sent to devices. In a deployment job, you can define several parameters, such as the devices to which you want to deploy configurations and the method used to deploy configurations to devices. You can also create deployment schedules to automatically spawn deployment jobs at regular intervals.
The following topics will help you better understand and use deployment jobs:
Overview of the Deployment Process
Broadly speaking, deployment is a three-step process, as described in the following table.
Steps |
Deployment Steps |
---|---|
Step 1 |
Security Manager obtains the current configuration for the device and compares it to the latest saved policies for the device in Security Manager. What Security Manager considers to be the current configuration depends on the type of device, the deployment method, and the settings for deployment preferences. These are the possible sources and the conditions under which they are used:
The running configuration is used when deploying to the device unless the deployment method is AUS, TMS, or CNS. You can force Security Manager to use Configuration Archive by selecting When Deploying to Device Get Reference Config from: Config Archive as the deployment preference (select , then select Deployment).
The factory default configuration is used with PIX or ASA devices if you use the AUS deployment method. It is used for deployment and for configuration preview. |
Step 2 |
Security Manager builds a delta configuration that contains the commands needed to update the device configuration to make it consistent with the assigned policies. It also builds a full device configuration. |
Step 3 |
If you are deploying to the device, Security Manager deploys either the delta configuration or the full configuration, depending on which deployment method you use. If you are deploying to file, Security Manager creates two files: device_name _delta.cfg for the delta configuration, and device_name _full.cfg for the full configuration. In both cases, the configurations are also added to Configuration Archive. These are the actions based on deployment method:
|
During deployment, if Security Manager determines that the configuration on the device differs from the last-deployed configuration, Security Manager overwrites the changes by default. You can control this behavior using the deployment preferences; select Deployment, and look for the When Out of Band Changes Detected setting. You can also control this for a specific deployment job by editing the deployment method for the job.
, then selectIf you make changes to the device configuration outside of Security Manager, you have two choices for bringing those changes into Security Manager:
-
You can rediscover policies on the device, in which case all policies for the device become local policies, and any assignments of shared policies to the device are removed.
-
You can make the required changes in Security Manager and redeploy them to the device. During deployment, do not select the option to force an error if out-of-band changes are found on the device. This is the recommended approach.
For more information on how out-of-band changes affect deployment, see Understanding How Out-of-Band Changes are Handled.
After configurations are deployed, you should make changes only through Security Manager for configurations that Security Manager controls. This varies based on operating system. For IPS devices, Security Manager controls the entire configuration. For IOS, ASA, PIX, and FWSM devices, you have more control over which aspects of the device configuration Security Manager controls. If you do not create policies for a feature in Security Manager, such as routing policies, Security Manager does not control those features on the device. If you do create policies for these features, Security Manager overwrites the settings on the device with the settings you defined in Security Manager. Through administration settings, you can control the types of policies that will be available for these devices, thereby preventing Security Manager from displaying or changing policies for these features. To see the available features and control whether they are available for management in Security Manager, select Policy Management. Security Manager does manage VPN-related policies.
, then selectRelated Topics
Deployment in Non-Workflow Mode
These topics help you understand deployment in non-Workflow mode:
Deployment Task Flow in Non-Workflow Mode
The deployment task flow in non-Workflow mode consists of three simple steps:
-
Create the job: A deployment job is created for you when you do one of the following:
-
Click the Submit and Deploy Changes button on the main toolbar, or select .
-
Note |
These options are not available when Ticket Management is enabled. |
-
Select
. -
Select Deploy.
and click
-
Define the job: You specify parameters, such as the devices to which you want to deploy the configurations and whether you want to deploy directly to the devices or to a file.
During this step, you can also preview configurations and compare them to the previously deployed configurations or the configuration currently running on the device.
Note
Devices selected for one job cannot be included in any other job. This measure ensures that the order in which policies are deployed is correct. However, you can include devices that are specified in deployment schedules.
-
Deploy the job: Deploying the job sends the generated CLI to devices, either directly or through an intermediary transport server (such as AUS, CNS, or TMS) or to output files. You select the destination (device or file) when defining a job. The transport server is specified in the device properties. For more details about defining deployment methods and transport servers, see Understanding Deployment Methods.
Job States in Non-Workflow Mode
In non-Workflow mode, the Status column on the Deployment Manager window lists the state of each job. The following table lists and describes all possible job states in non-Workflow mode. For more details, see Deployment Manager Window.
State |
Description |
---|---|
Deployed |
Configurations for all the devices in the job were successfully deployed to the devices or to configuration files. Devices in the job can now be included in another job. |
Deploying |
Configurations generated for the job are being deployed to the devices or to a directory on the Security Manager server. You can monitor the job progress in the Deployment Manager window if the Deployment Status window is not already open. |
Aborted |
The job was manually halted. Devices in the job can now be included in another job. |
Failed |
The deployment to one or more devices in the job failed. Devices in the job can now be included in another job. |
Rolling Back |
Security Manager is in the process of reverting to and deploying previous configurations for the devices within the deployment job. You can abort a job that is in the Rolling Back state. |
Rolled Back |
Security Manager has successfully reverted to and deployed previous configurations for the devices within the deployment job. |
Deployment in Workflow Mode
These topics help you understand deployment in Workflow mode:
Deployment Task Flow in Workflow Mode
The following is a typical task flow in Workflow mode (see Figure 1):
-
Create the job: Before you deploy configurations to your devices, you must create a deployment job.
-
Define the job: When you create a job, you specify parameters, such as the devices to which you want to deploy the configurations, whether you want to deploy directly to the devices or to a file, and when you want the job to take place.
-
Submit the job: In some organizations, before jobs can be deployed, they must be approved by a separate user with the appropriate permissions. In this case, Workflow mode is enabled with a deployment job approver, and you must submit the job to this user for review. The user reviews the job and either approves or rejects it.
-
Approve or reject the job: If you are working in Workflow mode with a deployment job approver, the approver reviews it, and can then either approve or reject the job. If the job is approved, the submitter can then deploy the job. If the job is rejected, the submitter can discard the job and start over or modify the job and resubmit it.
If you are working in workflow mode without an approver, you can approve the job yourself.
-
Deploy the job: Deploying the job sends the generated CLI to either devices, intermediary transport servers (such as AUS, CNS, or TMS), or files. You select the destination (device or file) when defining the job. The transport server is specified in the device properties. For more details about defining deployment methods and transport servers, see Understanding Deployment Methods.
Job States in Workflow Mode
In Workflow mode, the Status column in the Deployment Manager window lists the state of each job. The following table lists and describes all possible job states. For more details about the Deployment Manager window, see Deployment Manager Window.
State |
Description |
---|---|
Edit |
The job was created, but it is not currently being edited. The job can be opened, approved (in auto-approval mode), or discarded while it is in the Edit state. |
Edit-In Use |
The job is open for editing. The job can be closed, approved, discarded, or submitted while it is in the Edit Open state. |
Submitted |
The job was submitted for review. It can be viewed but not edited while it is in the Submitted state. The job can be opened for viewing, discarded, rejected, or approved while it is in the Submitted state. This state occurs only when Workflow mode is enabled with deployment job approval required. |
Approved |
The job was approved and is ready to be deployed. The job can be deployed while it is in the Approved state. |
Rejected |
The job was rejected. You can open the job for editing or discard the job while it is in the Rejected state. This state occurs only when Workflow mode is enabled with deployment job approval required. |
Discarded |
The job was discarded. No further changes to the job are not allowed. The job remains in the Deployment table showing a Discarded state until it is purged from the system. Devices in the job can be included in another job. |
Deployed |
Configurations for all the devices in the job were successfully deployed to the devices or to configuration files. Devices in the job can now be included in another job. |
Deploying |
Configurations generated for the job are being deployed to the devices or to a directory on the Security Manager server. You can monitor the job progress in the Deployment Manager window. |
Aborted |
The job was manually halted. Devices in the job can now be included in another job. |
Failed |
The deployment to one or more devices in the job failed. Devices in the job can now be included in another job. |
Scheduled to run at [date] |
The job is scheduled to be deployed at the date and time specified. |
Rolling Back |
Security Manager is in the process of reverting to and deploying previous configurations for the devices within the deployment job. You can abort a job that is in the Rolling Back state. |
Rolled Back |
Security Manager has successfully reverted to and deployed previous configurations for the devices within the deployment job. |
Deployment Job Approval
By default, Security Manager operates in non-Workflow mode; deployment jobs are handled behind the scenes and the user does not need to be aware of jobs or their approval. When using Workflow mode, you can choose to operate with or without a deployment job approver.
If you choose to operate without an approver, you have the permissions to define and approve jobs.
If your organization requires a different person with higher permissions to approve deployment of new or changed configurations to devices, use Workflow mode with a deployment job approver. When using Workflow mode with a deployment job approver, the job must be reviewed by a person with the appropriate permissions to approve or reject the job. This approval process helps to ensure that no inappropriate configurations reach the network devices and that deployment jobs are scheduled effectively.
Note |
You enable and disable deployment job approval under Tools > Security Manager Administration > Workflow. For more information, see Workflow Page. |
Deployment Jobs and Multiple Users
Only one user can define or change parameters or devices within an individual deployment job at one time. However, multiple users can work on the same deployment job in sequence: if a deployment job is closed, another user can open it and make changes to it. Multiple users can work in parallel on different deployment jobs.
Including Devices in Deployment Jobs or Schedules
When you create a deployment job or schedule, you select the devices to include in it. The inclusion of a device influences how the device can be used in other jobs or schedules. When you select a device for a specific job, it cannot be selected for any other job until the original job is deployed, rejected (in Workflow mode), discarded, or aborted. This mechanism prevents two or more people from deploying changes to the same device at the same time and ensures that policies are deployed to devices in the correct order.
However, a device can be part of a deployment schedule and still be selected for specific deployment jobs. While a deployment job is running, the device is locked. The device cannot be included in other jobs while the deployment job is running.
When you create a deployment job, Security Manager displays the devices on which policy changes were made but were not yet deployed. You can deploy to these devices, and you can select additional devices for the job. Although you can add as many devices to a deployment job as you desire (there is no limitation), as a practical matter, you should limit the number of devices per job. The deployment job might fail if you select a large number of devices or several devices that have large configuration files. If you encounter deployment failures, resubmit the job with fewer devices selected.
For VPNs, Security Manager must generate commands for devices that are affected by the policies defined for the devices you select for the job. So, if you select a device that is part of a VPN, Security Manager adds the other relevant devices to the job. For example, if you define a tunnel policy on a spoke, and you select the spoke for the job, Security Manager adds the spoke’s assigned hub to the job. During job generation, Security Manager generates commands for both peers so that the VPN configuration is complete and the tunnel can be established. If you deselect one of the devices associated with the VPN, Security Manager warns that removing the device might result in the VPN not functioning property.
Understanding Deployment Methods
Security Manager lets you deploy configurations to devices using three main methods: deploying directly to the device, deploying to a configuration file (which you must then manually apply to the device), and deploying to an intermediate server (which is treated like deploying directly to the device). The system default deployment method is to deploy directly to the device.
When you add devices to Security Manager, you select the deployment method to be used by that device. This determines the method used for deploying to the device (instead of a file). When you create a deployment job, an additional deployment method default applies to the job as a whole, which determines whether deployment creates configuration files or whether it sends the configuration to the device using the method selected for the device. You control this default in the administration settings (select Deployment; see Deployment Page). When you create a deployment job, you can also change whether the deployment is to a file or to the device for each device by clicking Edit Deploy Method in the Create Job window. If you are using non-Workflow mode, see Deploying Configurations in Non-Workflow Mode. If you are using Workflow mode, see Creating and Editing Deployment Jobs.
, then selectThe method you choose to use depends on the processes and procedures of your organization and the transport protocols supported by a particular type of device. If you are using Configuration Engine (CNS) or Auto Update Server (AUS), use those deployment methods. You must use one of these for devices that use dynamic IP addresses. Otherwise, for devices with static IP addresses, use SSL (HTTPS) for IOS, PIX, ASA, IPS, and standalone FWSM devices, and SSH for FWSM through the Catalyst chassis. If you are using a Token Management Server (TMS) for some devices, you can also use that method with Security Manager.
The following topics describe the deployment methods in more detail:
Deploying Directly to a Device
If you choose to deploy directly to a device, Security Manager uses the transport protocol defined in the device properties for the device (right click the device, select Device Properties, and click General). The protocol is typically the default protocol defined in the Device Communication page in the Security Manager Administration settings (see Device Communication Page). Table 1 lists some of the default transport protocol settings.
When you select Device as the deployment method, deployment is affected if you configure a transport server for the device, such as an AUS or Configuration Engine. When using an intermediate transport server, configuration deployment goes through the server. For more information on using an intermediate server, see Deploying to a Device through an Intermediate Server.
Deployment can also be affected if you made out-of-band changes to the device since the last deployment. For more information, see Understanding How Out-of-Band Changes are Handled.
During deployment, Security Manager sends only the changes made since the last deployment to the device.
Caution |
You must configure at least one policy on a device before deploying to that device. If you deploy to a device without assigning at least one policy, the device’s current configuration is overwritten with a blank configuration. |
Device Type |
Transport Protocol |
Description |
---|---|---|
ASA, IOS 12.3 and later routers, FWSM, PIX Firewall, IPS sensors |
SSL (HTTPS) (Default) |
Security Manager deploys the configuration to the device using the Secure Socket Layer (SSL) protocol, otherwise known as HTTPS. With this protocol, Security Manager encrypts the configuration file and sends it to the device. |
Catalyst 6500/7600 and other Catalyst switches |
SSH |
Security Manager deploys the configuration to the device using a Secure Shell (SSH). This provides strong authentication and secure communications over insecure channels. Security Manager supports both SSHv1.5 and SSHv2. Once connected to the device, Security Manager determines which version to use and downloads using that version. |
IOS 12.2 and 12.1 routers |
Telnet |
Security Manager deploys the configuration to the device using the Telnet protocol. |
Related Topics
Deploying to a Device through an Intermediate Server
Deploying configurations through an intermediate server, such as an Auto Update Server (AUS), Cisco Networking Services (CNS) Configuration Engine, or Token Management Server (TMS), is a version of deploying directly to device. When selecting the deployment method, select Device. Security Manager sends the configuration updates to the intermediate server, where the device retrieves it (for AUS and CNS), or where you can download it to an eToken (for TMS).
You must use an intermediate server if you are using dynamic IP addresses for your device interfaces (that is, the IP addresses are provided by a DHCP server). You can also use them with static IP addresses. However, you cannot use Configuration Engine to manage IOS devices with dynamic IP addresses if you configure features that use interactive CLI commands. The following features are affected:
-
Certificate Enrollment:
-
crypto pki trustpoint
-
crypto isakmp client configuration group
-
crypto key generate rsa
-
-
IPS signature configuration (ip ips signature-category)
-
IP Authproxy Banner (ip auth-proxy-banner)
-
Catalyst device interface switchport (interface switchport)
Security Manager uses an intermediate server if you have configured the device to use one. The following topics describe the required configuration steps when using an intermediate server:
Deployment can be affected if you made out-of-band changes to the device since the last deployment. For more information, see Understanding How Out-of-Band Changes are Handled.
During deployment, Security Manager sends configuration changes based on the type of server:
-
Auto Update Server (standalone or running on Configuration Engine) for PIX and ASA devices—Security Manager sends the full configuration to Auto Update Server, where the device retrieves it. The delta configuration is not sent.
-
Configuration Engine for IOS devices—Security Manager sends the delta configuration to Configuration Engine, where the device retrieves it.
-
TMS—Security Manager sends the delta configuration to the TMS server, from which it can be downloaded to an eToken to be loaded onto the device.
Related Topics
Deploying to a File
If you choose to deploy configurations to configuration files, Security Manager creates two files: device_name _delta.cfg for the delta configuration, and device_name _full.cfg for the full configuration. If the files are created by a job that was generated from a deployment schedule, the name includes a time stamp. Configuration files are in TFTP format so that you can upload them to your devices using TFTP.
Tip |
You cannot deploy configurations to file for IPS devices. |
If you deploy to file, you are responsible for transferring the configurations to your devices. Security Manager assumes that you have done this, so the next time you deploy to the same devices, the generated incremental commands are based on the configurations from the previous deployment. If for some reason the last change was not applied to the device, the new delta configuration will not bring the device configuration up to the one reflected in Security Manager.
Caution |
Although Security Manager in one sense assumes that you applied the delta configuration, in another sense, it assumes that it cannot know if the delta was deployed. Thus, Security Manager maintains an internal view of the configuration based on the last deployment made directly to the device. So, when you apply the delta, those delta changes will be considered out-of-band changes. On next deployment to the device, your out-of-band change setting might cancel the deployment. If you mix deployments to file with deployments to device, you should rediscover policies after applying file deployments to the device. For more information, see Understanding How Out-of-Band Changes are Handled. |
To set a default directory for file deployments, select Deployment (see Deployment Page). If you select File for the default deployment method, you also select the default directory. When you create a deployment job, you can change this directory for that job.
, then selectDeploying configurations to a file is useful when the devices are not yet in place in your network (known as green field deployment), if you have your own mechanisms in place to transfer configurations to your devices, or if you want to delay deployment. When deploying to a file, the deployment job might fail if you select a large number of devices or several devices that have large configuration files. If you encounter deployment failures, resubmit the job with fewer devices selected.
Tip |
Do not use commands that require interaction with the device during deployment when deploying to file. We recommend previewing your configuration before deployment to make sure there are no such commands in the file. For more information, see Previewing Configurations. |
Understanding How Out-of-Band Changes are Handled
Security Manager considers an out-of-band change to be any change made to a device manually or outside of Security Manager control, for example, by logging into the device directly and entering configuration commands through the CLI. Paradoxically, this includes the application of delta changes that Security Manager creates when you deploy configurations to file rather than to the device.
If you are deploying to the device (rather than to file), and the deploy to device method is configured to compare the new configuration to the current configuration on the device, you can specify how to handle out-of-band changes when they are detected using the Out of Band Change Behavior setting. The setting does not apply when deploying to file.
This setting is ignored if you are comparing the new device configuration with the latest version stored in the Security Manager Configuration Archive. The default way to handle out-of-band changes, is set in Tools > Security Manager Administration > Deployment; for more information see Deployment Page. Look for the Deploy to Device Reference Configuration and When Out of Band Changes Detected settings.
Tip |
When the deployment method is configured to use the reference configuration in Configuration Archive, out-of-band changes are always removed. This is equivalent to selecting Do not check for changes. |
Your options for handling out-of-band changes are:
-
Overwrite changes and show warning—When configurations are deployed, Security Manager uploads the device’s current configuration and compares it against the configuration it has in its database. If changes were made to the device manually, Security Manager continues with the deployment and displays a warning notifying you of this action. Out-of-band changes are removed from the device.
-
Cancel deployment—When configurations are deployed, Security Manager uploads the device’s current configuration and compares it against the configuration it has in its database. If changes were made to the device manually, Security Manager cancels the deployment and displays a warning notifying you of this action. You must either manually remove the out-of-band changes, or configure the same settings in Security Manager, before you can deploy configuration changes to the device.
-
Do not check for changes—Security Manager does not check for changes and deploys the changes to the device. No warnings are issued, and any out-of-band changes are removed from the device configuration.
Before you deploy configurations, you might want to detect whether there are out of band changes on a device and analyze whether you want to recreate those changes in Security Manager policies, or allow Security Manager to overwrite the changes. For more information, see Detecting and Analyzing Out of Band Changes.
Related Topics
Handling Device OS Version Mismatches
Before deploying a changed configuration file directly to a device, Security Manager normally uploads the current running configuration file from the device and checks the OS version running on the device with the OS version stored in the Security Manager database (you can configure it so that the archived configuration is used instead of the configuration from the device). Security Manager takes action depending on whether the OS versions match or differ from each other.
In some cases, Security Manager deploys the configuration and issues a warning, but in other cases, Security Manager cannot deploy the configuration. Security Manager deploys the configuration when:
-
The device has a newer minor version, for example, ASA 8.1(2) instead of the 8.1(1), indicated in Security Manager.
-
The device has a down-level minor version, for example, ASA 8.1(1) instead of 8.1(2).
Security Manager does not deploy the configuration when the device is running a new major version of the OS (for example, ASA 8.0 instead of the 7.2 indicated in Security Manager) or if the device is running a down-level major version (7.2 instead of 8.0).
The following table lists the possible actions Security Manager takes depending on the whether the OS versions match or differ from each other. The table uses the ASA device as an example; however, the actions apply to all supported device types.
Scenario |
OS Version in Security Manager Database |
OS Version On Device |
OS Version Used In Deployment |
Action |
---|---|---|---|---|
Versions match |
ASA 8.2(1) |
ASA 8.2(1) |
ASA 8.2(1) |
Deployment proceeds with no warnings. |
Device has newer minor OS version. |
ASA 8.1(1) |
ASA 8.1(2) |
ASA 8.1(2) |
Security Manager warns that it has detected a different OS version on the device than the one in the Security Manager database. Security Manager generates the CLI based on the OS version running on the device. |
Device has newer minor OS version, one that is not directly supported by Security Manager. |
ASA 8.0(2) |
ASA 8.0(4) |
ASA 8.0(3) |
Security Manager warns that it has detected a different OS version on the device than the one in the Security Manager database. Security Manager generates the CLI based on the OS version that it supports to which the running OS version is downward-compatible. |
Device has a new major OS version. |
ASA 7.2(4) |
ASA 8.2(1) |
None. Deployment fails. |
Security Manager reports an error indicating that it has detected a different OS version on the device than the one in the Security Manager database. Security Manager cannot proceed until you correct this mismatch. Remove the device from the inventory, add it again, and discover the device policies. |
Device has an older minor OS version. |
ASA 8.1(2) |
ASA 8.1(1) |
ASA 8.1(1) |
Security Manager warns that it has detected a different OS version on the device than the one in the Security Manager database. Security Manager generates the CLI based on the OS version running on the device. |
Device has an older major OS version |
ASA 8.2(1) |
ASA 7.2(4) |
None. Deployment fails. |
Security Manager reports an error indicating that it has detected a different OS version on the device than the one in the Security Manager database. Security Manager cannot proceed until you correct this mismatch. Remove the device from the inventory, add it again, and discover the device policies. |