An agent grouping can be based on a variety of criteria, such as machine type, OS, geographical area, or application type.

An agent can belong to multiple server classes. For example, a Windows forwarder located in Kelowna and providing information to the Web hosting team might belong to three server classes: "canada", "windows", and "web_host". This diagram shows how agents can span multiple server classes:

In this example, each agent is a Splunk Enterprise forwarder that belongs to two server classes, one for its OS and the other for its geographical location. Agent management maintains the list of server classes and uses those server classes to determine what content to distribute to each client. For an example of how to implement this type of arrangement to govern the flow of content to clients, see Deploy configurations to several forwarders.

Another common way to group agents is to define one server class that applies to all agents by default. You can then override various aspects of it as needed by defining more specific server classes for subgroups of agents. For example, if you have a mix of Windows and Linux universal forwarders sending data to the same indexer, you can specify that all forwarders get a common outputs.conf file, but that Windows forwarders get one inputs.conf file while Linux forwarders get a different one. To implement this, you can define an "all forwarder" server class that distributes a deployment app containing a common outputs.conf file to all forwarders, while also defining Windows and Linux server classes that distribute separate apps containing different inputs.conf files to the appropriate subsets of forwarders.

A server class is a mapping between agents and apps. It tells agent management which apps to send to which agents. Therefore, when you define a server class, you associate one or more apps with a group of agents.

You define server classes on the agent management with these steps:

1. Create the server class.
2. Specify one or more deployment apps for the server class.
3. Specify the clients that belong to the server class.

This section provides an overview of these steps. The specifics of the configuration process depend on the method you use to create the server class: the agent management interface or direct editing of serverclass.conf. See "Ways to define server classes".

You define server classes on the agent management. Server class definitions are saved in the agent management's serverclass.conf file. There are two ways to define server classes:

• By using the agent management interface. See "Use the agent management interface to define server classes" for details. This is the easy way to define server classes. It offers a quick, interactive approach to filtering agents and mapping them to apps.

• By directly editing the agent management serverclass.conf file. See "Use serverclass.conf to define server classes" for details. Some advanced configurations require that you directly edit serverclass.conf.

Once you edit serverclass.conf directly, you will probably not be able to use the agent management interface for subsequent configuration. This is because the agent management interface can handle only a subset of possible configurations. For details about what serverclass.conf changes are compatible with the agent management interface, see "Compatibility and agent management UI".

The serverclass.conf file is the key agent management configuration file. All server class definitions get written to that file. In addition, it holds a number of other settings related to the functioning of agent management. For a detailed description of that file, including a list of all configuration attributes, see serverclass.conf specification file.

For background information on Splunk Enterprise configuration files, see "About configuration files" in the Admin Manual.

When you configure server classes or create new server classes through the interface, the definitions are written to the serverclass.conf file under $SPLUNK_HOME/etc/system/local. If, instead of using the interface, you decide to directly edit serverclass.conf, you should create the serverclass.conf file in that same directory, $SPLUNK_HOME/etc/system/local. You may prefer to edit serverclass.conf directly for some complex configurations.

Agent management can have multiple versions of serverclass.conf. When there are multiple versions of a configuration file, Splunk Enterprise follows a defined process for merging the attributes from all the versions. For details on the order of precedence that Splunk Enterprise uses, see "Configuration file precedence" in the Admin Manual.

When you create a new server class through the interface, the server class definition is saved in a copy of serverclass.conf under $SPLUNK_HOME/etc/system/local. If, instead of using the interface, you decide to directly edit serverclass.conf, you should create the serverclass.conf file in that same directory, $SPLUNK_HOME/etc/system/local.

If a server class definition exists in a serverclass.conf file under some other directory (most typically an app directory located at $SPLUNK_HOME/etc/apps/<app_name>/local), the agent management interface will still display that server class, along with any other server class definitions located in files elsewhere on the system. If you use the interface to edit an existing server class, the interface will save the edits to the same version of serverclass.conf. That is, if you edit a server class that is defined in $SPLUNK_HOME/etc/apps/SomeApp/local/serverclass.conf, the interface saves the updated definition back to that same directory. However, if you then use the interface to create a new server class, it saves the new server class to $SPLUNK_HOME/etc/system/local/serverclass.conf.