Monitoring Windows Data Inputs with Splunk

Learn how Splunk collects Windows event logs, performance counters, WMI data, Registry changes, and Active Directory activity, and when to use WMI or a universal forwarder.

Splunk can ingest many kinds of Windows telemetry, including operational events, security audits, configuration changes, directory activity, and performance measurements. A Windows input is a Splunk data-collection source or configuration that gathers this telemetry from a Windows system.

This lesson compares local collection, remote collection with Windows Management Instrumentation (WMI), and collection through a Splunk universal forwarder. It also shows representative configurations, validation searches, selection criteria, and troubleshooting checks.

Windows input categories

The main Windows input categories are Windows Event Logs, performance counters, WMI-based remote monitoring, Registry monitoring, and Active Directory monitoring.

Input type	Primary data collected	Typical source	Common use cases	Local or remote collection
Windows Event Logs	Operating system, application, and security events	Windows Event Log service and its channels	Security auditing, troubleshooting, account activity, system health	Local with a collector or remote through WMI
Performance counters	Measurements such as CPU, memory, disk, network, processes, and services	Windows Performance Monitor	Capacity planning, saturation detection, performance investigation	Local or remote, depending on the collection method
WMI	Management data, event logs, and selected performance information	Remote Windows management interfaces	Targeted agentless monitoring	Primarily remote
Registry monitoring	Changes to selected Registry keys and values	Windows Registry	Configuration auditing, persistence detection, troubleshooting	Local on the monitored host; a forwarder can send it centrally
Active Directory monitoring	Changes to users, groups, computers, and Group Policy objects	Domain controllers and Windows security or directory auditing	Privilege-change detection, account lifecycle auditing, policy monitoring	Usually collected from domain controllers

Local collection and remote collection

Local collection runs the data collector on the Windows host that owns the data. For example, a universal forwarder installed on a server can read that server's event logs and Registry, collect selected counters, and forward the results to Splunk.

Remote monitoring retrieves data across the network from another Windows host. WMI is a common method for remote access. Remote collection avoids installing software on every target, but it introduces dependencies on network paths, authentication, permissions, services, and firewall rules.

Windows Event Log collection

A Windows Event Log is a record produced by the operating system, an application, or a security-auditing component. The Windows Event Log service manages these records and organizes them into channels.

Common channels include Application, System, and Security. Windows roles and installed applications can add custom channels, so inspect Event Viewer in the target environment before configuring collection.

Application: application errors, warnings, and informational messages.
System: operating-system services, drivers, hardware, and startup events.
Security: logons, account changes, policy events, and other audited activity.
Custom channels: events produced by specific roles, products, or applications.

Event logs support security auditing, system-health investigation, application troubleshooting, and account-activity monitoring. A local input reads channels directly from the host. Remote event-log collection is possible, but a forwarder on the source generally provides better source context and reduces repeated remote polling.

Local Event Log configuration

The following is a representative inputs.conf configuration for a Windows Splunk collector or universal forwarder. Input stanza names identify the channel. The index controls destination, while the sourcetype identifies the data format. Filtering options should be added only when they are supported by the installed Splunk version and the collection objective.

