ExamFinch.com My Study

Study guide

11.2 Deployment Apps & Deployment Clients

Practice this exam

Splunk Enterprise Certified Admin SPLK-1003

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the Splunk Enterprise Certified Admin Exam

2 Chapter 1: Splunk Admin Basics

1.1 Splunk Enterprise Architecture & Core Components

3 Chapter 2: License Management

2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting

4 Chapter 3: Splunk Configuration Files

3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations

5 Chapter 4: Splunk Indexes

4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy

6 Chapter 5: Splunk User Management

5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits

7 Chapter 6: Splunk Authentication Management

6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication

8 Chapter 7: Getting Data In

7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder

9 Chapter 8: Distributed Search

8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)

10 Chapter 9: Getting Data In – Staging

9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options

11 Chapter 10: Configuring Forwarders

10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing

12 Chapter 11: Forwarder Management

11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting

13 Chapter 12: Monitor Inputs

12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives

14 Chapter 13: Network and Scripted Inputs

13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection

15 Chapter 14: Agentless Inputs

14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration

16 Chapter 15: Fine Tuning Inputs

15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data

17 Chapter 16: Parsing Phase and Data

16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview

18 Chapter 17: Manipulating Raw Data

17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue

11.2 Deployment Apps & Deployment Clients

Key Takeaways Explain This Topic AI

Deployment apps live in $SPLUNK_HOME/etc/deployment-apps/<app> on the deployment server and install into $SPLUNK_HOME/etc/apps/<app> on clients.

At each update the client replaces the whole app, so local changes on the client are lost unless excludeFromUpdate protects them; deleting an app from the deployment server deletes it on clients.

Small single-purpose apps (outputs, inputs per technology, server settings) keep updates targeted and avoid unnecessary restarts.

A client is configured in deploymentclient.conf: [target-broker:deploymentServer] targetUri = <ds_host>:8089, with optional clientName and phoneHomeIntervalInSecs.

splunk set deploy-poll <ds_host>:8089 writes the client configuration; restart the client afterward.

Last updated: September 2026

Deployment Apps and Deployment Clients

Blueprint objectives 11.3 and 11.4 cover managing forwarders with deployment apps and configuring deployment clients . The deployment server stores apps in $SPLUNK_HOME/etc/deployment-apps/ , and each client pulls the apps its server classes assign to it into $SPLUNK_HOME/etc/apps/ .

Deployment Apps Anatomy & Packaging Best Practices

On the Deployment Server, configuration packages staged for distribution are known as deployment apps . They reside in a specialized repository directory: $SPLUNK_HOME/etc/deployment-apps/<app_name>/

When a client downloads a deployment app, the Deployment Server strips the deployment-apps namespace and writes the directory directly into the client's production runtime directory: $SPLUNK_HOME/etc/apps/<app_name>/

Standard Directory Structure of a Deployment App

A deployment app conforms to the standard Splunk application hierarchy: $SPLUNK_HOME/etc/deployment-apps/org_all_forwarder_outputs/

  • ├── default/
  • │ ├── app.conf
  • │ └── outputs.conf
  • ├── local/ (optional; replaced on clients at each update)
  • ├── bin/
  • │ └── (Optional: custom collection scripts, modular inputs, binaries)
  • └── metadata/
  • └── default.meta

Directory Purpose in Deployment Apps Administrative Best Practice

default/ or local/ The app's configuration files ( inputs.conf , outputs.conf , props.conf ). Either works, because the whole app is replaced on the client at every update. Many teams keep deployment apps in local/ so they outrank any default/ settings shipped with an add-on. Client-side edits inside the app are lost at the next update unless protected with excludeFromUpdate .

bin/ Shell scripts, Python scripts, PowerShell scripts, or compiled binaries executed by scripted inputs. Ensure executable permissions ( chmod +x or 0755 ) are preserved in the archive. Avoid architecture-specific binaries in cross-platform deployment apps.

metadata/ Object permission files ( default.meta ). Defines the visibility and export scope of knowledge objects if the app contains field extractions or lookups.

