Out-of-the-box Behavior in Connection Center

To understand the possibilities available in Connection Center, we first need to understand the high-level data flow in an uncustomized configuration.

Outbound Data Flow

1. SCOM Alert Raised

SCOM monitors IT operations against workflows that define desired state. These workflows raise Alerts when it has been detected that the system is not in the desired state. More info on what SCOM is and how it works here.

2. SCOM Alert Matched to Outbound Destination(s)

Each outbound destination comes with several options available to govern how it behaves. At its most basic you can simply send all alerts generated to your target destination. In this scenario, you’ll find that Connection Center is driven more by your overrides and the tuning of your alerts. If you find too many alerts are being sent to your target destination you should investigate the SCOM overrides that you have in effect and look at tuning SCOM to prevent it from generating unactionable alerts.

The outbound destinations can also be set up with specific scopes and criteria allowing you to send alerts based on membership of SCOM groups, an alert's severity, category, state, amongst others.

3. SCOM Alert Synced to Destination(s)

SCOM then syncs the alert to the target destination. If you would like to see a list of what is transferred between SCOM and the target system please see check the out-of-the-box behavior of each target system using the following links:

• Out-of-the-box Behavior in ServiceNow
• Out-of-the-box Behavior in Cherwell

4. The Destination Takes Action (where available)

Each destination type behaves differently and it would not be effective to list all of the different possibilities here. However, you can check out the out-of-the-box behavior of each target system using the following links:

• Out-of-the-box Behavior in ServiceNow
• Out-of-the-box Behavior in Cherwell

5. The Destination Is Kept up to Date with Any Changes to the SCOM Alert

If SCOM alerts change, data is kept up to date in the destination. In the case of a connector-based destination, the destination is kept up to date for the life of the alert. In the case of a subscription-based destination, the destination is kept up to date as long as the alert matches the criteria.

6. If a SCOM Alert Closes the Destination Record Is Not Resolved (Where Available)

The default behavior in ITSM tools is that tickets/incidents/tasks are not resolved when an alert is closed. It’s not always desirable to close off a raised record in your ITSM tool so by default we do not do this. Depending on the add-on in question you might be able to customize this.

Back to top

Inbound Data Flow

1. SCOM Alert Updates Checks for Changes in the Target Add-on

SCOM reaches out to each configured Alert Update source to check for updates that need to be synced back and added to the SCOM alert.

2. Any Configured Details Are Recorded Against the Relevant SCOM Alert

The details from the update are written back into the related SCOM alert.

Each destination type behaves slightly differently and it would not be effective to list all the differences here. However, you can check out the out-of-the-box behavior of each target system using the following links:

• Out-of-the-box Behavior in ServiceNow
• Out-of-the-box Behavior in Cherwell

3. (If Enabled) When a Linked Task/Incident Is Resolved Then the SCOM Alert Is Resolved/Closed

By default, SCOM Alert updates do nothing with the SCOM alert when the linked task/incident is resolved other than sync back the fact that this has occurred. However, It is a simple checkbox to enable the closing of alerts when the linked ticket is resolved/closed in supported add-ons.

4. (If enabled) SCOM Monitors Are Reset

Alerts that are linked to monitors have additional options available when the linked task/incident is resolved through Alert Updates. If enabled the unit monitor linked to the alert will be reset to resolve the SCOM alert. If the Alert is linked to an aggregate or dependency monitor you can also enable the setting that recursively resets these monitors. If the linked incident/task is re-opened the SCOM alert will remain closed (unless something SCOM side has happened to re-open it), but the SCOM Alert Record will remain linked to the task/incident so that you can continue to see the source alert and its properties.

Back to top

Maintenance Data Flow

1. SCOM Inbound Maintenance Checks for Current Maintenance Records

SCOM reaches out to each configured Maintenance source to check for active maintenance mode records that need to be synced back and applied to servers.

2. (If Enabled) Any Cancelled Maintenance Modes are removed

SCOM checks the FQDN provided by the Maintenance Record and matches it against the PrincipalName of the object in SCOM. If this object is already in a Maintenance mode that has been marked as canceled this will be removed.

3. Any Active Maintenance Modes Are Applied

SCOM checks the FQDN provided by the Maintenance Record and matches it against the PrincipalName of the object in SCOM. When a match is found the Maintenance mode is applied using the settings provided in the maintenance record.

4. (If Enabled) Any Updates to Existing Maintenance Modes are Applied

SCOM checks the FQDN provided by the Maintenance Record and matches it against the PrincipalName of the object in SCOM. If this object is already in a Maintenance mode that does not match the settings in the record retrieved, this will be updated to reflect the settings provided.