How to remove an app from a Deployment Server and restore app function?

[panderla]

I am a new user to Splunk and have made some choices that have got me in a difficult situation.

I have added a search application to my deployment server, and have added multiple remote search heads/indexers as Clients of a server class that includes the search app.

I have begun trying to use REST API inputs which are unique to each remote indexer.

I am losing my customized REST input because the search app on the deployment server does not have the same inputs file.

I can create multiple REST inputs on the deployment server, but don't want to resort to that as the management of that file will be difficult in the long run.

What alternatives do I have? Can I remove the search app from the deployment server server class? Will that delete my search functionality on my indexers?

Can I remove specific indexers as clients to the server class? Will that remove the search app from that client?

Any help is appreciated.

[jplumsdaine22]

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.