SCOM Administrative Tool Integration

Overview

Tool Integration sample is designed to highlight how one can integrate manually initiated tasks that are performed automatically from SCOM. This is another form of a “Run Book” scenario where procedures associated with performing an administrative task would normally be done manually, however Opalis allows these sorts of tasks to be run via workflow automation. There are numerous advantages to this approach:

1. Administrative tasks that are run through a standard interface require fewer access controls for an individual user. One only has to have credentials to SCOM rather than access to all the systems the automation interacts with.

2. Tasks run automatically produce a more standardized response. The “quality” of the task doesn’t depend on the skill level of the end user.

3. Tasks run automatically typically run faster than those performed manually.

4. Tasks run automatically via Opalis will be logged and have better governance in terms of tracking and auditing.

The sample highlights a few key features associated with Orchestration of such a process:

1. The workflow is meant to be called from a command line and integrated into SCOM in this fashion.

2. The results of the automation are stored via an “Information” event in SCOM. Once the task finishes, the alert is updated with the results of the automation contained within a custom field.

3. Validation of the reason for running the solution is built into the workflow. Certain tools might only be permitted to run under certain conditions. This type of a “gate” can be applied at the start of a workflow to guarantee a given tool is only run under specific circumstances.

Workflow Walk-Through

The workflow would provide a tool one could integrate into SCOM to free disk space on a server. It starts by creating a SCOM Information alert indicating that the action has started. It then validates that a low disk condition exists that would warrant the tool being run. This basically makes certain the condition for which the tool is designed has been satisfied (i.e. it is not possible to run the tool outside the permitted prerequisites, in this case a low disk space condition). Once the condition has been validated, an attempt is made to free up some disk space.

The results (successful or otherwise) are added to the SCOM alert in the form of an updated custom field. Note that even though the tool has run successfully, the alert isn’t marked as Resolved since we don’t want the user to lose track of the alert if they are watching it to see if the tool ran successfully.

Workflow Initiation

There are several ways one can initiate this workflow. Both are referenced in the Opalis product documentation. All methods push input parameters into the workflow via the Custom Start its beginning. In this sample, only one input parameter is used (“hostname”… the policy is hard-coded to the “C:\” drive).

Topics in the documentation one should review on programmatic workflow initiation would include:

1. **

   OIS5StartPolicy.exe – This is a command-line interface present on the Opalis Management Server. It allows one to start a workflow via the command-line. The workflow is specified by GUID . Note, there is a “search” feature in this CLI that lets one search for a GUID by name. Also, one can specify the input parameters; however take care to ensure that the parameters passed to the CLI are in the same order as they appear in the Custom Start. Finally, there is a “/wait” flag one can use if it is desired to have the command-line not return until the workflow has finished running. Not specifying this flag initiates the workflow and immediately returns (“launch and forget”). For this sample either mechanism would work well since once the workflow runs its status is reported to OM via updates to an Information alert.

2. Opalis Remote Trigger – This is an optional component which is covered in documentation that is referenced in the product manuals and also in documentation files in the Opalis install folder. The Remote Trigger provides a “Store” which buffers “events” (a request to run a workflow) and also a persistent service to “Forward” events to Opalis. Finally, there is a CLI that allows one to programmatically request a workflow to run with parameters. When the CLI is called the request is placed in the “Store” where it is eventually forward to Opalis via the “Forward” service. This has the advantage of being very robust (if Opalis can’t be reached the “Forward” service will keep trying to send the requests). The disadvantage is that one can’t wait for the workflow to finish. However, for this sample it’s not important that the command wait for the workflow to finish since once the workflow runs its status is reported to OM via updates to an Information alert. Note: The Remote Trigger calls the Opalis Operator Console Web Service and hence this service must be running and also one must have a valid user ID/password to connect as well as an Opalis profile that permits this ID to view and run the policy being launched.

3. Opalis Web Service – This is more a programmatic interface; however it can be used to launch a workflow, check status, etc. The web service is documented in the Users Guide. Also, there is an Authoring Example available that covers calling the Opalis Web Service (albeit calling the workflow from within Opalis, but it could provide a deeper understanding of the methods and their arguments).

Share this post :