Considerations for deciding how to monitor remote Windows data
This topic discusses the considerations for monitoring 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)
For Splunk Cloud deployments you must use the Splunk Universal Forwarder to monitor remote Windows data.
Use 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 or IBM BigFix.
After you install a universal forwarder, it gathers information locally and sends it to a Splunk deployment. 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).
- 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.
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 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 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 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:
- Confirm 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.
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. 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.
Use managed system accounts to access Windows data
On recent versions of Windows Server, you can use managed service accounts (MSAs) to address challenges with password expiry. See Managed service accounts on Windows Server 2008 and Windows 7 in the Installation manual.
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 data 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:
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, 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. 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 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.
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 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 you index it, 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 configurations later, or when you do large scale forwarder installations.
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 Splunk Enterprise 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 table shows a list of data sources and indicates which data collection type(s) are appropriate for each data source.
|Data source||Local forwarder||WMI|
* 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 Splunk deployment, but you must first use a Windows instance of Splunk Enterprise to get 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 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 Splunk.
How to get Windows data into your Splunk deployment
Monitor Active Directory
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 8.0.0, 8.0.1, 8.0.2