Oh dang, you mean THE search app? I take it you've learned a valuable lesson, but for other readers
From the docs (https://docs.splunk.com/Documentation/Splunk/7.1.2/Updating/Createdeploymentapps) :
Warning: Because of this behavior, you should be extremely cautious before deciding to use the deployment server to manage the Splunk Enterprise search app. Managing the search app through the deployment server prevents users from saving any unique searches on their search heads. And because there's no way to tell the deployment server to stop managing an app, you're stuck with that decision.
However, all is not lost. Someone else might come in with a better solution, but the simplest way to fix this is to back up the exisiting search app on the indexer, then remove the search server class from the Deployment server. After the DS deletes the search app from your indexers, restart the indexer, drop in the search app backup, and restart. That shouldn't do any permanent damage.
HOWEVER, Using the indexers to run inputs is another architectural issue. A simpler way for you to run this is to have a single Heavy Forwarder running all your rest inputs. If you are avoiding clustering your indexes for a reason, remember in an input you can use the _TCP_ROUTING key to direct specific inputs to specific indexers. This way you don't need to use the DS to manage these inputs at all.
Like I said, index clustering is the way to go for indexer management. If you're concerned about bandwidth/disk space issues with data replication, remember you can always set the Replication and Search Factor on an index cluster to 1, meaning no replication takes place, but you still get to use the cluster master to distribute configuration.
... View more
