VMware ESXi and vSphere Cluster Management

Windows Inputs in Splunk

Learn how Splunk collects Windows Event Logs, performance data, Registry changes, WMI data, and Active Directory modifications using local, remote, and universal forwarder approaches.

Splunk can ingest several kinds of data from Windows systems, including operating-system events, application events, security records, configuration changes, directory changes, and performance measurements. This lesson explains the Windows data sources available to Splunk and the mechanisms used to collect them.

A data source is the information being monitored, such as the Security event channel or a Registry key. A collection mechanism is how that information reaches Splunk, such as local collection, remote WMI polling, or a universal forwarder. Keeping these concepts separate makes collection designs easier to plan.

Windows input types at a glance

Splunk supports several Windows input categories. Some inputs read data directly on the Windows host. Others obtain information remotely through Windows management interfaces. The same general data type may therefore be collected through different deployment designs.

Input type	Data collected	Local or remote use	Typical purpose	Recommended collection mechanism
Windows Event Logs	Operating system, application, security, and other event-channel records	Local collection or remote collection depending on architecture	Operational troubleshooting, security analysis, and compliance	Universal forwarder for endpoint-local collection; WMI or another supported remote design where appropriate
Performance monitoring	Performance Monitor counters, instances, and measurements	Local or remote	Trend resource and application health	Universal forwarder for broad endpoint coverage; WMI for suitable remote polling
Remote WMI monitoring	Management information, including selected logs and performance information	Remote by design	Agentless-style monitoring of reachable Windows systems	Direct WMI collection from a properly authorized collector
Registry monitoring	Changes to selected Registry keys or values	Primarily local; remote endpoints use a forwarder	Configuration-change visibility and auditing	Universal forwarder installed on the monitored Windows host
Active Directory monitoring	Modifications to users, groups, computers, and Group Policy objects	Collected from systems that generate the relevant directory records	Identity, privilege, policy, and directory-change auditing	Collect the appropriate Windows or domain-controller data with a suitable local collector

Windows Event Log collection

The Windows Event Log is the Windows service and event-channel system that records operating-system, application, security, and other events. Splunk can collect events produced by this service and make them available for search, alerting, dashboards, and investigations.

Local event-log collection

With local collection, the collecting component runs on the Windows machine where the event data resides. A typical workflow is:

Identify the Windows host that contains the required events.
Select the relevant event channels, such as Application, System, or Security, plus any additional channels used by the organization.
Confirm that the collecting component can read those channels.
Assign the intended host identity and source and sourcetype values according to the Splunk data model used by the environment.
Send the events to the intended receiving or indexing destination.

Do not assume that every environment uses the same channel set. Windows versions, installed roles, applications, and security products can create additional channels. Select channels based on the questions the data must answer.

Remote event-log collection

Event-log data can also be gathered from another Windows machine. The collection architecture determines whether the collector reads the remote system through WMI or whether a universal forwarder runs locally on that system and sends the data outward. A local forwarder generally avoids repeated remote polling and places collection closer to the source.

Windows performance monitoring

Performance Monitor is a Windows facility that exposes measurements called performance counters. A performance counter is a numeric measurement for a system, service, process, device, or other monitored object. Examples include processor utilization, memory activity, disk activity, and network-related measurements.

Performance data is time-series data: values are collected repeatedly at defined intervals. A useful configuration identifies:

Object: the category being measured, such as a processor or disk object.
Counter: the specific numeric measurement.
Instance: the particular processor, disk, process, or other object instance when more than one exists.
Collection interval: how often Splunk requests or receives a measurement.
Destination: the Splunk receiving and indexing path for the resulting data.

The counters available to Windows Performance Monitor are the basis for the performance data Splunk can collect. Before configuring an input, verify that the desired object, counter, and instance exist on the target Windows version and installed roles.

Performance counter example

