Windows Event Log Monitoring

NetXMS provides two complementary approaches to Windows Event Log monitoring:

  • Parser-based monitoring (logwatch.nsm) — matches specific patterns in event log entries and generates NetXMS events

  • Event log synchronization (wineventsync.nsm) — copies all or filtered event log records to the NetXMS server for centralized storage and server-side parsing

Parser-Based Monitoring (logwatch.nsm)

Parser-based monitoring uses the same Log Watch subagent framework as file-based log monitoring, with a Windows Event Log-specific data source.

The agent uses the modern Windows Event Log API (Evt* functions) introduced in Windows Vista/Server 2008. On older Windows versions, event log monitoring is not available.

Configuration

Load the Log Watch subagent in the agent configuration:

SubAgent = logwatch.nsm

Event Log Parser Definition

Windows Event Log parsers use the same XML format as file parsers, with <file> containing the event log (channel) name prefixed with an asterisk (*):

<parser>
  <file>*System</file>
  <rules>
    <rule>
      <id>7036</id>
      <source>Service Control Manager</source>
      <match>The (.*) service entered the (.*) state</match>
      <event>100200</event>
      <description>Service state change</description>
    </rule>
  </rules>
</parser>

The two capture groups are passed as parameters of event 100200, so the event template’s message can be defined as, for example, Service %1 entered the %2 state. The <description> element is only a rule label shown in trace output; it is never macro-expanded and has no effect on the generated event.

The leading * is what marks the parser as a Windows Event Log parser. Without it, the name is treated as a file path and the parser will monitor a file instead of an event log.

The <file> element specifies the Windows Event Log (channel) name:

  • *System — System event log

  • *Application — Application event log

  • *Security — Security event log (requires appropriate privileges)

  • *Setup — Setup event log

  • Any other channel name is also supported, for example:

<file>*Microsoft-Windows-TaskScheduler/Operational</file>

Rule Elements for Windows Events

In addition to the standard <match> element, Windows Event Log rules support:

Element Description

<id>

Windows Event ID to match (numeric). <facility> is accepted as an alias.

<source>

Event source name to match. <tag> is accepted as an alias.

<level>

Bitmask of event level flags, matched with binary AND: Error=0x001, Warning=0x002, Information=0x004, AuditSuccess=0x008, AuditFailure=0x010, Critical=0x100. Default is 0xFFFFFFFF (match any level).

<match>

Regex pattern to match against the event message text
<severity> is accepted as a synonym of <level> in parser XML — it is a filter on the Windows event level and does not set the severity of the generated NetXMS event. The generated event’s severity is defined by its event template.

Multiple filter elements are AND-combined — all specified elements must match for the rule to trigger.

The <logName> element matches against the event channel name, scoping the rule to specific channels when the parser monitors several of them. In the server-side Windows event parser the same condition appears as the Log name field in the rule editor.

Example: Security Audit Monitoring

<parser>
  <file>*Security</file>
  <rules>
    <rule>
      <id>4625</id>
      <event>100210</event>
      <description>Failed login attempt</description>
    </rule>
    <rule>
      <id>4624</id>
      <match>Logon Type:\s+10</match>
      <event>100211</event>
      <description>RDP login</description>
    </rule>
    <rule>
      <id>4720</id>
      <event>100212</event>
      <description>User account created</description>
    </rule>
  </rules>
</parser>

Details of the matched Windows event (event ID, source, insertion strings) are passed as parameters of the generated event — see Event Parameters — and can be referenced in the event template’s message.

Example: Application Error Monitoring

<parser>
  <file>*Application</file>
  <rules>
    <rule>
      <level>1</level>
      <event>100220</event>
      <description>Application error</description>
    </rule>
    <rule>
      <level>2</level>
      <event>100221</event>
      <description>Application warning</description>
    </rule>
  </rules>
</parser>

In this example, <level>1</level> matches Error records (bit 0x001) and <level>2</level> matches Warning records (bit 0x002). To match several levels with one rule, sum the flag values (e.g. <level>3</level> matches Error and Warning).

Event Parameters

When a parser rule matches a Windows event, the following named parameters are passed to the generated NetXMS event:

Parameter Description

capture group names

Capture groups from the regular expression: named groups are passed under their names, unnamed groups as group_1, group_2, …​

eventTag

Event tag (if set)

source

Windows publisher/source name

eventId

Windows event ID

severity

Windows severity level

recordId

Windows record ID

repeatCount

Repeat count

variable1 .. variableN

Windows event insertion strings

fileName

Always empty for Windows Event Log parsers (set only by file-based parsers)
These agent-side parameter names differ from those used by the server-side Windows event parser (e.g. insertion strings are passed as variable1 .. variableN by the agent, while the server-side parser extracts <EventData> values as named parameters or wevt1, wevt2, …​).

Windows Event Log Synchronization (wineventsync.nsm)

NetXMS can collect and centrally store Windows event logs. Collection is performed by NetXMS agents using the wineventsync.nsm subagent. Unlike parser-based monitoring which matches specific patterns, synchronization copies all or filtered event log records to the server database.

