Collect Windows Host Information with Splunk

Learn how to configure local or remote Splunk collection for Windows host information, including operating system, CPU, disks, services, and processes.

Windows host monitoring is a Splunk data-input capability that periodically collects descriptive and operational information about a Windows computer. The resulting events help administrators and analysts understand what systems exist, how they are configured, and what is currently running.

This lesson covers local collection from a Windows Splunk installation and remote collection through a Splunk Universal Forwarder. It also explains permissions, input settings, validation searches, analysis patterns, and common troubleshooting steps.

What Windows host monitoring does

Windows host monitoring collects information about a Windows computer on a recurring schedule. A configured data input defines what is collected, how it is labeled, and where the resulting events are written.

Host-information collection is different from Windows performance counters. Performance counters measure resource behavior such as processor utilization, memory activity, or disk performance. Host monitoring instead describes the computer and its operating state, such as its operating-system build, disks, services, and running processes. The two input types can complement each other, but one does not replace the other.

Asset inventory: Record computer names, operating-system versions, processors, disks, and other system properties.
Operating-system visibility: Find systems running a particular Windows version or build.
Capacity awareness: Review disk capacity and available space.
Process and service review: Determine whether a service or process is present on a host.
Troubleshooting: Compare a host's known configuration with its expected configuration during an investigation.

Windows information available to collect

The event categories exposed by the input interface depend on the Splunk version and installed Windows components. Common categories include computer identity, operating-system details, CPU information, disks, services, and processes. Select the categories that support your use case rather than enabling every category automatically.

Collection category	Typical information returned	Example operational use	Polling-frequency considerations
Computer identity	Computer name, host identity, and related descriptive values	Build an endpoint inventory and correlate events to a machine	Usually changes infrequently; a longer interval is often sufficient
Operating system and build	Windows edition, version, release, and build details	Find systems requiring an operating-system update	Usually changes only after maintenance; avoid unnecessarily frequent polling
CPU information	Installed processor and processor-related details	Compare server configurations or investigate capacity differences	Generally static; collect periodically rather than continuously
Disk capacity and free space	Logical disks, capacity, and available-space values	Identify systems approaching a storage threshold	Collect more often when storage changes are operationally important
Services	Installed services and their available state information	Check whether a required service exists or is active	Choose an interval that reflects how quickly service changes matter
Processes	Running process names or executable details	Look for a required process or investigate unexpected activity	Can produce more data; use a moderate interval and monitor volume

Other selectable Windows host-monitoring event types may appear in the input form. Treat each event type as an independent collection decision: understand what it contributes, how often it changes, and whether its data belongs in your inventory, operations, or security workflow.

Permissions and execution requirements

The Splunk process collecting host information needs sufficient Windows privileges to read host-level data. Supported execution contexts include Local System and a local account with administrator permissions.

Local System is a built-in Windows service account with broad privileges on the local computer. A local administrator is an account that has administrative permissions on the endpoint. If the service runs with insufficient privileges, some categories may be missing, incomplete, or inaccessible even though the input itself is enabled.

Check the account used by the Splunk Enterprise or Universal Forwarder service.
Verify the account on every monitored machine, not only on the deployment server or indexer.
Recheck permissions after changing service accounts, applying Windows hardening, or upgrading Splunk.
Use an authorized account that follows your organization's service-account policy.

Local and remote collection architecture

Collection runs on the Windows computer whose information is being gathered. The deployment model determines which Splunk component performs that collection.

Deployment model	Where collection runs	Required component	Privilege requirement	Data path	Best use case
Local Splunk monitoring	On the Windows computer running Splunk	Splunk Enterprise or another supported local Splunk installation	Splunk service runs as Local System or an authorized local administrator	Local input to the configured index on that Splunk environment	Collecting information from the Splunk server itself
Remote monitoring through Universal Forwarder	On each remote Windows endpoint	Splunk Universal Forwarder installed on each endpoint	Forwarder service runs as Local System or an authorized local administrator	Endpoint to Universal Forwarder, then to a receiving tier such as an indexer, and finally to the search environment	Monitoring a fleet of Windows workstations or servers

