Splunk online course

Monitor Remote Windows Event Logs with Splunk Forwarders

Configure a Splunk Universal Forwarder on Windows to collect Security, Application, and System event logs and send them to the remotelogs index.

A Splunk Universal Forwarder can collect Windows Event Log data on a Windows host and send it to a central Splunk deployment. This lets administrators, security analysts, and operations teams search endpoint events from one location.

In this lesson, you will configure three standard Windows channels—Security, Application, and System—and route their events to a dedicated Splunk index named remotelogs.

Why monitor Windows Event Logs centrally?

Windows Event Log is the operating system's logging system. It organizes events into named channels, including Security, Application, and System. A Universal Forwarder reads selected channels locally, then forwards the events to a receiving Splunk component.

Central collection provides a searchable history that is more useful than inspecting each endpoint separately. Common uses include:

• Troubleshooting: correlate application failures, service changes, driver problems, and operating-system errors with events from other systems.
• Auditing: review logons, account changes, access-control activity, and other audit records.
• Security monitoring: investigate authentication activity, policy changes, suspicious process behavior, and possible attacks.
• Operations: identify recurring warnings and failures across many Windows hosts.

A forwarder is normally lightweight: it collects and transmits data while the indexer receives, processes, and stores it. A search head, or the search interface on an appropriate Splunk deployment, is then used to search the indexed events. See What Are Forwarders for the general forwarding model.

Prerequisites

Complete these requirements before changing the input configuration:

• Install and start a functioning Splunk Universal Forwarder on the Windows host. A Universal Forwarder is a lightweight Splunk component installed on a data-producing host to collect and send data to Splunk. See Install a Splunk Forwarder on Windows.
• Configure the forwarder to send data to a receiving Splunk indexer or another receiving Splunk component. The receiver must permit incoming forwarder data. See Set Up a Receiver.
• Ensure that the account running the forwarder service can read the selected Windows Event Log channels. The Security channel commonly requires more consideration than Application or System.
• Create the destination index before sending events. The example in this lesson uses remotelogs. An index is a Splunk data store and logical partition used to retain and search events. See Create an Index.
• Confirm that the Windows Event Viewer contains the channels and events you expect. Splunk cannot collect events that Windows has not generated or retained.

Understand the three Windows channels

Each channel is independently configurable. You can enable or disable a channel, send it to a different index, or apply different operational controls when requirements differ.

Configure WinEventLog inputs in inputs.conf

inputs.conf is the Splunk configuration file used to define data inputs, including Windows Event Log collection. A bracketed section in a Splunk configuration file is called a stanza. Each WinEventLog stanza describes one Windows Event Log channel.

Create or edit a local inputs.conf file in the forwarder's local configuration directory. For a standard Universal Forwarder installation, an appropriate location is the forwarder's system local configuration directory:

C:\Program Files\SplunkUniversalForwarder\etc\system\local\inputs.conf

Use the actual installation path if the forwarder is installed elsewhere. If an application or deployment-management app owns the input, place the configuration in that app's local directory instead. Do not edit files in a default directory directly; default files are intended to provide baseline settings and may be replaced during upgrades.

Add separate stanzas for the three channels:

[WinEventLog://Security]
disabled = 0
index = remotelogs

[WinEventLog://Application]
disabled = 0
index = remotelogs

[WinEventLog://System]
disabled = 0
index = remotelogs

The WinEventLog:// prefix identifies a Windows Event Log input, and the text after it identifies the channel. disabled = 0 enables the input. The index = remotelogs setting assigns all events from that stanza to the intended destination index.

Why use a dedicated index?

An index is both a storage location and a logical search boundary. Assigning these inputs to remotelogs separates Windows endpoint telemetry from unrelated machine, application, or network data.

A dedicated index can simplify searches, permissions, retention, and storage planning. Before deploying broadly, decide who may search Security events, how long audit data must be retained, and how much storage the index requires. Index naming, retention, access control, and storage allocation are administrative decisions; use the naming and governance standards for your environment.

Apply the configuration

Restart the Splunk Universal Forwarder after changing inputs.conf. Restarting the forwarder reloads its input definitions; it does not restart Windows or reboot the host.

"C:\Program Files\SplunkUniversalForwarder\bin\splunk.exe" restart

Run the command from an elevated command prompt when local service permissions require elevation. Substitute the actual path if the forwarder is installed in a different directory.

If the new inputs do not behave as expected, validate the effective configuration. Splunk configuration can be assembled from system settings and app layers, and a higher-precedence setting may override the file you edited. Confirm the file name is exactly inputs.conf, confirm its directory, inspect the effective input settings with the available Splunk configuration inspection tools, and then restart the forwarder again after corrections.

Verify that events are indexed

After restarting the forwarder, open Splunk Search and run an index-scoped search:

index=remotelogs

This search should return events from the configured Windows host after data reaches the receiver and is indexed. Arrival may take a short time because of service restart timing, network connectivity, receiver processing, the selected time range, and whether new events have been generated.

Field names and source-type values can vary with the forwarder version and configuration. If a source-type search returns nothing, start with index=remotelogs, inspect returned fields such as host, source, and sourcetype, and then use the values actually present. You can also narrow searches by host, source, sourcetype, channel-related fields, event code, account, or time range.

Example: investigate authentication activity

Once Security events are arriving, begin with the dedicated index and a suitable time range. Then narrow the results using the fields present in your data—for example, a host, account, event code, or Security channel source. This staged approach is safer than assuming every Windows deployment uses identical field names.

Troubleshoot collection problems

Events arrive in a different index

If events appear outside remotelogs, inspect each stanza for index = remotelogs. Then check configuration precedence and any routing or receiving rules that might redirect data. An input-level index assignment is the intended setting for this example, but another active configuration layer can override it.

Operational and security considerations

• Protect Security data: Security events can contain sensitive information about users, hosts, authentication, and access activity. Apply suitable index roles and access controls.
• Plan retention: Audit requirements may require longer retention than ordinary troubleshooting logs. Configure retention consistently with policy and legal requirements.
• Estimate volume: Verbose security auditing can produce substantial event volume. Measure a representative host before deploying the configuration widely and allocate storage accordingly.
• Configure the source: The forwarder can only collect events that exist in Windows. Channel enablement, event-log retention, audit policy, and application behavior determine what is available.
• Control scope: Start with the channels and hosts required for the use case. Add additional Windows channels only after reviewing volume, parsing, access, and retention implications.
• Protect transport and administration: Restrict who can modify forwarder configuration and use the organization's approved secure forwarding and certificate practices.

End-to-end checklist

1. Install and start the Universal Forwarder on the Windows endpoint.
2. Configure a receiving Splunk indexer or receiving component and verify connectivity.
3. Create the remotelogs index and establish its retention, access, and storage policies.
4. Confirm the forwarder service account can read Security, Application, and System channels.
5. Create a local inputs.conf with one enabled WinEventLog stanza per channel.
6. Assign index = remotelogs to each stanza.
7. Validate the effective configuration when multiple apps or configuration layers exist.
8. Restart the forwarder service, not Windows.
9. Run index=remotelogs and narrow by host, source, sourcetype, or channel as needed.
10. Investigate missing data in both Splunk and Windows Event Viewer.

For related background, review Monitor Logs Using Forwarders, Windows Inputs, and Collect Event Logs From a Local Windows Machine.