Considerations for deciding how to monitor remote Windows data

Considerations for deciding how to monitor remote Windows data

The best way to get data off of a Windows host is with local Splunk forwarder. Using a local forwarder offers the most types of data sources, minimizes network overhead and reduces operational risk and complexity.

However, there are circumstances – from organizational boundaries to local performance considerations – where remote collection is preferred. For these situations Splunk supports using the native WMI interface on Windows to collect Event Logs and performance data.

This table offers a list of data sources and their respective trade-offs for you to consider.

Data Source Considerations

Data Source	Local Forwarder	Remote Polling
Event Logs	Yes	Yes*
Performance	Yes	Yes
Registry	Yes	No
Log Files	Yes	Yes**
Crawl	Yes	No

Note: For remote Event Log collection, you *must* know the name of the Event Log you wish to collect. On local forwarders, you have the option to collect all logs, regardless of name

Note: Remote log file collection using {\\servername\share\} syntax is supported, however you must use CIFS as your application layer file access protocol and Splunk must have at least read access to both the share and the underlying file system

Tradeoffs:

Performance.

For identical collecting local Event Logs and flat log files, a local forwarder requires less CPU and performs basic pre-compression of the data; it is more memory intensive, mostly owing to the additional data source input options. WMI remote polling is more CPU intensive on the target for the same set of data (either remote Event Logs or remote performance data) and more network intensive.

Note that for highly audited hosts, such as domain controllers, remote polling may not be able to keep up with the volume of data or Event Log events. Remote polling is best-effort by design of the WMI API, and is throttled to prevent unintentional denial of service attacks.

Deployment.

Local forwarders are easier where you have control of the base OS build, and/or if you have many data sources, especially if transformation of data is required. Remote polling works well when you want a limited set of data from a large number of hosts (for example, just process CPU data for usage billing). Remote polling may be your only option where you don't have either build control or local administrator privileges on the target host.

A common usage scenario is to first test using remote polling, then add successful or useful polls to your local forwarding configuration later, or at mass deployment time.

Management.

Both mechanisms offer logging and, potentially, alerting to let you know if a host is coming on or offline or is no longer connected. However, to prevent an unintentional denial of service attack the WMI polling service in Splunk will start to poll less frequently over time if it is unable to contact a host for a period of time. Therefore remote polling is not advised for machines that are frequently offline, such as laptops or dynamically provisioned virtual machines.

Search Windows data on a non-Windows Splunk

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 to gather the Windows data. You can easily do this by means of a Splunk forwarder running on Windows, configured to gather Windows inputs and then forward the data to the non-Windows instance of Splunk where searching and indexing will take place.

There are two main ways to proceed:

• Set up light forwarders locally on each Windows machine that's generating data. These forwarders can send the Windows data to the non-Windows receiving instance of Splunk.

• Set up a regular forwarder on a separate Windows machine. The fowarder can perform remote polling on all the Windows machines in the environment and then forward the combined data to a non-Windows receiving instance of Splunk.

You must specially configure the non-Windows Splunk to handle the Windows data. For details, see "Searching data received from a forwarder running on a different operating system".

For information on setting up forwarders, see "Set up forwarding and receiving".