Splunk® Enterprise

Getting Data In

Download manual as PDF

This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Considerations for deciding how to monitor remote Windows data

This topic discusses the considerations you must take when using Splunk Enterprise to gather remote Windows data.

Remote Windows data overview

Splunk Enterprise collects remote Windows data for indexing in one of two ways:

  • from Splunk forwarders
  • via Windows Management Instrumentation (WMI)

Use a forwarder to collect remote Windows data

Use a universal forwarder to gather remote Windows data whenever possible. These are the advantages of using a universal forwarder:

  • The universal forwarder uses minimal network and disk resources on the installed machines.
  • You can install a universal forwarder as a non-privileged user, whereas you require administrative access for WMI.
  • If you install the universal forwarder as the Local System user, then it has administrative access to the machine and requires no authentication to get data from there, as WMI does.
  • It scales well in large environments and is easy to deploy. You can deploy it manually, with either a Microsoft deployment tool like System Center Configuration Manager (SCCM) or Systems Management Server (SMS), or a third party distribution solution such as BigFix/Tivoli.

After you install a universal forwarder, it gathers information locally and sends it to a Splunk Enterprise indexer. You tell the forwarder what data to gather either during the installation process or later, by distributing configuration updates manually or with a deployment server. You can also install add-ons into the universal forwarder.

There are some drawbacks to using the universal forwarder, depending on your network configuration and layout. See "Forwarders versus remote collection through WMI" in this topic.

Use WMI to collect remote Windows data

The Windows Management Instrumentation (WMI) framework lets Splunk Enterprise collect virtually any kind of data from remote Windows machines. In this configuration, Splunk Enterprise runs as a user that you specify at installation (or later on, in the Services control panel).

This configuration:

  • Gives Splunk Enterprise as much access to the network as the specified account has for remote access.
  • Lets indexers collect data from remote Windows machines across the enterprise and place that data into a central repository.
  • Is ideal for small to medium-sized networks with at least one indexer in each network segment

There are some caveats to this method of collection. See "Forwarders versus WMI" in this topic.

Note: While Active Directory (AD) monitoring does not use WMI, it has the same authentication considerations as data inputs that do use it. For information on how Splunk Enterprise monitors AD, see "Monitor Active Directory" in this manual.

Considerations for getting data over WMI

When collecting remote Windows data over WMI, consider the following:

Authentication for remote Windows data

Windows requires authentication for remote operations. Failure to understand how Splunk Enterprise interacts with Windows over the network can lead to suboptimal search results, or none at all. This section provides guidelines on security for collecting remote Windows data.

When you install Splunk Enterprise, you can specify that it run as the Local System user, or another user. This choice has ramifications for both installation and data collection.

The user you tell Splunk Enterprise to run as determines the type and amount of data it can retrieve from remote machines. To get the data you want, you must provide an appropriate level of permission to this user.

In most cases, configure the Splunk Enterprise user account with "least-permissive" access to the data sources you want to collect. This entails:

  • Adding the user to various domain security groups.
  • Making changes to the access control lists of various AD objects, depending on the data sources you need to access.

If your AD domain security policy enforces password changes regularly, you must also:

  • Make sure that either the Splunk Enterprise user password never expires, or that you manually change the password before it expires, as defined by the password policy.
  • Restart Splunk services that run as that account on all hosts in your network, once you change the password.

Note: On recent versions of Windows Server, you can use managed service accounts (MSAs) to address issues with password expiry. See "Managed service accounts on Windows Server 2008 and Windows 7" in the Installation manual.

You should also assign the Splunk Enterprise account the "Deny log on locally" user rights assignment in Local Security Policy to prevent the user from logging in interactively to workstations. It does not need to do so to collect Windows data.

This method gives you more control and is more secure than handing out domain administrator access.

Individual Getting Data In topics in this manual that deal with remote access to Windows machines contain additional information and recommendations on how to configure the user Splunk Enterprise runs as for least-permissive access. Review the "Security and remote access considerations" section on those pages.

Network and I/O usage considerations

Monitor network bandwidth usage closely, especially in networks with slow or thin WAN links. For this reason alone, universal forwarders are a better choice for large remote collection operations.

Disk bandwidth is a concern as well. Anti-virus scanner drivers and drivers that intermediate between Splunk Enterprise and the operating system should always be configured to ignore the Splunk Enterprise directory and processes, regardless of the type of installation.

Splunk forwarders versus WMI

Use a universal forwarder to get data in from a remote Windows host. A universal forwarder offers the most types of data sources, provides more detailed data (for example, in performance monitoring metrics), minimizes network overhead, and reduces operational risk and complexity. It is also more scalable than WMI in many cases.

