Out of the Box Behavior

To understand the possibilities in the behavior of Alert and Incident handling by Cookdown Alert Sync we first need to understand the high-level data-flow between SCOM and ServiceNow:

1. SCOM Alert Raised

2. SCOM Alert Synced to ServiceNow and Alert Record created in ServiceNow

3. ServiceNow Incident/Task Created (if the Alert matches a Creation Rule)

4. ServiceNow Incident/Task info synced to SCOM Alert. SCOM Alerts kept up to date with ServiceNow Incident/Task updates (if Bidirectional Sync is enabled)

5. ServiceNow Alert Record kept up to date with changes to SCOM Alert

6. ServiceNow Incident/Task is not resolved automatically when SCOM Alerts close (configurable)

7. SCOM Alert is closed if ServiceNow Incident is Resolved (if the correct setting in SCOM is enabled)

8. SCOM Monitors are reset (if the correct setting in SCOM is enabled)

Note that for this behavior, Creation Rules (non-script based) + Bidirectional Sync + SCOM Alert Closure configuration needs to be configured.

1. SCOM Alert Raised

SCOM monitors IT operations against workflows the define desired behavior and raises Alerts when the desired behavior is not happening. More info on what SCOM is and how it works here.

2. SCOM Alert Record created in ServiceNow

Alerts get sent to ServiceNow from SCOM based on a few things:

1. Your SCOM override tuning - Alert Sync can be sent to push all Alerts it generates to ServiceNow. If you find too many alerts are being sent to ServiceNow, start by looking at the SCOM overrides you have in effect and tune SCOM to prevent it generating Alerts that are not useful. You can do this manually by following the SCOM documentation or tune what alerts get generated with Easy Tune.

2. Your Alert Sync internal Connector settings - the internal connector settings govern what data relating to Alerts is sent from SCOM. You can choose to send alerts based on SCOM group, target, or based on specific criteria (such as an Alerts severity, category or state). See the setup guide for more on how the Internal Connector can be set up.

All Alerts sent from SCOM will be received by ServiceNow but not all will have an Incident raised for it (this is governed by the Creation Rules). Alerts received can be seen in Cookdown SCOM Connector > SCOM Alerts along with whether they have an incident created for them:

For an overview of what is between SCOM and ServiceNow please see Data Synced Between Scom and Servicenow.

3. ServiceNow Incident/Task Created

Once an Alert has been received from SCOM an Incident may be created depending on the Creation Rules defined in ServiceNow.

The ServiceNow app ships with no Creation Rules as every company's needs are different, however, there are saved settings in the installation guide that create an incident for all received incidents. See this article for more info on how to set up Creation Rules.

The default behavior (if you use the criterion-based incident creation rules rather than scripts) results in Incidents/Tasks with the following data:

1. Assignment Group set to the value selected from the UI

2. Short Description set to the SCOM Alert name

3. Description set to the SCOM Alert's Description

4. Configuration Item set to the value selected from the UI

5. Caller ID set to "Cookdown Alert Sync"

4. Incident information synced with Alert in SCOM

Once an incident has been created from a SCOM Alert, if Bidirectional Dync is enabled the following pieces of info are synced to SCOM. Any changes made in ServiceNow later are synced back to SCOM kept up to date:

5. ServiceNow Alert Record kept up to date with changes to SCOM Alert

If SCOM Alerts change, data is kept up to date on the Alert Record created in Service Now (the Alert Record is the item created in ServiceNow under Cookdown SCOM Connector > SCOM Alerts).

All data synced from SCOM when the Alert Record was initially created is kept up to date. The list of data synced is here.

By default, when an Alert is closed, the Incident or Task's activity is updated to reflect the change. This behavior can be changed with our Advanced Incident / Task Updates feature.

6. ServiceNow Incident/Task is not Resolved

The default behavior is that Incidents/Tasks are not auto resolved but this can be configured using our Advanced Update features.

When each SCOM Alert is closed, it is possible to get Alert Sync to close the raised Incident/Tasks too. But this isn't always desired, and some types of SCOM Alerts close themselves when they are resolved (EG CPU too high monitor Alerts will auto close when CPU returns to an acceptable level). Some company's internal processes will be set up so this makes sense (where the monitoring team handles the Alerts and operate in SCOM rather than in ServiceNow.

7. SCOM Alert is closed if ServiceNow Incident/Task is Resolved

If the following setting is checked in the Alert Sync settings in SCOM (navigate to the Administration pane, ServiceNow Connector - Cookdown, Alerts) then when an Incident or Task is resolved in ServiceNow, the SCOM Alert that created it is Closed.

By default this checkbox is unchecked but ServiceNow will always send the close request for SCOM Alerts to SCOM. Note that to enable this functionality, Bidirectional Sync must also be enabled (as this is a dependency).

If the ServiceNow Incident is re-opened the SCOM Alert will remain closed, but the SCOM Alert Record created in ServiceNow will remain linked to the Incident so you can see the source Alert and its properties.

8. SCOM Monitors are reset

If the following settings are checked in the Cookdown Alert Sync Management Pack settings in SCOM (navigate to the Administration pane, ServiceNow Connector - Cookdown, Alerts) then when an incident is Resolved in ServiceNow and the workflow that generated the Alert in SCOM was a Monitor, the SCOM Alert that generated it has its monitor reset (if this is not done, the Monitor will never fail again and not generate future Alerts).

By default these checkboxes are unchecked but ServiceNow will always send the close request for SCOM Alerts to SCOM. Note that to enable this functionality, "Bidirectional Sync" and "Allow Alerts to be closed by ServiceNow" must also be enabled (these are dependencies).

If the ServiceNow Incident is re-opened the SCOM Alert will remain closed (unless something SCOM side has happened to re-open it), but the SCOM Alert Record created in ServiceNow will remain linked to the Incident so you can see the source Alert and its properties.