To monitor server health, select CPU, memory, disk, and network-related counters, choose the required instances, and set an interval appropriate for the use case. A short interval can reveal rapid resource pressure but creates more data. A longer interval reduces volume and is often sufficient for capacity trends.

Remote monitoring through WMI

WMI means Windows Management Instrumentation. It is a Windows management framework that makes management information available to management applications. A collector can use WMI to obtain selected log and performance information from remote Windows machines.

What remote WMI requires

Remote WMI is not simply a switch in Splunk. It depends on the Windows and network environment:

Network reachability between the collector and the target Windows host.
Credentials that are valid for the remote system.
Authorization to query the required WMI namespaces, classes, logs, or performance information.
Working WMI services and remote-management configuration.
Firewall rules and organizational policies that permit the required traffic.

A remote WMI configuration identifies the target host, selects the WMI query or class concept needed for the data, supplies appropriate credentials, and defines the destination for the collected results. Exact settings depend on the Windows and Splunk versions and the organization’s security model.

WMI compared with endpoint collection

Direct WMI collection polls the remote host across the network. A universal forwarder instead runs on the endpoint, reads local sources, and transmits the results to Splunk. WMI can be useful when installing software on endpoints is not practical and remote management is already approved. A forwarder is usually more efficient for broad coverage because it reduces centralized polling and can collect endpoint-local sources such as Registry changes.

Windows Registry monitoring

The Windows Registry is a hierarchical Windows configuration database. Registry monitoring watches selected keys or values and records changes to them. This makes it a configuration-change and auditing data source rather than a general-purpose dump of the entire Registry.

Effective Registry monitoring requires a deliberately chosen scope. Select locations that matter to security, application configuration, startup behavior, or operational control. Define whether the monitoring target is a key, a value, or both, and understand which change events the input reports. Monitoring too broadly can create unnecessary volume and obscure important changes.

Registry data from remote Windows systems is commonly collected by installing a universal forwarder on each monitored endpoint. The forwarder watches the selected local Registry locations and sends change data to the configured Splunk receiving tier.

Active Directory monitoring

Active Directory is a Microsoft directory service containing identity, computer, group, and policy-related objects. Splunk can support auditing of modifications made to directory objects by collecting the relevant Windows records from the systems that generate them, commonly directory infrastructure such as domain controllers.

Important object categories include:

Object type	Example change	Audit value
User	Create, disable, delete, or change account attributes	Supports identity and account-lifecycle investigations
Group	Add or remove a member, or change group attributes	Helps identify privilege and access changes
Computer or machine	Create, delete, move, or modify a computer object	Provides visibility into domain-joined asset changes
Group Policy object	Create, link, modify, or remove a policy object	Supports policy and configuration auditing

A Group Policy object is an Active Directory object used to define and apply policy settings. Directory modifications and the records that describe them are generated by particular Windows systems and directory services. Therefore, collection must include the appropriate infrastructure systems, and auditing must be enabled where the relevant records are produced.

Universal forwarders for remote Windows collection

A universal forwarder is a lightweight Splunk component that gathers data and sends it to Splunk. It contains the essential forwarding components rather than the full search and indexing capabilities of a Splunk search head or indexer.

For remote Windows hosts, the general approach is to install a universal forwarder on each endpoint that must be monitored. The forwarder can collect local Event Logs, performance counters, and selected Registry changes before transmitting them to a receiving tier. This design is usually the most efficient way to gather data from a large number of Windows hosts.

Deployment workflow

Install the lightweight forwarder on each remote Windows host to be monitored.
Configure the required Windows inputs on the forwarder.
Configure forwarding to the intended Splunk receiving tier.
Confirm that the forwarder service is running and permitted to read the selected sources.
Validate that data arrives with the expected host identity, source, and sourcetype.

Choosing a collection approach

