Study guide
11.1 Deployment Management & the Deployment Server
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.1 Deployment Management & the Deployment Server
Key Takeaways Explain This Topic AI
Deployment management lets one deployment server distribute apps and configuration to many deployment clients (forwarders and non-clustered indexers or search heads) grouped into server classes.
Clients phone home to the deployment server's management port (TCP 8089) every phoneHomeIntervalInSecs (default 60 seconds) and download apps whose checksums differ.
Run the deployment server on a dedicated instance unless it has 50 or fewer clients, and never co-locate it with an indexer cluster manager.
Do not use the deployment server for indexer cluster peers (use the cluster manager's configuration bundle) or search head cluster members (use the deployer).
A deployment server cannot be a deployment client of itself.
Last updated: September 2026
Deployment Server Architecture & Deployment Apps
Quick Summary: Centralized configuration management across distributed Splunk environments is anchored by the Deployment Server (DS) and Deployment Client (DC) framework. Rather than manually configuring hundreds or thousands of forwarders, administrators maintain modular configuration packages called deployment apps in $SPLUNK_HOME/etc/deployment-apps/ on a centralized server. Through client-driven polling over HTTPS management port 8089, deployment clients automatically discover, download, and stage configuration updates based on assigned server classes.
Centralized Management: The Poll-and-Download Paradigm
A critical architectural distinction in Splunk Enterprise is that the Deployment Server does not push configurations to clients . Instead, the architecture functions on a client-initiated poll-and-download model (often termed "phone-home"). +-----------------------+ TCP 8089 (HTTPS) +-----------------------+
- | Deployment Client | ----------------------------------------> | Deployment Server |
- | (Universal Forwarder) | <---------------------------------------- | (Splunk Enterprise) |
- +-----------------------+ 1. Handshake & Checksum Manifest +-----------------------+
- 2. Compute Delta & Download Apps
- Why Pull Outperforms Push in Enterprise Networks
Perimeter Firewall & NAT Traversal: Forwarders are frequently deployed across strict network segments, such as DMZs, cloud VPCs, remote branch offices, and isolated internal subnets. Firewalls typically permit outbound connections from endpoints to central management networks but block inbound connections initiated by central servers. Because the forwarder initiates the outbound connection to the Deployment Server over TCP 8089, no inbound firewall pinholes into secured host environments are required.
Ephemeral & Dynamic Host Support: In modern containerized and cloud auto-scaling environments, forwarders spin up and tear down dynamically with ephemeral IP addresses. A push server would need an exhaustive, real-time registry of all active forwarder IPs. With the polling model, newly provisioned forwarders automatically register themselves upon initial boot.
Resilience to Offline Endpoints: When laptops, branch offices, or development VMs go offline, a push server wastes CPU cycles retrying connections and generating timeout faults. Under the poll-and-download model, offline forwarders simply check in and download required configuration updates whenever network connectivity is restored.
The Phone-Home Handshake Sequence
Every polling cycle follows a deterministic four-phase exchange over HTTPS (TCP 8089):
Connection: The client connects over HTTPS to the deployment server's management port at targetUri . If the deployment server requires client certificates ( requireClientCert ), the client must present one.
Client Identity: The client identifies itself (client name, IP address, DNS name, host name, instance ID, and machine type) and reports the deployment apps it holds, with their checksums.
Server Class Evaluation & Delta Calculation: The Deployment Server evaluates the client's metadata against all stanzas in serverclass.conf . It compiles the set of apps the client should possess and compares the server's current app checksums against the checksums reported by the client.
Download & Execution: If the Deployment Server detects missing apps or checksum mismatches, it responds with an instruction set directing the client to download the updated archive bundles. The client streams the compressed app packages from the Deployment Server, unpacks them into $SPLUNK_HOME/etc/apps/ , and initiates any required post-download actions (such as restarting splunkd or reloading specific configuration subsystems).
Planning and Placing the Deployment Server
The deployment server does no indexing, but it works hard when many clients phone home and download apps at the same time. Splunk's planning guidance:
Dedicated instance: Because app downloads use a lot of CPU and memory, run the deployment server on a dedicated Splunk Enterprise instance that is not an indexer or search head.
The 50-client exception: Only when the deployment server has 50 or fewer clients may an indexer or search head double as the deployment server. In that small case the deployment server may also host some management components, such as a search head cluster deployer.
Never with the cluster manager: Do not co-locate a deployment server and an indexer cluster manager under any circumstances. Both need reliable resources, and the deployment server can starve the manager.
Not its own client: A deployment server cannot be a deployment client of itself. Splunk logs "This DC shares a Splunk instance with its DS: unsupported configuration".
Pace large fleets: Clients phone home every phoneHomeIntervalInSecs (default 60 seconds). With thousands of clients, a longer interval spreads out handshakes and downloads.
Illustrative Bandwidth Estimate
Pushing a 15 MB add-on to 4,000 forwarders sends about 60 GB in total. If every client downloaded it within the same minute, that would take about 8 Gbps : Bandwidth = 4,000 × 15 MB × 8 60 s = 8,000 Mbps \text{Bandwidth} = \frac{4{,}000 \times 15\text{ MB} \times 8}{60\text{ s}} = 8{,}000\text{ Mbps} Bandwidth = 60 s 4 , 000 × 15 MB × 8 = 8 , 000 Mbps
In practice clients phone home at different moments, but the math shows why large app updates and short phone-home intervals on big fleets need planning.
- Architectural Boundaries: What the Deployment Server Must Not Manage
- 1. Never Use the Deployment Server for Indexer Cluster Peers
Do not use the deployment server or forwarder management to distribute configuration to indexer cluster peer nodes. Peers receive common configuration only through the cluster manager's configuration bundle : files placed in $SPLUNK_HOME/etc/manager-apps/ (formerly master-apps/ ) and pushed with splunk apply cluster-bundle . You may use the deployment server to update the cluster manager itself , which then pushes the bundle to the peers.
2. Never Use the Deployment Server for Search Head Cluster Members
The deployment server is not supported for distributing apps or configuration to search head cluster members. Use the deployer ( $SPLUNK_HOME/etc/shcluster/apps/ and splunk apply shcluster-bundle ).
3. Keep the Deployment Server Off Busy Instances
Once there are more than 50 clients, keep the deployment server off indexers and search heads, and never place it on the indexer cluster manager. Heavy phone-home and download traffic on those instances competes with indexing, searching, and cluster management.