Change how vCenter alarms create SCOM alerts
Control which vCenter alarms are forwarded to SCOM, and how often, with UseBookMark and the AlarmFilter.csv filter file.
Applies to: OpsLogix VMware Management Pack (all versions) · SCOM 2019, 2022, 2025 · vCenter 7.0, 8.0, 9.0
Last updated: October 2026 · Reading time: 5 minutes
Goal
Control which vCenter alarms the VMware Management Pack turns into SCOM alerts. You can change how the alarm rule picks up alarms, and you can filter out alarms you don't want in SCOM.
How vCenter alarms become SCOM alerts
The rule Monitor vCenter for new Alerts runs every 2 minutes (120 seconds) for each vCenter connection. It asks the OpsLogix VMware Collector for the triggered alarms in vCenter and creates a SCOM alert for each one, named VC Alert raised: <alarm name>.
| vCenter alarm status | SCOM alert severity |
| Red | Critical |
| Yellow | Warning |
| Any other status | Information |
SCOM suppresses duplicates: a second occurrence of the same alarm on the same object raises the repeat count of the open alert instead of creating a new one.
If you scaled out the connection, the extra connection objects (<connection>--GROUP01 and so on) only forward alarms of ESXi hosts, virtual machines and snapshots. See Scale out a vCenter connection.
Option 1: Choose which alarms the rule picks up (UseBookMark)
The rule has an override parameter UseBookMark:
| UseBookMark | What the rule forwards |
| True (default) | Only alarms that were triggered after the previous run of the rule. Each alarm is forwarded once. Alarms that were already active when the rule started, for example after an upgrade or after a restart of the Microsoft Monitoring Agent, aren't forwarded. The same goes for alarms that are triggered while the agent is stopped. |
| False | Every triggered alarm, in every run. The repeat count of the SCOM alert goes up every 2 minutes for as long as the alarm is triggered in vCenter. If you close the SCOM alert while the alarm is still triggered, the next run creates a new alert. This continues until the alarm is no longer triggered in vCenter, for example after Reset to Green. Acknowledging the alarm in vCenter doesn't stop it. |
Use False if you don't want to miss alarms that were already active, and you accept the repeated alerts.
To change it:
- In the Operations console, go to Authoring > Management Pack Objects > Rules and search for Monitor vCenter for new Alerts.
- Right-click the rule and select Overrides > Override the Rule > For all objects of class: VMware vCenter, or select a group to change it for some connections only.
- Override UseBookMark to the value you want, select an unsealed management pack for the override and click OK.
The rule also has the override parameters Interval (default 120 seconds), Priority (default 0, Low), Severity, SyncTime, DebugModule and Enabled. Keep the default interval unless you have a reason to change it, and don't override Severity: its default passes the vCenter alarm status on to the alert.
Option 2: Filter out specific alarms
We recommend that you tune the alarms in vCenter first, so vCenter only raises alarms that matter to you. For alarms you can't change in vCenter, use the alarm filter of the OpsLogix VMware Collector. The collector drops matching alarms before they reach SCOM.
- On a server in the VMware resource pool, open C:\Program Files\Opslogix\OpsLogix VMware Collector\AlarmFilter\AlarmFilter.csv in a text editor such as Notepad. The collector installs this file with only a header line.
- Keep the header line
AlarmName,EntityType,EntityDisplayName,OverallStatusand add one line per filter. Separate the columns with commas. Leave a column empty to ignore it. An alarm is filtered out when it matches every column you filled in on one line. - Save the file. If you use Excel, save it as CSV (comma delimited); other formats can use a different separator, and the collector then can't read the file.
- Copy the same AlarmFilter.csv to C:\Program Files\Opslogix\OpsLogix VMware Collector\AlarmFilter\ on every server in the VMware resource pool. Each server filters only the alarms it collects itself.
- Restart the Opslogix VMware Collector Service on all these servers. The collector reads the file only when it starts.
| Column | Matches |
| AlarmName | The name of the alarm as shown in vCenter, for example Host memory usage. |
| EntityType | The vSphere type of the object that triggered the alarm, for example HostSystem, VirtualMachine, Datastore, ClusterComputeResource, Datacenter, ResourcePool or VmwareDistributedVirtualSwitch. |
| EntityDisplayName | Don't use this column. See Known issue below. |
| OverallStatus | The alarm status: red, yellow, green or gray. |
Each column is a regular expression. Keep in mind that:
- The match is case-sensitive.
yellowdoesn't matchYellow. - The expression can match anywhere in the value.
Hostalso matchesHost memory usageandVM on Host. Use^and$to match the start and end, for example^HostSystem$. - Don't put spaces around the separators or inside expressions like
(yellow|red).
Example
AlarmName,EntityType,EntityDisplayName,OverallStatus
,^HostSystem$,,^yellow$
^Host memory usage$,^HostSystem$,,
^Virtual machine,,,^(yellow|red)$
- Line 2: filters all yellow alarms of ESXi hosts.
- Line 3: filters the alarm Host memory usage of ESXi hosts, with any status.
- Line 4: filters all yellow or red alarms whose name starts with Virtual machine, from any object type.
Known issue: don't fill in the EntityDisplayName column. The collector compares it with a value that it doesn't fill in for alarms. A line that uses it can make the whole alarm request fail, so no alarms are forwarded at all. Use AlarmName and EntityType instead. To leave out alarms of specific objects, use Exclude VMware components from monitoring.
Upgrades: an upgrade of the management pack reinstalls the collector, which can replace your AlarmFilter.csv with the default file. Keep a copy, and check the file on every server after an upgrade.
Verify it worked
- UseBookMark: watch new alarms in vCenter. The SCOM alerts follow the behavior in the table above.
- Filter: when the collector starts, it writes Found Alarm black list file. Parsing.... to the Operations Manager event log (source OpsLogix VMware Collector). If the file can't be read, it writes a warning There was an error trying to parse Alarm Black list file. Continuing startup without alarm blacklist filtering. Fix the file and restart the service. Matching alarms no longer create SCOM alerts; other alarms still do.
See also
- Exclude VMware components from monitoring
- The OpsLogix VMware Collector explained
- Rules and monitors in the VMware Management Pack