The problem occurred in the following two scenarios:
a) When a 2nd ruleset is mistakenly applied to a GC that already had a ruleset applied and then it was removed.
b) When a ruleset is applied to multiple GCs with hundreds of devices in multiple landscapes and then removed.
The Ruleset remains assigned to hundreds of servers/devices.
The steps from the following KB article did not resolve the issue:
How to fix Process Rulesets invalidly applied to some Models
DX NetOps Spectrum: Any release
In case of invalid File System resources use the action code REMOVE_INVALID_HOST_RESOURCE_RULE_DATA ( 0x10334 )
update.exe action=0x10334 mh=<rfc27790app mh> (Windows)
./update action=0x10334 mh=<rfc27790app mh> (Linux)
This action can be performed on the VNM model as well as rfc2790App model instance.
When you perform this action on the VNM model, it finds out all models whose model type is rfc2790App and performs the action on each of the model.
(Action on the VNM model will work internally on ALL rfc2790app model instances):
update.exe action=0x10334 mh=<VNM model handle> (Windows)
./update action=0x10334 mh=<VNM model handle> (Linux)
In case of invalid Monitored Process recourses use the action code REMOVE_INVALID_HOST_RESOURCE_PROCESS_DATA ( 0x10335 )
update.exe action=0x10335 mh=<rfc27790app mh> (Windows)
./update action=0x10335 mh=<rfc27790app mh> (Linux)
This action can be performed on the VNM model as well as rfc2790App model instance.
(Action on the VNM model will work internally on ALL rfc2790app model instances):
update.exe action=0x10335 mh=<VNM model handle> (Windows)
./update action=0x10335 mh=<VNM model handle> (Linux)
Without enabling any debug these actions will log into the file VNM.OUT
For example :
Performed REMOVE_INVALID_HOST_RESOURCE_RULE_DATA ( 0x10334 ) on VNM model handle ( 0x1000000 )
vnmsh>update.exe action=0x10334 mh=0x1000000
update action: successful
Response has 0 attributes:
VNM.OUT logs :
2024/09/02 06:21:29
trying to clean up invalid host resource ruleset data
Checking disk monitoring data for model 0x1000071
Number of rules - 1
Number of associations - 1
Disk monitoring data for model 0x1000071 has been successfully cleaned up (0 incorrect entries were removed)