[WinEventLog://Application]
disabled = 0
index = windows
sourcetype = WinEventLog:Application

[WinEventLog://Security]
disabled = 0
index = windows
sourcetype = WinEventLog:Security
renderXml = true

After enabling the configuration and restarting or refreshing the relevant Splunk component, validate arrival with a search such as:

index=windows sourcetype=WinEventLog:Security | stats count by host, source

For a local collection exercise, first confirm that the channel exists and contains events in Event Viewer. You can also follow the focused lesson collecting event logs from a local Windows machine.

Windows performance monitoring

Performance Monitor exposes Windows measurements as performance counters. A counter is a measurable metric organized under an object and, often, an instance. Examples include processor utilization, available memory, disk activity, network traffic, process counts, and service-related measurements.

Splunk can collect available Windows performance counters. Counter selection, collection interval, and instance selection determine both usefulness and data volume. Collecting every counter at a short interval can create unnecessary indexing load; start with a focused baseline and expand it when the monitoring question requires more detail.

Performance counter configuration

[Perfmon://CPU]
object = Processor
counters = % Processor Time
instances = _Total
interval = 60
index = windows
sourcetype = Perfmon:CPU

[Perfmon://Memory]
object = Memory
counters = Available MBytes
instances = 
interval = 60
index = windows
sourcetype = Perfmon:Memory

[Perfmon://Disk]
object = PhysicalDisk
counters = % Disk Time,Current Disk Queue Length
instances = _Total
interval = 60
index = windows
sourcetype = Perfmon:Disk

[Perfmon://Network]
object = Network Interface
counters = Bytes Total/sec
instances = *
interval = 60
index = windows
sourcetype = Perfmon:Network

Object and counter names can differ by Windows version, language, installed roles, and hardware. Confirm names with Performance Monitor before deployment. An empty or wildcard instance setting has different practical effects by counter; use a specific instance when a stable aggregate is available. See collecting performance counters for a focused walkthrough.

Remote monitoring through WMI

Windows Management Instrumentation (WMI) is a Windows management framework that allows management applications to obtain information from Windows systems and interact with management objects. Splunk can use WMI to access selected remote event-log and performance data.

Remote WMI collection depends on all of the following:

Network reachability and correct name resolution.
Credentials and an authentication method accepted by the target.
Permissions to access the requested WMI namespace and data.
Availability of WMI and related remote-management services.
Firewall rules that permit the required management communication.

Representative WMI configuration

WMI input syntax and supported properties vary between Splunk releases and Windows input implementations. Treat the following as a configuration pattern: verify the stanza type, property names, namespace, and query format against the documentation for the installed version before enabling it. Protect credentials and use a dedicated least-privilege account.

[WMI:RemoteSecurityEvents]
server = win-app-02.example.internal
namespace = root\cimv2
type = eventlog
event_log_file = Security
interval = 60
index = windows
sourcetype = WinEventLog:Security

[WMI:RemotePerf]
server = win-app-02.example.internal
namespace = root\cimv2
type = perfmon
object = Processor
counter = % Processor Time
instance = _Total
interval = 60
index = windows
sourcetype = Perfmon:CPU

Some implementations use a saved credential or authentication context rather than placing a password in inputs.conf. Do not put reusable secrets in ordinary configuration examples or source control. Before enabling the input, test DNS, TCP reachability, the WMI service, firewall policy, authentication, and namespace permissions.

WMI is useful for a small number of carefully selected targets or environments where software installation is restricted. At larger scale, frequent remote polling can increase connection overhead and create a central dependency on network and target availability.

Windows Registry monitoring

The Windows Registry is a hierarchical configuration database containing system, application, user, and policy settings. Registry monitoring tracks changes to selected keys or values. Those changes can reveal configuration drift, startup persistence, unauthorized software behavior, or the cause of an application problem.

Registry monitoring configuration

Scope Registry monitoring narrowly. High-churn locations can produce large amounts of low-value data. The exact WinRegMon attributes and supported event types must be verified for the installed Splunk version; the example below shows the important concepts, including an explicit hive and a selected key path.

[WinRegMon://StartupRunKeys]
hive = HKEY_LOCAL_MACHINE
key = Software\Microsoft\Windows\CurrentVersion\Run
type = SetValue
proc = .*
disabled = 0
index = windows
sourcetype = WinRegMon

Depending on the release, the key path may be represented in the stanza name or by a separate path property, and the change-type property may use a different supported value. Validate the final stanza with the target version's input reference and configuration inspection tools. Monitor only keys or values that support a defined audit, detection, or troubleshooting objective.

Active Directory monitoring

Active Directory is Microsoft's directory service for managing identities, devices, groups, and policies in Windows domains. Splunk can audit modifications to user objects, group objects, computer or machine objects, and Group Policy objects. Group Policy is the centralized configuration applied to Windows users and computers in a domain.

Useful security and operational questions include:

Who added or removed a member from a privileged group?
Which accounts were created, disabled, enabled, or modified?
Which computer objects changed?
Who changed a Group Policy object or policy setting?

Directory auditing depends on the relevant audit policies being enabled and the applicable security or directory events being collected from domain controllers. Collecting only workstation logs will not provide complete visibility into domain-wide directory changes.

index=windows (sourcetype=WinEventLog:Security OR sourcetype=WinEventLog:DirectoryService)
| search EventCode IN (4728,4729,4732,4733,5136,5137,5141)
| stats count by host, EventCode, SubjectUserName, TargetUserName

The exact event IDs and field availability depend on the auditing configuration and Windows version. Build searches around the events your domain controllers actually produce, and test additions and removals in a controlled environment.

Universal forwarder for Windows collection

A universal forwarder is a lightweight Splunk component designed to gather local data and send it to a Splunk receiving or indexing tier. It contains the essential forwarding functions, not the full indexing and search capabilities of a Splunk instance.

Installing universal forwarders on remote Windows hosts is generally the most efficient approach for broad Windows monitoring. A forwarder can read local event logs, Registry changes, performance counters, and other configured inputs before transmitting them centrally. This distributes collection work, reduces reliance on remote polling, preserves source-host context, and usually scales better across segmented networks.

Forwarder installation and enrollment example

Install the Windows universal forwarder on each source host, enroll it with the receiving deployment, and enable only the required inputs. The exact installer switches and management-port settings depend on the deployment design. A representative command pattern is:

msiexec /i splunkuniversalforwarder.msi AGREETOLICENSE=Yes RECEIVING_INDEXER=splunk-indexer.example.internal:9997 /quiet

Configure the forwarder's receiving target in its deployment or output configuration, then place selected Windows input stanzas in the forwarder's local configuration. For example:

[WinEventLog://Security]
disabled = 0
index = windows
sourcetype = WinEventLog:Security

[Perfmon://CPU]
object = Processor
counters = % Processor Time
instances = _Total
interval = 60
index = windows
sourcetype = Perfmon:CPU

Confirm that the receiver is listening on the configured port, the forwarder service is running, and the host can reach the receiver. Then search for the host's data:

index=windows host=WIN-SERVER-01 | stats count by sourcetype, source

Related guidance is available in install a Splunk forwarder on Windows, monitor logs using forwarders, and what forwarders are.

Remote WMI collection versus universal forwarder collection

Criterion	Remote WMI	Universal forwarder	Recommended use
Host count	Convenient for a small, targeted set	Better for many source hosts	Prefer forwarders for broad deployment
Network design	Requires inbound management access to targets	Usually requires outbound access from sources to the receiver	Choose the path allowed by segmentation policy
Administration	No agent installation, but credentials and remote permissions require management	Requires software installation and lifecycle management	Use WMI where installation is prohibited; use forwarders where deployment is manageable
Reliability	Central polling is sensitive to network and target interruptions	Collection occurs at the source and can use configured queues and buffering	Prefer forwarders for continuous monitoring, with capacity limits understood
Security	Protect credentials and restrict WMI namespaces and firewall access	Secure forwarder-to-receiver traffic and limit forwarder privileges	Apply least privilege to either design
Data types	Best for supported remote event and management data	Broad local input coverage, including Event Logs and Registry monitoring	Use the method that supports the required telemetry

Choosing a Windows collection method

Choose local collection with a forwarder when the host count is large, source context matters, network segments limit inbound management access, or continuous event and Registry monitoring is required.
Choose remote WMI for targeted monitoring when agent installation is not practical and the organization can provide secure network reachability, authentication, permissions, and firewall rules.
Choose a local collector without forwarding only when the Splunk component is intentionally installed on that Windows system and the architecture supports its resource and security requirements.

Also consider bandwidth, event volume, retention, administrative access, credential handling, operating-system diversity, and the data types required. A low-volume periodic query may be suitable for WMI, while high-volume security logs and many performance streams usually benefit from distributed forwarders.

Windows monitoring use cases by data source

Use case	Recommended Windows input	Example data	Operational or security value
Logon and account auditing	Security Event Log	Successful and failed logons, account changes	Investigate access and detect suspicious activity
Server capacity planning	Performance counters	CPU, available memory, disk queue, network throughput	Identify trends and resource saturation
Application troubleshooting	Application Event Log and selected counters	Application errors, latency-related resource pressure	Correlate failures with host conditions
Persistence detection	Registry monitoring	Changes to selected startup-related keys	Detect unauthorized startup configuration
Privilege-change detection	Active Directory and Security auditing	Privileged group membership changes	Detect identity and access-control changes
Policy auditing	Directory and Security event collection	Group Policy object modifications	Track configuration governance and unexpected policy changes

Troubleshooting Windows inputs

Event Logs are not appearing

Confirm that the intended channel exists and contains events.
Verify that the collector or forwarder service is running.
Check input enablement, index, sourcetype, and filtering settings.
If using a forwarder, verify connectivity to the receiving endpoint and inspect forwarder logs.

Remote WMI monitoring fails

Test name resolution and network reachability to the target.
Verify WMI and required remote-management services are running.
Confirm firewall rules permit the required communication.
Validate credentials, authentication, namespace access, and WMI permissions.

Performance data is missing

Confirm that the object, counter, and instance exist on the target Windows version.
Check spelling, localization, and wildcard behavior.
Review the interval and whether the counter returns usable values.
Ensure the collection account can access performance data.

Registry monitoring is too noisy

Reduce monitoring to specific keys or values.
Exclude high-churn locations unrelated to the objective.
Decide whether every detected change needs indexing and retention.

Active Directory changes are missing

Confirm auditing is enabled for the directory activities of interest.
Verify the applicable Security or Directory Service events are collected.
Check that the correct domain controllers are sending data.
Confirm the search index and time range.

Universal forwarder data does not arrive

Verify that the forwarder service is running.
Confirm the receiver address and port.
Test network connectivity from the Windows host to the receiver.
Review forwarder logs and verify that required inputs are enabled.

Exam-relevant notes

Windows Event Logs are managed by the Windows Event Log service and are organized into channels.
Performance counters measure resources through Performance Monitor; interval and instance choices affect volume.
WMI is an agentless remote-management approach, but it depends on network, credentials, permissions, services, and firewall configuration.
A universal forwarder is lightweight and forwards locally collected data; it is not a full Splunk indexing and search instance.
Forwarders are generally preferred for broad remote-host monitoring, while WMI is often reserved for targeted or agent-restricted situations.
Registry and Active Directory monitoring must be scoped and audited deliberately to produce useful data.