Event Suppression Due to Related Change Request

[ahmedaldorr]

Dears,

According to the default Maintenance rule, the primary CIs referenced in a change request will be automatically added to the table em_impact_maint_ci during the service window to mask or suppress related events.

If the referenced CI in the change request is a dynamic group, then the maintenance rule will add the dynamic group itself in that table.

So my Question now is: Does servicenow extract that dynamic group to suppress the related CIs or not?

[abbasshaik4]

Hello @ahmedaldorr,

Please refer to the link below:
Solved: Re: Alert suppression during change window or chan... - ServiceNow Community

If it is helpful, please mark it as helpful and accept the correct solution by referring to this solution in the future it will be helpful to them.

Thanks & Regards,

Abbas Shaik

[ahmedaldorr]

Unfortunately the details he provided are incorrect

[sagieratzon]

Hi @ahmedaldorr ,

The maintenance rule doesn’t expand the dynamic CI group into its member CIs.

The “CI in Change Window” rule writes the CI referenced on the change to em_impact_maint_ci. If that CI is a dynamic CI group, only the group record is written. The members aren’t.

If you need the members suppressed:

1. Custom maintenance rule (Advanced option): use a script that resolves the dynamic CI group’s members and returns them as CIs in maintenance during the change window. (Sharing below an example of custom script that works for cmdb_group table on custom fields, but you can modify it to work for your use case)
2. Affected CIs: populate the change’s Affected CIs with the group members. First confirm whether your maintenance rule evaluates affected CIs or only the primary CI.

Let me know if that helps.

Maintanace Rule Script:

(function findCisInMaint() {
return JSON.stringify(Object.keys(new MaintenanceWindowUtils().getCIsInActiveGroupWindows()));
})();

Script Include Maintanace Rule calls to:

var MaintenanceWindowUtils = Class.create();
MaintenanceWindowUtils.prototype = {
initialize: function() {},

// Returns { sys_id: true, ... } for every CI currently inside an ACTIVE group window.
getCIsInActiveGroupWindows: function() {
var ciSet = {};
var now = new GlideDateTime();

var grp = new GlideRecord('cmdb_group');
grp.addNotNullQuery('u_start_maintenance_date');
grp.addNotNullQuery('u_end_maintenance_date');
grp.addQuery('u_start_maintenance_date', '<=', now);
grp.addQuery('u_end_maintenance_date', '>=', now);
grp.query();

while (grp.next()) {
var groupId = grp.getUniqueValue();
var groupName = grp.getValue('name');

// Manual CIs + Saved (Query Builder) queries
try {
var response = sn_cmdbgroup.CMDBGroupAPI.getAllCI(groupId, false, true);
var parsed = new JSONParser().parse(response);
if (parsed && parsed.idList) {
for (var i = 0; i < parsed.idList.length; i++)
ciSet[String(parsed.idList[i])] = true;
}
if (parsed && parsed.errors && parsed.errors.length)
gs.warn('[MaintUtils] getAllCI errors for "' + groupName + '": ' + JSON.stringify(parsed.errors));
} catch (ex) {
gs.warn('[MaintUtils] getAllCI failed for "' + groupName + '": ' + ex);
}

// Encoded-query members
this._addEncodedQueryMembers(groupId, groupName, ciSet);
}
return ciSet;
},

_addEncodedQueryMembers: function(groupId, groupName, ciSet) {
var enc = new GlideRecord('cmdb_group_contains_encoded_query');
if (!enc.isValid())
return;
enc.addQuery('group', groupId);
enc.query();
while (enc.next()) {
var ciClass = enc.getValue('class');
var encQuery = enc.getValue('condition');
if (!ciClass || !encQuery)
continue;
var ci = new GlideRecord(ciClass);
if (!ci.isValid()) {
gs.warn('[MaintUtils] invalid CI class "' + ciClass + '" in group "' + groupName + '"');
continue;
}
ci.addEncodedQuery(encQuery);
ci.query();
while (ci.next())
ciSet[ci.getUniqueValue()] = true;
}
},

type: 'MaintenanceWindowUtils'
};

[rpriyadarshy]

  when you are raising the Change which CI is the Impacted CI in the Change Record?

ServiceNow Event Management uses the out-of-the-box "CI in Change Window" maintenance rule to automatically suppress alerts. When a change request moves to the Implementation phase, linked Configuration Items (CIs) enter a maintenance state (em_impact_maint_ci table), stopping alert rule processing and filtering alerts from the console.

Now your Second Questions : OOTB CMDB Based ALERT Correlation works when alerts are coming on CIs which are part of the CMDB MAP. 

In your scenario I do not think AUTOMATIC Alert Correlation will work for whole Dynamic Group CIs .

Regards

RP