Study guide
14.1 Windows Management Instrumentation (WMI) Inputs
Splunk Enterprise Certified Admin SPLK-1003
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the Splunk Enterprise Certified Admin Exam
2 Chapter 1: Splunk Admin Basics
1.1 Splunk Enterprise Architecture & Core Components
3 Chapter 2: License Management
2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting
4 Chapter 3: Splunk Configuration Files
3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations
5 Chapter 4: Splunk Indexes
4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy
6 Chapter 5: Splunk User Management
5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits
7 Chapter 6: Splunk Authentication Management
6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication
8 Chapter 7: Getting Data In
7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder
9 Chapter 8: Distributed Search
8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)
10 Chapter 9: Getting Data In – Staging
9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options
11 Chapter 10: Configuring Forwarders
10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing
12 Chapter 11: Forwarder Management
11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting
13 Chapter 12: Monitor Inputs
12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives
14 Chapter 13: Network and Scripted Inputs
13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection
15 Chapter 14: Agentless Inputs
14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration
16 Chapter 15: Fine Tuning Inputs
15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data
17 Chapter 16: Parsing Phase and Data
16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview
18 Chapter 17: Manipulating Raw Data
17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue
14.1 Windows Management Instrumentation (WMI) Inputs
Key Takeaways Explain This Topic AI
WMI inputs run as the splunk-wmi.exe process on a Windows Splunk Enterprise instance or a Windows universal or heavy forwarder; instances on Linux or macOS cannot collect WMI data.
wmi.conf input stanzas are [WMI:<name>] and use either event_log_file or wql, never both; interval is required and server defaults to the local machine.
For event log stanzas, current_only = 1 collects only events that occur while Splunk runs, while the default 0 collects everything from the checkpoint.
WQL stanzas do not update the WMI checkpoint, so their results are indexed as fresh data on every run; current_only = 1 marks an event notification query.
Remote WMI needs a domain user (not Local System) with least-permissive DCOM, performance, and WMI namespace rights, and Splunk recommends a universal forwarder on the target when possible.
Last updated: September 2026
Windows Management Instrumentation (WMI) Inputs
Quick Summary: WMI inputs let a Splunk instance running on Windows collect event logs and performance data from remote Windows machines without installing anything on them. The input runs as a separate process, splunk-wmi.exe , and is configured in wmi.conf with [WMI:<name>] stanzas that use either event_log_file or wql . It requires a domain user account with WMI rights, and Splunk itself recommends installing a universal forwarder on the target instead whenever possible.
Where a WMI Input Can Run
WMI (Windows Management Instrumentation) is Microsoft's management interface, and remote WMI uses DCOM/RPC. Splunk's WMI input therefore has to run on a Windows machine:
Splunk Enterprise on Windows can collect WMI data directly.
A universal forwarder or heavy forwarder on Windows can run the WMI input and forward the data. This is also the only way to get WMI data into Splunk Cloud Platform, because Splunk Cloud cannot connect to Windows machines using WMI.
A Splunk instance on Linux or macOS cannot run WMI inputs.
The input runs as a separate process called splunk-wmi.exe , which Splunk's documentation describes as a scripted input. One WMI input can connect to multiple WMI providers (target machines).
How Collection Works (Pull Model)
The Windows Splunk instance reads its [WMI:<name>] stanzas from wmi.conf .
Every interval seconds, splunk-wmi.exe connects to each machine listed in server and runs the event log or WQL query.
The results come back over the network, become events, and are indexed locally or forwarded to the indexers.
All the collection load sits on the polling instance and the network, rather than being spread across the endpoints.
Configuring wmi.conf
wmi.conf lives on the Windows instance that collects the data, for example in %SPLUNK_HOME%\etc\system\local\ or in an app. You can also create WMI inputs in Splunk Web with the Remote event log monitoring and Remote Performance monitoring inputs. Configuration files expose more options. Restart Splunk after editing the file.
The [settings] Stanza (Optional, Global)
- Setting Default Meaning
- initial_backoff 5 Seconds to wait before the first reconnection after an error; doubles on each failure
- max_backoff 20 Maximum wait between reconnection attempts
max_retries_at_max_backoff 2 Attempts at max_backoff before the input gives up on that provider until Splunk restarts
- checkpoint_sync_interval 2 Seconds to wait for event log checkpoint data to be written to disk
- Input Stanzas: [WMI:<name>]
Each input stanza uses one of two types, and never both:
Event log stanza: set event_log_file to a comma-separated list of channels such as Application, System .
WQL stanza: set wql to a Windows Query Language statement. This is how you collect performance data.
If a stanza defines both settings, the input does not run.
- Setting Applies to Default Notes
- server both the local machine Comma-separated list of Windows machines (WMI providers)
- interval both none: required Poll frequency in seconds; without it the input does not run
- disabled both 0 1 disables the input
- index both default index ( main ) Destination index
- hostname both detected automatically Make all results appear to come from this host
- event_log_file event log none Channels to collect
current_only event log 0 1 = only events that occur while Splunk is running; 0 = all events from the checkpoint, or from the oldest event if there is no checkpoint
disable_hostname_normalization event log 0 By default, local names such as localhost are normalized to %COMPUTERNAME%
- wql WQL none The query to run
- namespace WQL root\cimv2 WMI namespace of the provider
- current_only WQL 0 1 = the query is an event notification query; 0 = a standard query
- Example 1: Remote Event Logs [WMI:RemoteAppServerLogs]
- server = app-srv01.corp.example, app-srv02.corp.example
- event_log_file = Application, System
- interval = 60
- current_only = 1
- index = winevent
- disabled = 0
- Example 2: Performance Data with a Standard WQL Query [WMI:DomainControllerCPU]
- server = dc01.corp.example
- wql = SELECT Name, PercentProcessorTime FROM Win32_PerfFormattedData_PerfOS_Processor WHERE Name = '_Total'
- interval = 15
- index = perfmon
- disabled = 0
- Example 3: An Event Notification Query [WMI:ProcessCreation]
- server = app-srv01.corp.example
- wql = SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'
- current_only = 1
- interval = 1
- index = winevent
An event notification query has to be correctly structured. The spec says its WQL must contain a GROUP , WITHIN , or HAVING clause. Badly formed WQL stops the input from running.
Event Logs vs. WQL Data
Event log stanzas keep a checkpoint. After a restart or outage, the input continues from the saved position, so events are not collected twice. With current_only = 1 , events generated while Splunk was stopped are not collected when it starts again.
WQL stanzas do not update the WMI checkpoint file. A WQL query returns dynamic data, so Splunk indexes the results as fresh data every time the stanza runs. A standard query on a static class (such as a list of services) produces the same events again at each interval.
For performance data, prefer the formatted classes ( Win32_PerfFormattedData_* ), which return ready-to-use values such as percentages. The raw classes ( Win32_PerfRawData_* ) return counters that you would have to convert yourself.
Security and Network Prerequisites
Splunk's documentation lists these requirements for remote WMI:
The Splunk instance must run as a domain user in the same Active Directory domain or forest as the targets, with permission to make remote connections and to query WMI. The user must also belong to the local Administrators group on the machine running Splunk.
Local System does not work. It has no access to other machines on the network, and you cannot grant it such access.
The Splunk user should not be a Domain Admin. Splunk recommends least-permissive access instead:
Local Security Policy user rights on each polled machine, such as Access this computer from the network and Log on as a service .
Membership in Distributed COM Users for DCOM access.
Membership in Performance Log Users for remote performance objects.
WMI namespace rights on Root and below: Execute Methods , Enable Account , Remote Enable , Read Security .
For event logs, a group with suitable access, such as Event Log Readers .
Firewalls must allow WMI between the polling machine and the targets. Remote WMI uses the RPC endpoint mapper on TCP 135, followed by a dynamically assigned RPC port. Microsoft's default dynamic range on Windows Server 2008 and later is TCP 49152–65535.
To test access, Splunk documents running splunk cmd splunk-wmi -wql "select * from win32_service" -namespace \\<host>\root\cimv2 as the Splunk user. First, temporarily point the data store elsewhere with splunk set datastore-dir , so the test does not update the real WMI checkpoint.
WMI vs. a Universal Forwarder on the Target
Splunk's own guidance is: if possible, install a universal forwarder on the machine you want to collect Windows data from, rather than using WMI. The resource load of WMI can exceed that of a forwarder, especially when you collect several event logs or performance counters from each machine, or from busy machines such as domain controllers.
- Dimension Remote WMI input Universal forwarder on the target
- Software on target None Universal forwarder
- Collection model Polling every interval seconds Local collection of event logs, performance data, and files
Accounts and permissions Domain user with DCOM, WMI, and event log rights on every target Local service account on each machine
Firewall RPC (TCP 135 plus dynamic ports) from poller to each target One outbound connection to the indexers (for example TCP 9997)
When the target is unreachable Nothing is collected until the provider is reachable again; after repeated errors the input gives up until restart The forwarder keeps reading locally and sends when the indexers are reachable
Delivery to indexers The polling instance forwards the data Can use indexer acknowledgment on its own connection