What Happens to an App on the Client During an Update

When a deployment app changes, the client replaces its copy of the app with the downloaded version . Any content created locally inside that app on the client, including its local/ directory and lookup files, is deleted or overwritten , unless you protect it with excludeFromUpdate in serverclass.conf on the deployment server: [serverClass:linux_web:app:org_app_apache_inputs]

excludeFromUpdate = $app_root$/local,$app_root$/lookups/cidr.csv

excludeFromUpdate can be set at the global, server class, or app level. Each entry must start with $app_root$/ . Also note: if you remove an app from the deployment server's repository, every client that received it deletes its copy. Once the deployment server manages an app, it always manages it.

Creating Modular "Micro-Apps"

A severe anti-pattern in Splunk forwarder management is deploying a single monolithic app containing outputs, multiple input types, and parsing properties (e.g., all_forwarder_config ). This approach tightly couples unrelated configurations and forces widespread forwarder restarts whenever a single input changes.

Instead, enterprise administrators construct atomic, modular micro-apps dedicated to single operational domains: $SPLUNK_HOME/etc/deployment-apps/

  • ├── org_all_forwarder_outputs/ # outputs.conf (indexer cluster target, autoLB, SSL)
  • ├── org_all_license_client/ # server.conf ([license] points to License Manager)
  • ├── org_nix_base_inputs/ # inputs.conf (Linux /var/log/messages, secure, audit)
  • ├── org_win_base_inputs/ # inputs.conf (Windows Security, System, Application event logs)
  • ├── org_app_apache_inputs/ # inputs.conf (Apache access_log, error_log)
  • └── org_app_oracle_inputs/ # inputs.conf (Oracle alert logs and listener telemetry)

By composing server classes from these modular units, a Linux web server can receive org_all_forwarder_outputs , org_nix_base_inputs , and org_app_apache_inputs . If the Apache log path changes, only org_app_apache_inputs is updated and distributed, eliminating unnecessary changes to baseline system or output configurations.

Deployment Client Setup: deploymentclient.conf

To transform any standard Splunk instance (Universal Forwarder, Heavy Forwarder, or standalone server) into a Deployment Client, an administrator defines deploymentclient.conf in $SPLUNK_HOME/etc/system/local/ or within a bootstrap deployment client application ( $SPLUNK_HOME/etc/apps/org_base_deploymentclient/local/deploymentclient.conf ).

Detailed Configuration Syntax # $SPLUNK_HOME/etc/system/local/deploymentclient.conf

  • [deployment-client]
  • # Optional logical name the deployment server can filter on
  • clientName = corp-web-prod-01
  • # How often (seconds) to check for new content (default 60)
  • phoneHomeIntervalInSecs = 60
  • [target-broker:deploymentServer]
  • # Fully qualified domain name or IP and management port (TCP 8089) of the Deployment Server
  • targetUri = splunk-ds.corp.internal:8089
  • Key Attributes Breakdown

[deployment-client] : The global client stanza.

clientName : An optional logical name, such as pci-cardholder-web , that server class filters can match. When filters are evaluated, the client name is tried first, then IP address, DNS name, host name, and instance ID.

phoneHomeIntervalInSecs : The time between phone-home checks. Defaults to 60 seconds.

[target-broker:deploymentServer] : Defines the connection target broker.

targetUri : The deployment server's host name or IP address and management port, in host:port form (for example splunk-ds.corp.internal:8089 ).

handshakeRetryIntervalInSecs : How often to retry a failed handshake (default: one fifth of phoneHomeIntervalInSecs ).

After changing deploymentclient.conf , restart the client . splunk set deploy-poll also requires a restart.

CLI Configuration Workflow

Administrators can configure the deployment client via the command-line interface without manually creating files: # Point forwarder to the Deployment Server and configure deploymentclient.conf

splunk set deploy-poll splunk-ds.corp.internal:8089

  • # Restart splunkd to initiate immediate handshake
  • splunk restart
  • # Display current deployment client status and target broker configuration
  • splunk display deploy-client
  • # Check the configured phone-home polling target URI
  • splunk show deploy-poll