Documentation: 3.4.1
Print Version Contents
This page last updated: 10/10/08 09:10am

Windows Management Interface (WMI) input

Splunk supports WMI (Windows Management Interface) data input for agentless access to Windows performance data and event logs. This means you can pull event logs from all the Windows servers and desktops in your environment without having to install anything on those machines.

The Splunk WMI data input can connect to multiple WMI providers and pull data from them. The WMI data input runs as a separate process (splunk-wmi.exe) on the Splunk server. It is configured as a scripted input in $SPLUNK_HOME\etc\system\default\inputs.conf. Do not edit this file.

Note: This feature is only available on the Windows versions of Splunk and is NOT enabled by default. To enable it, add the following line to $SPLUNK_HOME\etc\system\local\inputs.conf:

[script://$SPLUNK_HOME\bin\scripts\splunk-wmi.py]
disabled = 0

Important: There is an issue with stopping and restarting Splunk currently affecting users of remote WMI polling. If one or more of your WMI sources is unavailable at the time that you stop Splunk, Splunk will not come back up unless you wait for the splunk-wmi.exe process to exit, or kill it manually. To avoid this issue, do not unnecessarily list non-existent/non-functioning machines in wmi.conf.

Security and remote access considerations

Splunk requires privileged access to index many Windows data sources, including WMI, Event Log, and the registry. This includes both the ability to connect to the box, as well as permissions to read the appropriate data once connected. To access WMI data, Splunk must run as a user with permissions to perform remote WMI connections. This user name must be a member of an Active Directory domain and must have appropriate privileges to query WMI. Both the Splunk server making the query and the target systems being queried must be part of this Active Directory domain.
Note: If you installed Splunk as the LOCAL SYSTEM user, WMI remote authentication will not work; this user has null credentials and Windows servers normally disallow such connections.

There are several things to consider:

  • For remote data collection via WMI, the Splunk service must run as a user who has sufficient OS privileges to access the WMI resources you wish to poll. At a minimum, Splunk requires access to the following privileges on every machine you poll:
    • Profile System Performance
    • Access this Computer from the Network
    • The simplest way to ensure Splunk has access to these resources is to add Splunk's user to the Performance Log Users and Distributed COM Users Domain groups. If these additions fail to provide sufficient permissions, add Splunk's user to the remote machine's Administrators group.
  • You must enable DCOM for remote machine access, and it must be accessible to Splunk's user. See the Microsoft topic about Securing a Remote WMI Connection for more information. Adding Splunk's user to the Distributed COM Users local group is the fastest way to enable this permission. If this fails to provide sufficient permissions, add Splunk's user to the remote machine's Administrators group.
  • The WMI namespace that Splunk accesses (most commonly root\cimv2) must have proper permissions set. Enable the following permissions on the WMI tree at root for the Splunk user:
  • If you have a firewall enabled, you must allow access for WMI. If you are using the Windows Firewall, the exceptions list explicitly lists WMI. You must set this exception for both the originating and the remote machine. See the Microsoft topic about Connecting to WMI Remotely Starting with Vista for more details.

Test access to WMI

Follow these steps to test the configuration of the Splunk server and the remote machine:

1. Log into the machine Splunk runs on as the user Splunk runs as.
2. Click Start -> Run and type wbemtest. The wbemtest application starts.
3. Click Connect and type \\<server>\root\cimv2, replacing <server> with the name of the remote server. Click Connect. If you are unable to connect, there is a problem with the authentication between the machines.
4. If you are able to connect, click Query and type select * from win32_service. Click Apply. After a short wait, you should see a list of running services. If this does not work, then the authentication works, but the user Splunk is running as does not have enough privileges to run that operation.

Configure WMI input

Look at wmi.conf to see the default values for the WMI input. If you want to make changes to the default values, edit a copy of wmi.conf in $SPLUNK_HOME\etc\system\local\. Only set values for the attributes you want to change for a given type of data input. Refer to How configuration files work for more information about how Splunk uses configuration files.

[settings]
initial_backoff = 5
max_backoff = 20
max_retries_at_max_backoff = 2
result_queue_size = 1000
checkpoint_sync_interval = 2
heartbeat_interval = 500

[WMI:AppAndSys]
server = foo, bar
interval = 10
event_log_file = Application, System, Directory Service
disabled = 0

[WMI:LocalSplunkWmiProcess]
interval = 5
wql = select * from Win32_PerfFormattedData_PerfProc_Process where Name = "splunk-wmi"
disabled = 0

The [settings] stanza specifies runtime parameters. The entire stanza and every parameter within it are optional. If the stanza is missing, Splunk assumes system defaults.

  • The following attributes control how the agent reconnects to a given WMI provider when an error occurs. All times are in seconds:
    • initial_backoff: how much time to wait the first time after an error occurs before trying to reconnect. Thereafter, if errors keep occurring, the wait time doubles, until it reaches max_backoff.
    • max_backoff: the maximum amount of time to wait before invoking max_retries_at_max_backoff.
    • max_retries_at_max_backoff : if the wait time reaches max_backoff, try this many times at this wait time. If the error continues to occur, Splunk will not reconnect to the WMI provider in question until the Splunk services are restarted.
  • result_queue_size: size of the queue that ensures that WMI providers don't end up blocking while waiting for data to be written to the output. Results received from the WMI providers are put into this queue.
  • checkpoint_sync_interval: minimum wait time for state data (event log checkpoint) to be written to disk. In seconds.
  • heartbeat_interval: the thread that manages the connection to WMI providers will execute at this interval. In milliseconds.

You can specify two types of data input: event log, and raw WQL (WMI query language) The event log input stanza contains the event_log_file parameter, and the WQL input stanza contains wql.

The common parameters for both types are:

  • server: a comma-separated list of servers from which to pull data. If this parameter is missing, Splunk assumes the local machine.
  • interval : how often to poll for new data, in seconds. Required.
  • disabled: indicates whether this feature is enabled or disabled. Set this parameter to 1 to disable WMI input into Splunk.

WQL-specific parameters:

  • namespace: specifies the path to the WMI provider. The local machine must be able to connect to the remote machine using delegated authentication. This attrbitue is optional. If you don't specify a path to a remote machine, Splunk will connect to the default local namespace (\root\cimv2), which is where most of the providers you are likely to query reside. Microsoft provides a list of namespaces for Windows XP and later versions of Windows.
  • wql: provides the WQL query. The example above polls data about a running process named splunkd every 5 seconds.

Event log-specific parameter:
event_log_file: specify a comma-separated list of log files to poll in the event_log_file parameter. File names that include spaces are supported, as shown in the example.

Fields for WMI data

All events received from WMI have the source set to wmi.

  • For event log data, the source type is set to WinEventLog:<name of log file> (for example WinEventLog:Application).
  • For WQL data, the the source type is set to the name of the config stanza (for example, for a stanza named [WMI:LocalSplunkdProcess], the field is set to WMI:LocalSplunkProcess).

The host is identified automatically from the data received.

Previous: Windows inputs    |    Next: Windows registry input

Comments

  1. Additional notes on configuring remote WMI polling:
    You may explicitly configure the domain user to do the WMI polling.
    To do this, you need to configure Splunkd & SplunkWeb windows services to log on as the desire user. (Need to restart services after configuration)

    Additional notes on testing remote WMI access using wbemtest:
    You should select Asynchronous in the Method Invocation Options to test remote WMI access.
    Since splunk-wmi.py uses AsyncCall to poll WMI data from the remote servers, the WMI query responses initiated from the remote servers may get blocked by some firewalls (including windows firewall). If it is the case you need to add additional rules to your firewalls to allow the traffic to pass through.

  2. MichaelE: The WMI scripts will only work on windows since the scripts are calling the WMI service to make the query of the remotes system(s). I've added a note to this page explicitly stating that you need a Splunk instance on Windows to poll this data. remember that you can have a this Windows instance forward the WMI data on to your indexer which can be running on any of the supported operating systems.

  3. Where are the scripts for this? I've just updated to 3.3.3 and there are no other .py scripts in $SPLUNKHOME/bin/scripts/ other than echo.sh. The more I read this page the more I 'infer' that this is only for Splunk on Windows. Is this true? Documentation needs to be made more clear on this.

  4. spencer205: as far as i know, Splunk does not support this capability yet. if this is something you'd like to see in a future release, you're welcome to email support@splunk.com with an enhancement request. thanks!

  5. How do you configure the user name and password to use when connecting? WMI can make connections using alternative credentials then the ones that the current process is running as, so it seems plausible to me that a stanza should allow one to pass in a user name and password parameter to use when connecting. For example, something like this:

    [WMI:Foobar]
    server = 192.168.0.2
    interval = 10
    event_log_file = Application
    username = johnd
    password = changeme
    disabled = 0

Log in to comment.