Forum Discussion

enescalban's avatar
enescalban
Copper Contributor
Jul 25, 2026

Windows Forwarded Events connector with Windows Security Events NRT rules

Hello,

We are testing Microsoft Sentinel using the official Windows Forwarded Events connector.

 

Environment

- Windows Server WEC

- Windows Event Forwarding

- Azure Arc

- Azure Monitor Agent

- Windows Forwarded Events connector

 

Everything works correctly.

Forwarded security events are successfully ingested into the WindowsEvent table.

 

For example:

 

- Event ID 1102

- Event ID 4732

 

However, the built-in Windows Security Events NRT Analytics Rules (Content Hub version 1.0.1) query only the SecurityEvent table.

 

Example:

 

NRT Security Event log cleared

 

SecurityEvent

| where EventID == 1102

 

As a result, forwarded events received through the Windows Forwarded Events connector never trigger these NRT rules.

 

Question:

 

Is this expected behavior?

 

Should Windows Forwarded Events customers use a different set of analytics rules (ASIM or other templates), or should these built-in NRT rules also support WindowsEvent?

 

Thank you.

1 Reply

  • Yes—this behavior is expected for these specific templates. Your WEC/WEF, Arc, and AMA path is working because forwarded records reach WindowsEvent, while Windows Security Events via AMA writes to SecurityEvent. An NRT rule evaluates only the tables referenced by its KQL, so a template starting with SecurityEvent cannot detect event 1102 or 4732 stored in WindowsEvent; the connector itself is not failing.

     

    Create a custom NRT rule based on the template logic, query WindowsEvent, filter EventID, and project only fields needed for alerts and entity mappings. For 4732, inspect EventData and map the member and group values present in your records. Test against recent events, enable the rule, then prevent duplicate detections. If you require the unchanged SecurityEvent templates, collect the source machines through Windows Security Events via AMA. Use an ASIM-based template only when its documented parser and schema explicitly support these records; ASIM is not an automatic bridge.