Troubleshooting Tip: FortiSIEM Windows Agents display an Event Status of Critical despite logs being received due to residual OMI onboarding artifacts

This issue typically arises when Windows servers with FortiSIEM agents are reporting a Critical event status, even though logs are being received normally. As a result, these agents are automatically being placed into an Inactive CMDB group, which blocks correlation and downstream processing. The following symptoms have also been observed when this issue is occurring:

• Event Status for Windows Agents remains Critical despite logs being received by FortiSIEM.
• Agents automatically moved to an Inactive CMDB group.
• Attempts to clear status from the GUI alone do not resolve the issue.
• Simply restarting the agent or FortiSIEM services does not clear the status.

Root Cause:

FortiSIEM retains historical OMI monitoring artifacts, even after transitioning to native Windows Agent monitoring. These stale OMI entries result in:

• Conflicting health evaluation

• CMDB misclassification

• Persistent Critical Event Status despite active log transmission

The environment attempts to validate both OMI and native agent health. Since OMI is no longer valid, FortiSIEM interprets it as ongoing failure, keeping the Event Status Critical. For more information on OMI vs native agent, refer to the following documentation links:

• Microsoft Windows Server via OMI/SNMP/WMI
• Microsoft Windows Server via Agent

Steps to Resolve the Issue:

Step 1 - Verify the Affected Hosts

1. In FortiSIEM, navigate to Inventory -> CMDB and locate the affected Windows Hosts.
2. Check and confirm that the Event Status is show as Critical.

3. For the affected Windows hosts, validate that logs are being received successfully despite the Critical status.

Step 2 - Remove OMI Monitoring Traces

1. In FortiSIEM, navigate to the affected device via Device -> Details -> Monitor -> Metric

2. Identify any OMI-related monitoring/metric entries and remove them.

Step 3 - Remove OMI Credentials

1. Navigate to Admin -> Credential and locate the OMI credentials associated with the affected Windows hosts.

2. Delete the credentials, then confirm that the devices are removed from the Pull Events tab.

Step 4 – Clean the CMDB Record

1. Navigate to Inventory -> CMDB and select the previously-identified Windows hosts.

2. Delete the entry to clear any legacy bindings.

CMDB retains a stale binding of the device identity to previous OMI health metrics, which prevents status recalculation. Removing the CMDB entry forces FortiSIEM to rebuild a clean record.

Step 5 – Reinstall FortiSIEM Windows Agent

1. Log into the affected Windows server and uninstall the FortiSIEM Windows Agent. For guidance with uninstalling the Windows Agent, refer to the following FortiSIEM document: Uninstalling Windows Agent

2. Next, reinstall the FortiSIEM Windows Agent (see also: Installing Windows Agent).

3. Once the agent is reinstalled, check the following:

   • Connectivity to FortiSIEM is functioning correctly.

   • Registration details appear to be correct.

   • System time sync is accurate.

Validation:

To validate that the issue is resolved, wait approximately 10 minutes after completing the above procedure and confirm that the Windows host reappears in the CMDB. Verify that the Event Status is Normal, that the host no longer belongs to the Inactive CMDB Group, and that logs are continuing to stream in normally.

If the issue is resolved, repeat the procedure for any additional Windows Agents affected by this issue.

Note: This issue is distinct from the case where Event Status remains 'Critical' following a FortiSIEM upgrade. In that scenario, simply deleting stale metrics is sufficient to resolve the issue, whereas this scenario requires the deeper cleanup and agent re-onboarding described above to resolve the OMI agent conflict.

Related documents:

Troubleshooting Tip: How to troubleshoot collector issues

Microsoft Windows Server via OMI/SNMP/WMI

Microsoft Windows Server via Agent

FortiSIEM Windows Agent