User scenario for operator-initiated changes

This topic describes a scenario in which the changes implemented by a BMC Server Automation operator are automatically recorded, tracked, and approved in BMC Remedy ITSM.

The topic includes the following sections:

Overview

When you select one of the execute options (Execute now, Execute against, and Execute against failed targets) for a job that requires BMC Remedy ITSM approval, the job is blocked until approval notification is received from BMC Remedy ITSM. The job displays a status of Waiting for Approval until the approval notification is received. When the approval is received, the job executes automatically (for Execute now ) or at the scheduled time (for scheduled jobs). 

The BMC Server Automation integration with BMC Remedy ITSM supports the following job types:

  • AIX patching Job
  • Agent Installer Job
  • BLPackage Deploy Job
  • Batch Job
  • File Deploy Job
  • Network Shell Script Job
  • Oracle Enterprise Linux Patching Job
  • Provision Job
  • Red Hat Linux Patching Job
  • Software Deploy Job
  • Solaris patching Job
  • SuSE Linux Patching Job
  • UCS Provision Job
  • Virtual Guest Job
  • Windows Patching Job
  • Workflow Job
    You enable job approval for these job types using the Configuration > Approval Configuration menu option.

In this scenario, an operator in the IT operations organization is using BMC Server Automation to implement changes on the data center servers. The operator creates the job, selects the Execute Now option, and specifies that the change should be approved in BMC Remedy ITSM by selecting an appropriate approval type.

After completing the job definition in the job wizard:

  • A BMC Remedy ITSM change and task ticket is created automatically
  • The job execution is blocked and displays Waiting for approval status

As soon as the corresponding change request in BMC Remedy ITSM has been approved and BMC Server Automation has been notified, the job is executed and the corresponding ticket in BMC Remedy ITSM is updated with the results. This workflow ensures that all server configuration changes are logged for tracking by the change manager.

Operator-initiated change scenario

As part of a regular maintenance schedule, the BMC Server Automation operator creates a File Deploy Job to deploy new configuration files to several target servers. Because the administrator has specified that File Deploy Jobs must be approved by BMC Remedy ITSM, the wizard displays the Approval Information window.

  • The operator chooses Remedy Manual Approval, accepts the defaults for Change type, Impact, and Risk Level, and enters a description of the change that will result from the execution of the job. For information about configuring job approvals, see Executing a job with BMC Remedy ITSM approval in the BMC Server Automation documentation.

  • The operator chooses to have a new change ticket opened for this job execution, and completes the job definition. BMC Server Automation schedules the job and requests that a new change request be created in BMC Remedy ITSM. The new change request is created using a specific change template and includes one task, even if multiple servers are used as targets. The change request ID and task ID are sent to the BMC Server Automation system and the values are attached to the job schedule. The servers that have been specified as targets are associated to the change and task requests as CIs.
  • The operator checks to see if the interaction with the change management system was successful by reviewing the job schedule log, which is displayed under the job until the job starts running. For information, see the Viewing job schedules page in the BMC Server Automation documentation.
  • Because the BMC Server Automation administrator had configured this particular type of change (File Deploy) to have automatic approval in BMC Remedy ITSM, no manual intervention is required for the job to approved and subsequently executed. 
  • The operator checks the status of the File Deploy Job and sees that it has been approved and executed. 

    Note

    If the change request in BMC Remedy ITSM is rejected or canceled, then the corresponding BMC Server Automation job schedule remains in the Waiting for approval state (shown in the Tasks in Progress pane) the change request might be re-opened and moved into pre-approved state at a later time. If the change request remains in a Rejected or Canceled state after the job schedule expires, the job schedule is automatically deleted in BMC Server Automation. If a job in Waiting for Approval status is canceled (for example, due to time-out), the BMC Remedy ITSM task associated with the change request is automatically closed.

  • After the BMC Server Automation job execution completes successfully, the BMC Remedy ITSM user opens the change ticket to review the following items:
    • Status of task (Completed)
    • Status of change record - determined by BMC Remedy business logic
    • The actual start and end Date of the Change
    • Review which servers were updated

  • The BMC Remedy Service Desk user reviews the status of the change ticket and the task ticket, noting that the job succeeded and the change and task tickets have been closed. By reviewing the Dates tab of the task ticket, the operator can review the details of when the job was executed.

 

  • The BMC Remedy Service Desk user can also perform the following tasks:
    • From the General tab of the task ticket, the BMC Remedy Service Desk user can click Launchto display the BMC Server Automation Console, where the user can review the job details to verify the change actions.

      Note

      To be able to launch the BMC Server Automation Console from the task ticket, the BMC Server Automation Console must be installed on the same system where the user is running BMC Remedy ITSM Service Desk.

    • If there were failures in all or some of the targets, the user can review the status of the change and task records to review the status of the task (which would display as failed), the status of the change request, and which servers were updated and which were not updated, resulting in the failure (in the WorkInfo note).

Note: For more information about using the change management console, see Using the Change Management Console and the Change form.

Where to go from here

Troubleshooting continuous compliance for servers issues

Was this page helpful? Yes No Submitting... Thank you

Comments