In circumstances where you collect data remotely (such as when corporate or security policy restricts code installation, or there are performance or interoperability concerns,) you can use the native WMI interface to collect event logs and performance data.

These are the main areas of tradeoff between WMI and forwarders:

  • Performance
  • Deployment
  • Management

Performance

With respect to performance, a forwarder is a better choice when:

  • You collect local event logs or flat files. A forwarder requires less CPU and performs basic precompression of the data in an effort to reduce network overhead.
  • You want to collect data from a machine without having to worry about authentication. When you install a forwarder as the Local System user, it has administrative access to the machine, allowing you to collect any data from it.
  • You want to collect data from busy hosts such as AD domain controllers or machines that consistently experience periods of high utilization, such as Exchange, SQL Server/Oracle, VMWare, Hyper-V, or SharePoint servers. This is because WMI might have problems keeping up with the amount of data these services generate. WMI polling is best-effort by design, and Splunk Enterprise also throttles WMI calls to prevent unintentional denial-of-service attacks.
  • You are concerned about CPU and network utilization. Forwarders use as little of these resources as possible, while WMI uses more CPU and network resources to transfer data.
  • You are concerned about scalability. Universal forwarders scale very well. Heavy forwarders do not scale as well as universal forwarders, but both types of forwarder scale considerably better than WMI.

WMI is a better choice when you are concerned about memory usage on a system with high memory utilization. Because forwarders have more polling options available, and reside on the local machine while collecting data, they use more memory than WMI does.

Deployment

A forwarder is a better choice for deployment when:

  • You have control of the base build of the OS, as is the case when you create system images.
  • You have many data sources to collect, particularly if the data collected requires transformation of any kind.

Note: Except for a few cases, you cannot use a universal forwarder to process data before it reaches the indexer. If you need to make any changes to your data before it is indexed, you must use a heavy forwarder.

WMI is a better choice when:

  • You don't have control of the base OS build, or you don't have domain administrator access, or local administrator privileges on the machines from which you want to get data.
  • You want or need only a limited set of data from a large number of hosts (for example, CPU data for usage billing).

A common deployment scenario is to first test using remote polling, then add successful or useful data inputs to your forwarder's configuration later, or at mass deployment time.

Management

Both mechanisms offer logging and alerting to let you know if a host is coming on or offline or is no longer connected. To prevent an unintentional denial of service attack, the WMI polling service in Splunk Enterprise begins to poll less frequently over time if it cannot contact a host for a period of time, and will eventually stop polling unreachable hosts altogether. Do not use remote polling over WMI for machines that are frequently offline, such as laptops or dynamically provisioned virtual machines.

The table shows a list of data sources and indicates which data collection type(s) are appropriate for each data source.

Data sources and collection methods
Data source Local forwarder WMI
Event logs Yes Yes*
Performance Yes Yes
Registry Yes No
Active Directory Yes No
Log files Yes Yes**
Crawl Yes No

* For remote event log collection, you must know the name of the event log you want to collect. On local forwarders, you have the option to collect all logs, regardless of name.

** Splunk Enterprise supports remote log file collection using the "\\SERVERNAME\SHARE" syntax; however, you must use CIFS (Common Internet File System, or Server Message Block) as your application layer file access protocol, and Splunk Enterprise must have at least read access to both the share and the underlying file system.

Search Windows data on a non-Windows instance of Splunk Enterprise

You can index and search your Windows data on a non-Windows instance of Splunk, but you must first use a Windows instance of Splunk Enterprise to gather the Windows data. You can do this by installing a Splunk forwarder onto the Windows computer and configuring it to forward Windows data to the non-Windows instance of Splunk Enterprise.

There are two ways to proceed:

  • Set up forwarders locally on each Windows machine from which you want data. These forwarders can send the Windows data to the non-Windows receiving instance of Splunk.
  • Set up a forwarder on a separate Windows machine. The forwarder can use WMI to collect data from all the Windows machines in the environment and then forward the combined data to a non-Windows receiving instance of Splunk.

You must explicitly configure the non-Windows Splunk Enterprise instance to handle the Windows data. See "Searching data received from a forwarder running on a different operating system" in the Forwarding Data Manual.

For information on setting up forwarders, see "Set up forwarding and receiving" in the Forwarding Data Manual.

PREVIOUS
How to get Windows data into Splunk Enterprise
  NEXT
Monitor Active Directory

This documentation applies to the following versions of Splunk® Enterprise: 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters