I'm setting up a fresh install of Splunk Enterprise Security 4 and have a question about the deployment client requirement. I've got ES 4 installed already, and the server is not currently configured as a deployment client.
Creating the Splunk_TA_ForIndexers
1. On the Enterprise Security menu bar, browse to Configure > General and select Distributed Configuration Management.
"Your server has not been configured as a deployment client yet. In order to use this feature, you have to setup a deployment client."
The installation of Enterprise Security on a search head will not complete if apps or add-ons included in the ES package are managed by a deployment server. Before beginning the ES installation, remove the deploymentclient.conf containing references to the deployment server and restart Splunk services.
Just want to make sure that I need to have my ES search head set as a deployment client, but that it shouldn't receive any apps?
Fundamentally, this is about how you'll manage add-ons when it comes to the ES app. There are a couple of important points around add-on management, the ES installer, and ES features that are confusing. Let's see if that can be cleared up a bit 🙂
1. ES Add-ons must be installed on the ES SH. True, and required. When you install Splunk Enterprise Security, the ES installer installs and enables the add-ons included in the ES package on the search head. When you upgrade, the installer does the same work all over again. It's not an intelligent installer, but simply does a version check and overwrite.
2. The ES SH can be a deployment client. True, but not always necessary. In all versions of the ES installer so far, the installer will force an upgrade of the included add-ons/TA's on the SH. Would you rather extract the add-ons/TA's, and place them on the Deployment Server (DS) to keep them in sync and centrally managed, or just use the ES installer to do the work? Each option has advantages and disadvantages in managing the upgrade processes. If your company wants to centrally manage a number of home-grown apps (domain and company specific knowledge) that reside on the ES SH, configuring the ES SH as a deployment client might become a necessity. Also, in some future release, the ES installer might stop providing the add-ons/TA's, in which case managing them with DS for the SH will be necessary.
3. A feature of the ES 4.x version is the ability to create a "Splunk_TA_ForIndexers," which can also be pushed back to the DS if the ES SH is a deployment client. True, but not very useful for most deployments. The "Splunk_TA_ForIndexers" is a roll-up all of the defined indexes and props/transforms spread across all add-ons/TA's on the ES SH placed into one app. It is (in my opinion) a better tool to validate what needs to be managed on the Indexers, as it will provide a handy list of index names that you'll need to account for. It doesn't replace the need for a deployment-wide, centrally managed indexes.conf. The "Splunk_TA_ForIndexers" could replace the need for centrally-managed add-ons/TA's that provide index-time props/transforms. But, the "Splunk_TA_ForIndexers" can only analyze what's installed on the ES SH.
4. The installation of Enterprise Security on a search head will not complete if apps or add-ons included in the ES package are managed by a deployment server.
So now it's down to your administrative processes around upgrades and app management. If you want to keep ES SH centrally managed, you'll implement deploymentclient.conf, but include steps in your upgrade docs to pre-prep the ES SH and disable it, and re-enable it after the upgrade completes. You'll have to decide if the "Splunk_TA_ForIndexers" (which is generated AFTER the upgrade of the ES SH) is easier to manage conceptually then just extracting add-ons/TA's from the installer, reviewing the props/transforms for any active ones you care about, staging them on the DS, and deploying them normally. The "Splunk_TA_ForIndexers" is also completely ignorant of volume settings and other customized elements in you indexes.conf.
Another resource is your SE or a PS rep, especially if they were involved in the ES SH implementation.