Out of the box behvaiour
To understand the possibilities in the behavior of Alert and Incident handling by Cookdown Alert Sync we first need to understand the high-level dataflow between SCOM and ServiceNow:
- SCOM Alert Raised
- SCOM Alert Synced to ServiceNow and Alert Record created in ServiceNow
- ServiceNow Incident Created (if the Alert matches an Incident Creation Rule)
- ServiceNow Incident info synced to SCOM Alert. SCOM Alerts kept up to date with ServiceNow Incident updates (if Bidirectional Sync is enabled)
- ServiceNow Alert Record kept up to date with changes to SCOM Alert
- ServiceNow Incident is not resolved automatically when SCOM Alerts close (configurable)
- SCOM Alert is closed if ServiceNow Incident is Resolved (if the correct setting in SCOM is enabled)
- SCOM Monitors are reset (if the correct setting in SCOM is enabled)
Note that for this behavior, Incident 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:
- 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.
- 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 Incident Creation Rules). Alerts received can be seen in Cookdown Alert Sync > SCOM Alerts along with whether they have an incident created for them:
The following data is pushed to ServiceNow for each Alert:
- Alert attributes
- Alert ID
- Resolution State (both the name of each state and the underlying ID of the state)
- Repeat Count
- Whether the Alert is from a monitor or not
- Alert Last Modified date/time
- Side ID
- Time raised (date/time)
- Time Resolved (date/time)
- Alert Custom Fields 1-10
- Monitored Object (that generated the Alert) Attributes
- Monitored object display name
- Monitored object full name
- Monitored object path
- Monitored object name
- Principal name
- Netbios Computer Name
- Monitored object ID
- Whether the Monitored object is in maintenance mode or not
- Monitoring object parent Ids
- SCOM Monitoring Configuration (info on the SCOM Management Pack/workflow/management group that raised the alert)
- Management Pack Display Name
- Workflow Display Name
- Management Pack Name
- Workflow Name
- Management Group
The following additional data is also added to the Alert record data stored in ServiceNow
- Incident (that was created from the Alert) attributes
- Incident ID
- The Incident creation rule that resulted in the creation of the associated incident
- Alert Record data
- Alert Record created date/time (the "Created" field)
- Alert Record Updated date/time (the "Updated" field)
The following screenshots show this data in the products UI:
3. ServiceNow Incident Created
Once an Alert has been received from SCOM an Incident may be created depending on the Incident Creation Rules defined in ServiceNow.
The ServiceNow app ships with no incident 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 Incident Creation Rules.
The default behavior (if you use the criterion-based incident creation rules rather than scripts) results in Incidents with the following data:
- Assignment Group set to the value selected from the UI
- Short Description set to the SCOM Alert name
- Description set to the SCOM Alert's Description
- Configuration Item set to the value selected from the UI
- Caller ID set to "Cookdown Alert Sync"
If bidirectional sync is enabled, at the point an Incident has been created, the Alert that triggered it will also be updated with the following:
- Incident ID is pushed to SCOMs Ticket ID property. This is useful for the SCOM admin in understanding who is assigned to each Incident and where it is in its journey to resolution
- Assignment Group is stored in SCOMs "CustomField1"
- Business Service that the Incident is raised against is stored in SCOMs "CustomField2". What happens if the Incident is raised against a CI but hasn’t directly been mapped to a BS?
- Configuration Item that the associated Incident is raised against is stored in SCOMs "CustomField3"
- Incident State is stored in SCOMs "CustomField4"
4. Incident information synced with Alert in SCOM
Once an incident has been created from a SCOM Alert, if bidirectional sync is enabled the following pieces of info are synced to SCOM and are kept up to date if there are any changes in ServiceNow:
|Incident value||SCOM Alert field|
|Incident ID||Ticket ID|
|Assignment Group||Custom Field 1|
|Business Service||Custom Field 2|
|Configuration Item||Custom Field 3|
|Incident State||Custom Field 4|
If bidirectional sync is enabled the above fields will have their contents overwritten with values from the created Incident. If you do not want this to happen do not enable bi-directional sync or customize this behavior using the advanced scripting options. More info on scripting.
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 visible under Cookdown Alert Sync > 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's activity is updated to reflect the change. This behavior can be changed with the Incident Update script.
6. ServiceNow Incident is not Resolved
The default behavior is that Incidents are not auto resolved but this can be configured in the Incident Update script.
When each SCOM Alert is closed, it is possible to get Alert Sync to close the raised Incident too, this isn't always desired, some types of SCOM Alerts close themselves when they are resolved (EG CPU too high monitor Alerts will auto close when CPU dips below acceptable level). Some company's internal processes will be set up so this makes sense (where the SCOM team handles the Alerts and live in SCOM rather than in ServiceNow.
7.SCOM Alert is closed if ServiceNow Incident is Resolved
If the below setting is 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, 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 (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 below setting is 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 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" 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.