VMware ESXi and vSphere Cluster Management

Collect Windows Host Information with Splunk

Learn how to configure Splunk Windows host monitoring inputs to collect Windows inventory, services, processes, disk details, and operating system information.

Windows host monitoring lets Splunk poll a Windows system for selected inventory and operating-state information. You can use it to understand what systems exist, which Windows builds they run, which services and processes are present, and how disks are configured.

This lesson covers local collection on a Windows system running Splunk and remote collection from Windows systems using a Splunk Universal Forwarder. It assumes familiarity with basic Splunk Web navigation, data inputs, indexes, and Windows service accounts.

What Windows host monitoring does

Windows host monitoring is a Splunk data input capability that polls a Windows system for selected host and system-information categories. The collected information can support asset visibility, endpoint troubleshooting, operational reporting, and searches about system configuration.

Host monitoring is different from other common Windows data sources:

For example, host monitoring can tell you which processes are present during a polling cycle. It is not a replacement for a time-series performance input that measures how heavily the CPU or disk is being used.

Windows information you can collect

The available event types depend on the Windows host-monitoring input and Splunk configuration. An event type is a selectable category of Windows host information. Common categories include:

Other selectable Windows host-monitoring event categories may be exposed by the input configuration. Select only categories that support a defined operational need. Collecting every available category at a very short interval can increase endpoint work and indexing volume.

Permissions and execution requirements

The Splunk process must have sufficient Windows privileges to retrieve host monitoring data. Supported execution contexts include:

• Local System: a highly privileged built-in Windows service account that can be used by the Splunk process for host data collection.
• Local administrator: a local Windows account with administrative rights on the machine.

Insufficient privileges can prevent collection of some or all requested host details. A configuration may appear correct while particular categories remain unavailable because the Splunk service account cannot read the required Windows information.

Before troubleshooting the input, identify the account used by the Splunk Windows service. Confirm that the account is Local System or a local administrator account, and apply your organization’s least-privilege and service-account policies where applicable.

Configure local Windows host monitoring

For a Splunk instance running directly on Windows, open the host-monitoring input configuration in Splunk Web:

Settings > Data inputs > Local Windows host monitoring

Create a new input and work through the following fields.

1. Create a new input. Choose the option to add a host monitoring input.
2. Enter a collection name. Use a meaningful administrator-assigned identifier, such as a name that describes the host and the information being collected. The collection name identifies the input configuration; it does not replace the host metadata on events.
3. Select event types. Choose the Windows host-information categories to collect, such as operating system details, CPU information, disks, services, and processes.
4. Set the interval. Enter the polling interval in seconds. This is the number of seconds between collection attempts.
5. Choose the app context. Select the Splunk application context under which the input is created and managed. Use the context that matches your administration and permissions model.
6. Set or confirm the host value. The host field identifies the Windows system associated with the events. Choose a value that follows your organization’s hostname convention.
7. Choose the destination index. Select the index that should receive the collected host information.
8. Review and submit. Verify the selections, submit the input, and confirm that it is enabled.

Choose an appropriate polling interval

The polling interval controls how frequently Splunk asks Windows for the selected information. A shorter interval makes changing state visible sooner, but it can increase work on the endpoint and the amount of data sent to and stored by Splunk.

Relatively static inventory normally needs less frequent collection. Operating system version, build, processor details, and disk inventory often change infrequently. Services and processes can change more often, so an operations team may choose a shorter interval when near-current state is important.

Consider these questions when choosing an interval:

• How quickly must a change become searchable?
• How many Windows hosts will use this configuration?
• How much endpoint, network, and indexer capacity is available?
• Will the selected categories produce mostly static records or frequently changing records?
• Is the interval appropriate for the investigation or reporting use case?

Do not assume that a very short interval is automatically better. Start with the freshness requirement, then test the effect on endpoint resources and indexed data volume.

Organize collected data with indexes and host metadata

An index is a Splunk data store that receives events and influences retention and access behavior. Selecting the destination index is an operational design decision, not just a form entry.

Use an index strategy that supports:

• Retention appropriate for inventory and operational investigations.
• Role-based access to Windows infrastructure data.
• Searches across the Windows fleet.
• Separation of operational data where different teams or retention policies apply.
• Predictable dashboards and reports.

The host field is the event metadata value used to identify the system associated with collected data. Correct host attribution makes it possible to group results by computer, compare systems, and investigate one endpoint without mixing it with another. If different systems use inconsistent host naming, searches and reports can become difficult to interpret.