In a remote design, the monitored endpoint is the Windows computer whose data is collected. The Universal Forwarder is the lightweight Splunk agent that gathers local data and forwards events. The indexer receives, processes, stores, and makes the events searchable. The search environment is the Splunk interface or search tier used by analysts to query the indexed data.

Install and configure a Universal Forwarder on every remote Windows server or workstation. Configure the desired host-monitoring input on each endpoint through your chosen deployment method, then configure forwarding to the organization's receiving tier. For forwarder installation guidance, see Install A Splunk Forwarder On Windows and Monitor Logs Using Forwarders.

Create a local Windows host monitoring input

Use Splunk Web to create a local input when Splunk is installed directly on the Windows computer to be monitored.

Open Settings in Splunk Web.
Select Data Inputs.
Open the Local Windows host monitoring input type.
Choose the option to create a new input.
Enter a meaningful collection name. Use a predictable name that identifies the endpoint or purpose, such as a name based on the computer and inventory function.
Select the required event types, such as operating-system information, processor information, disks, services, and processes.
Set the polling interval in seconds. This is the number of seconds between collection attempts.
Choose the app context when the interface provides that option. The app context determines which Splunk application scope owns or exposes the configuration.
Set the host field value or host-naming behavior. Use a consistent value that identifies the originating Windows computer.
Choose the destination index. An index is a Splunk data store and search boundary where the events are written.
Review the resulting configuration, confirm that the input is enabled, and submit or save it.

Setting	Purpose	Selection guidance	Example
Collection name	Identifies the input for administration and troubleshooting	Use a stable, descriptive naming convention	Windows inventory for a server or endpoint group
Event types	Determines which Windows host categories are collected	Select only categories needed for the operational, inventory, or security objective	OS, CPU, disk, service, and process information
Interval	Sets the seconds between collection attempts	Balance freshness with collection and indexing volume	A moderate recurring interval for baseline inventory
App context	Associates the configuration with a Splunk application scope	Choose the context that matches ownership, visibility, and permissions	An infrastructure-monitoring application
Host value	Sets the event metadata identifying the originating machine	Use a consistent naming strategy across endpoints	The Windows computer name
Index	Routes events to a data store and search boundary	Consider retention, access control, and data-management requirements	A Windows inventory or infrastructure index

Input design decisions

Select useful event types

Choose categories based on the question you need to answer. Operating-system and CPU data support baseline inventory. Disk data supports storage awareness. Services and processes support operational and security review. Broad selection is not automatically better: it can increase ingest volume and make ownership and retention harder to manage.

Choose the polling interval

The interval should reflect how quickly the information changes and how quickly you need to act. Operating-system and processor details are usually stable, while process and service information can change more often. A short interval may be appropriate for a focused operational requirement, but a fleet-wide process collection at a short interval can create unnecessary indexing activity.

Standardize names and routing

Use a predictable collection name and a consistent host-field strategy. This makes endpoint comparison, troubleshooting, and configuration review easier. Route the data to an index whose retention, permissions, and ownership match the value of the information. If the host field is manually overridden, make sure the value is unique and matches the naming convention used by your searches.

Practical example: local baseline inventory

Suppose Splunk Enterprise is installed on a Windows server and you want a baseline inventory. Create a Local Windows host monitoring input, name it for the server and inventory purpose, select operating-system, processor, disk, service, and process categories, and use a moderate recurring interval. Route the events to an infrastructure or Windows inventory index.

After saving the input, wait for at least one complete polling period and search the destination index. Compare the returned computer name, Windows build, processor, disks, services, and processes with the known properties of the server.

Practical example: remote Windows server fleet

Install a Universal Forwarder on each remote Windows server.
Ensure the forwarder service runs as Local System or an authorized local administrator account.
Configure the desired Windows host-monitoring input on every endpoint through the selected deployment method.
Configure the forwarders to send events to the organization's Splunk receiving tier.
Confirm that the receiving indexer or other receiving component accepts the data.
Search by the standardized host field to compare operating systems, disks, services, and processes across servers.

The forwarder gathers the information locally; it does not require the indexer to remotely inspect the Windows endpoint. This local execution model makes endpoint permissions and forwarder health essential parts of the design.

Validate collected host data

