The General panel lets you provide information that identifies a Deploy Job.
Field definitions
| |
| Optional descriptive text. |
| Folder in which to store the object. |
Number of targets to process in parallel | Choose one of the following options: - Unlimited — Simultaneously runs the job on as many servers as possible. Application Server settings control the number of targets the job can access.
- Limited — Specifies the maximum number of targets on which the job can run simultaneously. Limiting the number of targets is useful when a job might temporarily disrupt the functionality of a target server, and you want to limit that disruption to a small fraction of your managed servers.
If you want the job processed serially at the target servers, set this value to 1. Note, however, that although this is the best approach for achieving serial processing, it does not always guarantee full serial processing at all targets; the first two or three targets might still run in parallel.
|
| Select if this job should always execute as if your current role and user are scheduling the job. After you click this option, the job definition shows the role:user combination under which the job executes. |
| Remove an existing execution override. |
Change Automation Options:
Change Task Template Enabled | Publish the job as a task template in BMC Remedy ITSM, to support the Change-Initiated-Job (CIJ) use case of BMC Change Automation for execution of the job without the involvement of the Operations team. This option is available if this job type was selected to support the creation of ITSM task templates and a connection to BMC Remedy ITSM was set up. For more information, see Enabling-Change-Automation-for-TrueSight-Server-Automation-jobs. |
Note
If you are running an advanced Deploy Job and you are executing Phases-of-a-Deploy-Job separately, the job uses the most recent override settings when each phase executes. For example, consider this scenario:
- UserA creates a Deploy Job with an execution override. In other words, the job should always run as UserA.
- UserB runs the Commit phase of the job using the job's override settings (that is, the job executes as UserA).
- UserA clears the execution override.
- UserB attempts to run an undo of the job. The job fails because there is no override set. The job attempted to run as UserB.
If the phases of a Deploy Job are run consecutively, changing override settings are not a problem. Thus, the issue is not a concern when you run:
- Basic Deploy Jobs. You cannot schedule phases separately for Basic Deploy Jobs.
- Advanced Deploy Jobs, if you have selected the Execute selected phases sequentially option (see Phase-scheduling-and-execution for information about that option).
Where to go from here
Deploy-Job-Package (for a BLPackage Deploy Job)
Deploy-Job-Software (for a Software Deploy Job)