Windows events received by the NetXMS server are stored in the database and can be viewed in the Windows Events log in the Logs perspective. Upon reception, event logs can be parsed according to server-side rules and NetXMS events can be generated.

Agent Configuration

Agent configuration for Windows Event Log Synchronization can be done in two ways:

  1. In the agent’s configuration file

  2. Using Agent Configuration policy (see Agent Policies)

Enable the Windows Event Log Synchronization subagent in the agent configuration:

SubAgent = wineventsync.nsm

Logs to monitor are specified in the [WinEventSync] section:

[WinEventSync]
EventLog = Application
EventLog = Security
EventLog = System

With the above configuration, records in the specified logs will be synchronized.

Additional parameters in the [WinEventSync] section:

Parameter Type Default Description

ProcessOfflineEvents

Boolean

true

Replay events recorded while the agent was down (offline events) on startup

MaxOfflineEventAge

Integer

1

Maximum age of offline events to replay, in days

The subagent also provides the WinEventSync.EventLogs list, which returns the event logs configured for synchronization.

Per-log filtering settings can be configured in sections named after the log, e.g. [WinEventSync/System].

Filtering is done in two stages:

  1. Pre-filter — independently filters events by Event ID, Source, and Severity level

  2. Filter (added in version 5.2) — defines a chain of rules to filter by combinations of Event ID, Source, and Severity level

Pre-filter

Event ID Filtering

Filtering by Event IDs is done using IncludeEvent and ExcludeEvent options. Ranges are supported (e.g. 100-200). Comma-separated lists are not supported; add multiple lines for multiple includes/excludes.

By default, if no IncludeEvent or ExcludeEvent are given, all IDs in that log will be synchronized. Explicit Includes override Excludes. For example, if you configure IncludeEvent=201 and ExcludeEvent=200-300, you will receive all events except 200 and 202-300.

To exclude all Event IDs and selectively include specific ones:

[WinEventSync/Security]
IncludeEvent = 4624-4625
IncludeEvent = 4800-4803
ExcludeEvent = 0-65535

Source Filtering

Filtering by Source is done using IncludeSource and ExcludeSource options. Wildcard characters are supported: * (matches zero or more characters) and ? (matches any single character).

By default, if no IncludeSource or ExcludeSource are given, all sources in that log will be synchronized. You can use ExcludeSource=* to exclude all sources and specify IncludeSource to override the exclusion for specific sources.

[WinEventSync/System]
IncludeSource = Microsoft-Windows-WindowsUpdateClient
ExcludeSource = *

Severity Level Filtering

Filtering by severity level (also called event type in older Windows versions) is done using the SeverityFilter option. If it is not set, all severity levels (including Critical) are synchronized. Each severity level has its own numeric value. To filter by multiple severity levels, specify the sum of appropriate values (bitmask), or use comma-separated severity level names.

Severity Level Hex Value Decimal Value

Error

0x001

1

Warning

0x002

2

Information / Info

0x004

4

AuditSuccess

0x008

8

AuditFailure

0x010

16

Critical

0x100

256

The following examples all filter only Warning and Error records:

[WinEventSync/System]
SeverityFilter = 0x003
[WinEventSync/System]
SeverityFilter = 3
[WinEventSync/System]
SeverityFilter = Warning,Error

Filter Chains

Filter chains were added in version 5.2.

Filter chains allow defining a sequence of rules to filter by combinations of Event ID, Source, and Severity level. Rules are specified using the Filter option in the format:

Filter = Action:Source:Id:Severity
Field Required Description

Action

Yes

Either accept or reject

Source

No

Event source (provider) name. Wildcards supported: (multiple characters), ? (single character). Empty or matches any source.

Id

No

Event ID or range (e.g. 4800-4803). * or empty matches any ID.

Severity

No

Bitmask or comma-separated severity level names (same format as SeverityFilter). * or empty matches any severity.

Rules are processed sequentially. When an event matches a rule, it is accepted or rejected based on the rule’s action, and processing stops. Events that do not match any rule are accepted by default. It is recommended to add Filter=reject as the last rule to explicitly reject unmatched events.

Example: Accept only specific security events
[WinEventSync/Security]
Filter = accept:*:4624-4625:*
Filter = accept:*:4720-4722:*
Filter = accept:*:4800-4803:*
Filter = reject:*:*:*
Example: Reject noisy sources, accept everything else
[WinEventSync/Application]
Filter = reject:SomeNoisyApp:*:*
Filter = reject:AnotherNoisyApp:*:information
Filter = accept:*:*:*
Example: Combined pre-filter and filter chain
[WinEventSync/System]
SeverityFilter = Error,Warning,Critical
Filter = reject:*:1000-2000:*
Filter = accept:*:*:*

Complete Configuration Example

SubAgent = wineventsync.nsm

[WinEventSync]
EventLog = System
EventLog = Security
EventLog = Application