Verify that the input is enabled and assigned to the expected index.
Note the configured polling interval and wait for at least one complete interval.
Search the target index broadly for the monitored host.
Inspect the returned event categories, host values, timestamps, and Windows details.
Compare the results with known properties of the computer, such as its actual build, disk layout, installed services, and currently running processes.
After identifying the event metadata, add source-type and category filters to make later searches more precise.

index=<windows_host_index> host=<endpoint_name>

Begin with a broad search when validating a new deployment. Restrictive filters can hide data when the host value, source type, or extracted field name differs from your expectation.

Search and analysis guidance

Field names and source types can vary by Splunk version, Windows add-on, and deployment configuration. Inspect your own events before building saved searches or dashboards. Use the event's metadata and extracted fields rather than assuming that a field name from another environment will exist unchanged.

Find a specific Windows build

First identify the field containing the operating-system version or build, then filter on the target value and group by host.

index=<windows_host_index> <os-version-or-build-field>=<target_value>
| stats values(<os-version-or-build-field>) as build by host

This produces a host-oriented list after you replace the placeholders with fields present in your events.

Review a service

Search service-related events for the required service name or executable. Limit the search to a host or server group when investigating a specific system.

index=<windows_host_index> host=<endpoint_name> <service-field>=<target_service>

Use the returned state or status field, if available, to determine whether the service is active. Presence of a service event does not by itself prove that the service is healthy.

Review a running process

Search process-related events for the executable or process name.

index=<windows_host_index> host=<endpoint_name> <process-field>=<target_process>

Use this as an operational starting point. Host-monitoring data is periodic, so a process that is absent from one collection may have started or stopped between polling attempts.

Identify hosts needing storage attention

Collect disk information regularly, identify the fields representing capacity and available space, and aggregate or filter for low available-space values.

index=<windows_host_index> <available-space-field> <low-space-condition>
| stats values(<available-space-field>) as available_space by host

Validate a low-space result against the endpoint before taking corrective action. Confirm the unit of measurement and whether the event describes a local disk, logical volume, or another storage object.

Maintenance and operational practices

Review intervals and selected categories as inventory and monitoring requirements change.
Monitor ingest volume when broad categories, especially processes or services, are polled frequently.
Maintain Universal Forwarder deployment, configuration, and connectivity for remote systems.
Revalidate collection after Windows updates, Splunk upgrades, service-account changes, index-routing changes, or endpoint hardening.
Keep host naming consistent so fleet searches and comparisons remain reliable.
Review index retention and access requirements as the inventory grows.

Troubleshooting

No host-monitoring events appear in search

Verify that the input was saved, enabled, and assigned to the intended index.
Confirm that the search time range includes a completed polling cycle.
Search broadly in the destination index before adding host, source-type, or category filters.
Check that the host value in the search matches the event metadata.
For remote systems, check forwarder status and forwarding connectivity to the receiving Splunk environment.

Only some Windows details are collected

Review whether the relevant event type was selected.
Confirm that the Splunk or forwarder service runs as Local System or a local administrator.
Inspect raw events and available fields. The selected category may not expose the expected detail in every environment.

Remote data is difficult to identify

Review the configured host value and host-naming behavior.
Standardize endpoint names across forwarder deployments.
Check for duplicated, abbreviated, or overwritten computer names.
Compare event metadata with the actual Windows computer name.

Indexing volume or polling activity is unexpectedly high

Compare selected event categories with the actual monitoring objective.
Increase the interval where near-real-time updates are unnecessary.
Collect process or service information less frequently if the use case permits.
Route and retain inventory data according to its operational value.

Sample searches do not match your fields

Field extraction behavior, source types, Splunk versions, and installed add-ons differ between environments. Run a broad search for the host-monitoring events, inspect event metadata and extracted fields, and adapt the search to the names actually present in your deployment.

Exam-relevant points

Host monitoring describes Windows computers; performance counters measure resource and performance behavior.
Collection requires adequate privileges on the monitored endpoint, typically Local System or a local administrator account.
Remote collection runs on the endpoint through a Universal Forwarder before sending events to a receiving and indexing tier.
The polling interval controls how often collection attempts occur and affects freshness and ingest volume.
The host field identifies the originating machine and must be consistent for reliable correlation.
Always validate the actual fields and source types in your environment before relying on a search.