Last Modified: Mar 21, 2019
See more info
Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 12.1.4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 13.1.1, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 14.0.0, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 14.1.0, 220.127.116.11, 18.104.22.168, 22.214.171.124
Opened: Oct 02, 2017
A WMI monitor configured for an invalid node defaults to 'UP', and never transitions to 'DOWN'. Upon loading a configuration, a node defaults to 'UP' as an initial probe is sent based on the monitor configuration, and the node is then marked 'DOWN' as probes timeout or monitor responses indicate an error. However, an WMI monitor probe sent to a non-existent node is not detected as an error, and that node may persist in an 'UP' state (not transitioning to 'DOWN' as expected, such as after expiration of the configured monitor timeout).
The node persists in an 'UP' state, even though no WMI service is available, or that node does not exist.
WMI monitor is configured for an invalid node address, or for a node address on which no WMI service is running.
An additional node monitor can be created to confirm the node is available (which may be a partial solution in some configurations). Using a non-WMI monitor (such as TCP) to probe availability of the WMI service on the target node may be possible in other scenarios.