Collect information from remote Windows hosts

A remote Windows machine can collect its own host information and send it to an indexer through a Universal Forwarder. A Universal Forwarder is a lightweight Splunk agent installed on a data source that forwards collected data to a receiving Splunk tier.

The monitored endpoint, its forwarder, and the receiving Splunk deployment have different responsibilities:

• The Windows endpoint is where host information is read.
• The Universal Forwarder runs on that endpoint and forwards the collected data.
• The indexer receives, processes, stores, and makes the data searchable.

Configure the host-monitoring input on the Windows machine where the data is collected. Configuring an input only on the indexer does not cause the indexer to poll a separate Windows endpoint for that endpoint’s host information.

Verify collection and search the results

After submitting an input, allow at least one polling interval to elapse. Then search the selected index. Begin broadly before adding restrictive filters.

index=<selected_index>

Once events appear, narrow the search using the host value and the category or source type used by your deployment:

index=<selected_index> host=<expected_host>

Depending on the data format and configuration, you can also filter by the relevant host-information category or source type. Use the field names and category values shown in the returned events rather than assuming that every deployment uses identical names.

Validate more than event arrival. Check that:

• The host metadata identifies the intended Windows system.
• Operating system version and build values match the endpoint.
• CPU details are present when that event type was selected.
• Disk information includes the expected disks and available-space values.
• Installed service data contains expected services.
• Running process data contains processes expected at the collection time.
• Event timestamps advance at the configured polling cadence.

For fleet inventory, search across the selected index and group results by host or operating system fields. For a service or process investigation, filter to one host and inspect the most recent events. For disk validation, allow multiple polling cycles so that you can confirm both the values and the recurring collection pattern.

Practical examples

Monitor a local Splunk server

On a Windows machine running Splunk, create a local Windows host monitoring input. Select operating system, CPU, disk, service, and process categories. Set an interval appropriate for the required freshness and store the results in an index used for Windows operations. Verify that each selected category produces searchable information for the local host.

Build Windows asset visibility

Install and configure Universal Forwarders on Windows servers. Configure host monitoring on each endpoint to collect computer names, Windows versions, build numbers, and CPU details. Search the destination index to identify systems running a particular operating-system build or to compare processor information across hosts.

Investigate service or process state

Enable service and process collection on a critical application server. After the input has completed a polling cycle, search the selected index for the target host and inspect the newest events. Confirm whether the expected service or process is present at the collection time.

Validate disk inventory

Enable disk-information collection and search by host after multiple polling cycles. Review the available-space fields for the expected volumes and compare successive events when investigating a capacity concern.

Troubleshooting

No Windows host information appears

Possible causes include an input that was not submitted or enabled, an incorrect index or time range, an interval that has not elapsed, or insufficient privileges for the Splunk service account.

• Confirm the input configuration and selected index.
• Wait through at least one expected polling cycle.
• Search the selected index broadly before adding host or category filters.
• Verify that the Splunk service runs as Local System or a local administrator account.

Only some categories are collected

The missing event types may not have been selected, or the process may lack permission to retrieve those categories.

• Review the event-type selections in the input.
• Check the Windows account used by the Splunk service.
• Compare the expected information with the categories exposed by the host-monitoring configuration.

Remote Windows hosts do not send information

Check the endpoint’s Universal Forwarder, the input location, forwarding connectivity, and endpoint permissions.

• Confirm that the Universal Forwarder is installed and running on the remote Windows host.
• Confirm that host monitoring is configured on that endpoint.
• Validate the forwarder’s connection to the receiving Splunk infrastructure.
• Check the endpoint’s Splunk service account privileges.

Host attribution is unexpected

The configured host value may not match the desired hostname convention, or systems may use inconsistent names.

• Review the host value selected in the input.
• Compare host metadata across events from different systems.
• Standardize host naming where necessary.

Scope boundaries and next steps

Windows host monitoring provides system information and point-in-time operating-state data. It is not a replacement for performance monitoring. If you need CPU, memory, disk, or other resource measurements tracked over time, configure Windows performance counter collection.

For broader remote-data collection, study Universal Forwarder deployment, forwarder-to-indexer data flow, and deployment configuration. Windows event log collection is also a separate input area when the requirement is to search security, system, or application events.

For a concise reference to the configuration path, return to Collect Windows Host Information.