OperationsManager plugin health state does not update in the SCOM console

Question

The health state reported by the OperationsManager plugin does not update in the SCOM console after a manual health‑state reset is performed in SCOM console.

When the health state of an OME device is reset in SCOM, subsequent health‑synchronisation cycles fail to reflect the actual device status from OME.

For example: A device that shows Critical in both OME and SCOM becomes Healthy after a manual reset in SCOM. During the next health synchronisation, while the device remains Critical in OME, the updated state is not propagated back to SCOM.

Has anyone else encountered this behaviour?

modric · Answer

This issue is usually caused by stale agent cache, SDK service communication problems, or delayed workflow synchronization between the OperationsManager plugin and the SCOM management server.

A few things you can check:

1. Restart the following services on the management server and affected agent:

* System Center Management service
* System Center Data Access service

2. Clear the agent cache:

* Stop the Microsoft Monitoring Agent service
* Delete contents of:
`C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State`
* Start the service again

3. Verify the OperationsManager plugin workflows are running correctly and not stuck in a failed state.

4. Check Event Viewer under:

* Applications and Services Logs
* Operations Manager

Look for SDK connection errors, workflow failures, or health service warnings.

5. Force a manual health refresh from the SCOM console or run:
`Remove-SCOMDisabledClassInstance`
and trigger agent rediscovery if objects are stale.

6. If the console state still does not update, verify database grooming and synchronization between the Operational DB and data warehouse.

In many cases, restarting the HealthService and clearing the Health Service State folder resolves delayed or incorrect plugin health status updates.

covid-19 · Answer

I have done these and it did not resolve the issue.

1. Restart the following services on the management server and affected agent:

* System Center Management service
* System Center Data Access service

2. Clear the agent cache:

* Stop the Microsoft Monitoring Agent service
* Delete contents of:
`C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State`
* Start the service again

For, 3. Verify the OperationsManager plugin workflows are running correctly and not stuck in a failed state.
How do I do that and which workflows?

Dell-Martin S · Answer

Did you notice any Event ID 21405 entries in your Management Server's event viewer when searching for the Dell workflows? if yes this could helps https://andresorange.home.blog/2017/09/20/health-service-modules-event-id-21405/

covid-19 · Answer

@Dell-Martin S​ at the primary management server, No, I did not find event ID 21405I tryied the WFAnalyzer.exe but the tool keeps on crashing. Although it successfully created a task in SCOM console that showing running rules and Monitors for this Health Service whichs shows something like this: Object Id: {7A993E00-C6CA-7350-1D49-F9C6A281D704} Object Display Name: System Workflows: show/hide

Dell-Martin S · Answer

Run the Direct Workflow Check via SCOM PowerShell

If you see a workflow listed with a Status of Failed or an error referencing a database token or API connection, copy that description. If the list comes back completely empty, it means SCOM has completely unloaded the Dell monitoring logic due to a security or configuration mismatch

When a SCOM monitor gets stuck after a manual reset, the underlying database logic stops running calculations for that device because it thinks the state is settled. You must force the SCOM management server to discard its memory cache and rebuild the Dell device tree.

Open the SCOM Console and go to the Authoring workspace.
Select Management Pack Objects > Monitors.
In the Look For search box at the top, type Dell and press Enter.
Locate the core device monitor (usually named Dell OpenManage Enterprise Device Health Monitor or similar).
Right-click it, select Overrides > Override the Monitor > For all objects of class...
Find the parameter row for Enabled.
Check the Override box, change the Override Value to False, and save it into your custom overrides Management Pack.
Wait 5 minutes for the configuration to distribute across your management servers. (This completely strips the broken tracking logic off the devices).
Go back to that same override, uncheck the override box (or delete the override), and save it.

This forces SCOM to tear down the old monitoring instances and completely rebuild them from scratch. It will query the OME appliance freshly, realize the device is actually "Critical," and update the console immediately.

covid-19 · Answer

@Dell-Martin S​  In the SCOM console under Management Pack Objects -> Monitors, I filtered on the Dell OME Server Management Pack and I can see the following health monitors: Dell Server Memory Group Health Dell Server PowerSupply Group Health Dell Server Processor Group Health Dell Server Storage Group Health Dell Server Temperature Group Health Dell Server Voltage Group Health Dell.OME.serverSystem.Health Are these the monitors you are suggesting to temporarily override to False, wait for the management pack changes to propagate across all Management Servers, and then remove the override afterward?Thanks

Systems Management General

OperationsManager plugin health state does not update in the SCOM console

Was this post helpful?