Method	How collection occurs	Best use case	Key dependencies	Strengths	Considerations
Universal forwarder on the Windows host	A local endpoint component reads Windows sources and forwards the data	Broad, continuous collection from managed endpoints	Software deployment, forwarder administration, endpoint permissions, and network path to Splunk	Efficient at scale; close to the data source; suitable for Event Logs, performance data, and Registry monitoring	Requires installation and lifecycle management on each endpoint
Remote WMI monitoring	A collector queries another Windows host across the network	Reachable systems where remote management is approved and endpoint installation is unsuitable	Connectivity, credentials, authorization, WMI health, firewall rules, and remote-management policy	Avoids installing a collector on every target	Centralized polling can be less efficient at scale and is sensitive to network and permission failures

Use local collection when the collector is on the source host and endpoint control is available. Use remote WMI when the target is reachable, the required information is exposed through WMI, and security policy permits the access. For extensive remote-host coverage, local endpoint collection through universal forwarders is generally preferred because it scales more efficiently and supports endpoint-local sources.

Base the decision on scale, endpoint reachability, administrative control, data type, security requirements, and collection efficiency. Also consider ownership: a forwarder requires endpoint deployment and updates, while WMI requires centralized credentials, permissions, and reliable remote connectivity.

Configuration planning examples

Local Windows Event Logs

Choose the local Windows host as the input host, select the required event channels, and define the host, source, and sourcetype values used by your Splunk environment. Route the resulting events to the intended receiving and indexing path. Validate both event arrival and field extraction before expanding the channel selection.

Performance counters

Select the Performance Monitor objects, counters, and instances that answer the monitoring question. Set a collection interval, identify the target Windows host, and configure the destination indexing settings. Test the selected counters in Windows Performance Monitor first so that unavailable or incorrectly scoped counters are not mistaken for Splunk failures.

Remote WMI

Identify the remote target, choose the required WMI query or class, configure credentials with only the permissions needed, and verify network and firewall prerequisites. Start with one target host and a narrow query before scaling the configuration.

Registry monitoring with a forwarder

On each endpoint, select relevant Registry keys or values and configure the local monitoring scope in the universal forwarder. Forward the resulting change events to Splunk. Avoid monitoring the entire Registry unless there is a clearly justified requirement.

Troubleshooting Windows inputs

Expected Event Log events do not appear

Confirm that the desired event channel is enabled for collection.
Confirm that the Windows Event Log service is available on the host.
Verify that the collecting component can read the relevant event log.
Verify forwarding and destination connectivity.

Performance data is missing or has no values

Confirm that the selected counter exists in Windows Performance Monitor.
Check whether the counter requires a specific instance.
Verify availability on the target Windows version and installed role.
Review the configured collection interval.

Remote WMI monitoring fails

Verify network reachability between the collector and remote host.
Verify credentials and authorization for WMI access.
Confirm that WMI is functioning on the remote host.
Check firewall and remote-management policy requirements.

Remote Registry changes are not collected

Confirm that a universal forwarder is installed and running on each endpoint.
Verify that the intended Registry locations are included in the monitoring scope.
Confirm that the forwarder can send data to its configured destination.

Active Directory modifications are absent

Confirm that auditing is enabled where the relevant directory-change records are generated.
Verify collection from the appropriate Windows or directory infrastructure systems.
Confirm that the monitored object categories include the required users, groups, computers, and Group Policy objects.

Exam-relevant notes

Windows Event Logs, performance counters, Registry changes, and Active Directory modifications are data sources; local collection, WMI, and universal forwarders are collection approaches.
WMI stands for Windows Management Instrumentation and supports remote management access, but it depends on connectivity, credentials, authorization, and firewall policy.
A universal forwarder is lightweight forwarding software, not a full Splunk search-and-indexing platform.
For broad remote Windows coverage, deploying universal forwarders on the endpoints is generally the preferred approach.
Performance counter availability in Windows Performance Monitor determines which performance measurements can be collected.
Active Directory monitoring depends on collecting the records from the Windows systems or domain controllers that generate the relevant directory-change events.

For a focused reference, continue with Windows Inputs.