SCOM Connector Design prototype
This article explains a simple prototype to design SCOM connector to any of the ITIL tool.
A connector is a custom script or program that sync SCOM alerts to ticketing tool and vice versa.
Connector operations:
1) Create ticket on new alert
2) Update ticket on alert status change
3) Update alert with ticket info
4) Close alert on ticket resolve and reset monitor health state.
Known issues with Alert’s creation in SCOM: SCOM generates duplicate alert in turn duplicate tickets will be created in ticketing tool. duplicate alerts will be generated from rule/monitor for same problem in below scenarios
Monitor: the monitor is configuring to generate alert and set to auto resolve i.e. if the issue is intermediate scom will create new alert every occurrence in turn creates new tickets even though there is open ticket for old alert.
Example: CPU utilization monitoring, let’s assume monitoring is configured for 80% threshold, SCOM will generate alert on reaching 80% and closes alert once it is normal. On each occurrence of issue, a new alert will be generated.
We have option to create an override for monitor to disable auto resolve, which involve lot of effort.
Please find the script to create bulk override:
Rule: The rule is configured to generate alert without Alert suppression for example event id alert rule, a new alert will be generated for every occurrence of alert.
Rule do not have any option to add suppression parameters via override, to add suppression parameters need to disable current rule using override and create new rule in unsealed MP.
Refer below link for more information on
Workaround: Creating override is time consuming and tedious, to overcome this issue we can build connector with below logic.
Alert: any alert generated in SCOM has below parameters
Category,ConnectorId,ConnectorStatus,Context,CustomField,CustomField10,CustomField2,CustomField3,CustomField4,CustomField5,CustomField6,CustomField7,CustomField8,CustomField9,Description,Id,IsMonitorAlert,LastModified,LastModifiedBy,LastModifiedByNonConnector,MaintenanceModeLastModified,ManagementGroup,ManagementGroupId,MonitoringClassId,MonitoringObjectDisplayName,MonitoringObjectFullName,MonitoringObjectHealthState,MonitoringObjectId,MonitoringObjectInMaintenanceMode,MonitoringObjectName,MonitoringObjectPath,MonitoringRuleId,Name,NetbiosComputerName,NetbiosDomainName,Owner,Parameters,PrincipalName,Priority,ProblemId,RepeatCount,ResolutionState,ResolvedBy,Severity,SiteName,StateLastModified,TicketId,TimeAdded,TimeRaised,TimeResolutionStateLastModified,TimeResolved,
Refer below link for more information:
** Connector Workflow:**
Unique parameters for Ticketing tool: TicketID
Unique parameter for SCOM alert: Alert ID
For cross tool communication Alertid will be stored in ticket and TicketID will be stored in Alert TicketID field, so that for every alert there is a ticket and vice versa.
If Alert is reoccurring for same issue need to create one ticket and append all reoccurring SCOM alert to ticket until issue is resolved by engineer i.e. multiple alert will be appended to same ticket.
Workflow:
Note: above prototype will not work for transaction monitoring like ( port, url, sql query ), as monitoring object path and alert name remain static, to overcome this issue need to add dynamic alert name for transaction monitoring.
Refer below link how to add dynamic alert description in alert:
https://blogs.technet.microsoft.com/kevinholman/2015/02/20/can-alert-names-contain-dynamic-data/