[WinEventSync/System]
SeverityFilter = Error,Warning,Critical
IncludeSource = Service Control Manager
IncludeSource = Microsoft-Windows-WindowsUpdateClient
ExcludeSource = *

[WinEventSync/Security]
IncludeEvent = 4624-4625
IncludeEvent = 4720-4722
IncludeEvent = 4800-4803
ExcludeEvent = 0-65535

[WinEventSync/Application]
ExcludeSource = SomeNoisyApp
SeverityFilter = Error,Critical
Filter = reject:TestApp:*:*
Filter = accept:*:*:*

Debugging

Agent log messages related to Windows event log synchronization are written with the tag wineventsync. To enable debug logging, add the following to the agent configuration:

DebugTags = wineventsync:6

Server-Side Windows Event Parser

Windows events received by the server (via wineventsync.nsm) can be parsed according to rules that generate NetXMS events. The parser is configured in Configuration  Windows Event Log parser.

Storage of synchronized Windows events to the server database is controlled by the WindowsEvents.EnableStorage server configuration variable (default: enabled). When enabled, events are written to the win_event_log database table. Stored records are kept for the period set by WindowsEvents.LogRetentionTime (default: 90 days). The DBWriter.MaxRecordsPerTransaction variable controls batch size for database writes (default: 1000).

Parser Editor

Rules can be edited using the graphical editor or XML editor. When switching between editors, all entered information is automatically converted.

If the Always process all rules checkbox is not set, rules are processed until the first match. If set, all rules are always processed.

Macros

In the Macros section you can define macros for use in matching rules. For example, define a macro for an IP address pattern and reuse it across multiple rules instead of repeating the regular expression. Each macro must have a unique name and can be referenced in matching rules as @{name}.

Rule Conditions

Each rule can have multiple conditions that are AND-combined:

Condition Description

Matching regular expression

A PCRE-compliant regular expression matched against the event message. Parts enclosed in parentheses are extracted as capture groups and passed as parameters of the generated NetXMS event. Macros defined in the Macros section can be used. If the Invert checkbox is set, the record matches when it does not match the expression.

Level

Severity level bitmask filter. Same values as the agent-side severity table (Error=1, Warning=2, Information=4, AuditSuccess=8, AuditFailure=16, Critical=256).

Event ID or ID range

Specify a single event ID (e.g. 7) or a range with a minus sign (e.g. 10-20 matches IDs 10 through 20 inclusive).

Source

Event source name or pattern with and ? wildcards. For example, Tcpip matches the exact source (case-insensitive), and X matches any source starting with "X".

Log name

Windows Event Log name or pattern with * and ? wildcards.

Rule Actions

When a rule matches, the following actions can be performed:

  • Generate NetXMS event — optional. It can be useful to have rules that act as exclusions: match specific conditions without generating events.

  • Break — stop processing subsequent rules even if Always process all rules is set.

  • Do not save to database — the matched Windows event record will not be stored in the database.

Event Parameters from Server Parser

When the server-side parser generates a NetXMS event, the following named parameters are available:

Parameter Description

1 to n

Capture groups from the matching regular expression

eventTag

Event tag (if set on the rule)

wevtSource

Windows event publisher/source name

wevtId

Windows event ID

wevtLevel

Windows severity level

wevtRecordId

Windows event record ID

repeatCount

Number of times this event was repeated

data element names

Event data parameters, built from the Windows event XML (see below)

Event data parameters are derived from the <EventData> section of the Windows event XML:

  • <Data Name="X"> elements become parameters named after the Name attribute (e.g. <Data Name="TargetUserName"> becomes parameter TargetUserName)

  • Unnamed <Data> elements become wevtN, where N is the element’s position among all children of <EventData>, named and unnamed alike — an unnamed element that follows two named ones becomes wevt3

  • Binary data becomes wevtBinaryData

Policy Deployment

Windows Event Log parsers can be deployed through agent policies for centralized management:

  1. Create a Log Parser Policy on a template

  2. Define the parser XML with Windows Event Log configuration

  3. Apply the template to Windows nodes

See Agent Policies for details.

Troubleshooting

Events Not Being Captured

  1. Verify the agent is running with sufficient privileges (LocalSystem or an account with Event Log Reader rights)

  2. Check that the appropriate subagent is loaded (logwatch.nsm for parser-based monitoring, wineventsync.nsm for synchronization)

  3. Verify the event log (channel) name matches exactly

  4. Check agent log for parser errors

  5. For synchronization issues, enable debug logging with DebugTags=wineventsync:6

Security Log Access

The Security event log requires the agent to run as LocalSystem or an account in the Event Log Readers group. If the agent cannot access the Security log, check the agent service’s logon account.

Server Not Receiving Events

  1. Verify the agent can connect to the server

  2. Check that WindowsEvents.EnableStorage is enabled on the server if you want events stored in the database

  3. Check the server-side Windows event parser configuration in Configuration  Windows Event Log parser

  4. Review server debug logs with tag winevt for processing errors