Considerations for deciding how to monitor remote Windows data

If you want to monitor Windows data that is not on a local Windows machine, consider these options.

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

• From Splunk forwarders
• Using Windows Management Instrumentation (WMI)

For Splunk Cloud Platform deployments, you must use the Splunk Universal Forwarder on a Windows machine to monitor remote Windows data.

Using a forwarder to collect remote Windows data

Use a universal forwarder to get remote Windows data whenever possible. The universal forwarder has these advantages:

• It uses minimal network and disk resources on the installed machines.
• You can install it as a non-privileged user, whereas you require administrative access for WMI.
• If you install it 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 install. You can install it manually, with either a Microsoft deployment tool like System Center Configuration Manager (SCCM) or a third party distribution solution such as Puppet.

After you install a universal forwarder, it gathers information locally and sends it to . 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 on the universal forwarder.

There are some drawbacks to using the universal forwarder, depending on your network configuration and layout. See Splunk forwarders versus WMI in this topic.

Using WMI to collect remote Windows data

The WMI framework lets the Splunk platform collect virtually any kind of data from remote Windows machines. In this configuration, the Splunk platform runs as a user that you specify at installation or later on, in the Services control panel. For more information, see Choose the Windows user Splunk Enterprise should run as in the Installation Manual.

This configuration has the following advantages:

• It gives the Splunk platform as much access to the network as the specified account has for remote access.
• It lets indexers collect data from remote Windows machines across the enterprise and place that data into a central repository.
• It 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 Considerations for getting data over WMI and Splunk forwarders versus WMI later in this topic.

Also, 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 the Splunk platform monitors AD, see Monitor Active Directory in this manual.

Considerations for getting data over WMI

When collecting remote Windows data over WMI, take into account the following considerations:

• Authentication for remote Windows data
• Using managed system accounts to access Windows data
• Network and I/O usage

Authentication for remote Windows data

Windows requires authentication for remote operations. Failure to understand how the Splunk platform interacts with Windows over the network can lead to suboptimal search results or no results at all.

When you install the Splunk platform, you can specify the Splunk platform to run as the Local System user or another user. This choice has ramifications for both installation and data collection. For more information, see Choose the Windows user Splunk Enterprise should run as in the Installation Manual.

The user you tell the Splunk platform to run as determines the kind 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 platform user account with least-permissive access to the data sources you want to collect. This means you must do the following:

• Add the user to various domain security groups.
• Modify 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 do the following:

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

You must also give this account the "Deny log on locally" user rights assignment in Local Security Policy to prevent the user from logging in interactively to workstations. This method gives you more control and is more secure than giving domain administrator access.

See the other topics in this chapter that deal with remote access to Windows machines for more information. Check the Security and remote access considerations sections for how to configure the user that the Splunk platform runs as for least-permissive access.

Network and I/O usage

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 data collection operations.

Disk bandwidth is a concern as well. Always configure antivirus scanner drivers and drivers that intermediate between the Splunk platform and the operating system to ignore the Splunk platform 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 when there are performance or interoperability concerns, you can use the native WMI interface to collect event logs and performance data.

WMI and forwarders have the following main areas of tradeoff:

• Performance
• Deployment
• Management

Performance

With respect to performance, a forwarder is a better choice when the following circumstances apply:

Scenario	Considerations
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, letting you 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.	Consider using a forwarder in this scenario because WMI might have problems keeping up with the amount of data these services generate. WMI polling is best-effort by design, and the Splunk platform 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 have concerns 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 the following circumstances apply:

• 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 requires transformation of any kind.

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 you index it, you must use a heavy forwarder.

WMI is a better choice when the following circumstances apply:

• You don't have control of the base OS build, 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, like 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 configurations later or when you do large scale forwarder installations.

Management

Both mechanisms offer logging and alerting to advise if a host comes on or offline or is unreachable. To prevent an unintentional denial of service attack, the WMI polling service in the Splunk platform polls less frequently over time if it cannot contact a host and eventually stops 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 following table shows a list of data sources and indicates which data collection types are appropriate for each data source:

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.

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

Search Windows data on a non-Windows instance of the Splunk platform

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

You can proceed in one of the following ways:

• Set up forwarders locally on each Windows machine that you want data. These forwarders can send the Windows data to the non-Windows receiving instance.
• 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 the Splunk platform.