Agent Handler details

Prev Next

Agent Handlers provide specific features that can help grow your network to include many more managed systems.

When to use Agent Handlers

There are many reasons to use Agent Handlers in your network.

  • Hardware is cheaper — The mid-range server hardware used for Agent Handlers is less expensive than the high-end servers used for ePO - On-prem servers.

  • Scalability — As your network grows, Agent Handlers can be added to reduce the load on your ePO - On-prem server.

  • Network topologyAgent Handlers can manage your agent requests behind a firewall or in an external network.

  • Failover — Agents can failover between Agent Handlers using a configured fallback priority list.

  • Load Balancing — Multiple Agent Handlers can load balance the Trellix Agent requests in a large remote network.

When not to use Agent Handlers

There are some instances not to use Agent Handlers.

  • As distributed repositories — Repositories, for example SuperAgents, distribute large files throughout an organization. Repositories do not contain any logic. Agent Handlers use logic to communicate events back to the database. These events tell the Trellix Agent when to download new products from the distributed repositories. Agent Handlers can cache files from the distributed repositories, but don't use them to replace distributed repositories. Agent Handlers are used to reduce the event management load on the ePO - On-prem server.

  • Through a slow or irregular connection — Agent Handlers require a relatively high speed, low latency connection to the database to deliver events sent by the agents.

  • To save bandwidth —Agent Handlers do not save bandwidth. They actually increase bandwidth use over the WAN connection that connects the clients to the Agent Handler. Use distributed repositories to save bandwidth.

How Agent Handlers work

Agent Handlers use a work queue in the ePO - On-prem database as their primary communication mechanism.

Agent Handlers check the server work queue every 10 seconds and perform the requested action. Typical actions include wake-up calls, requests for product deployment, and data channel messages. These frequent communications to the database require relatively high speed, low latency connection between the Agent Handler and the ePO - On-prem database.

An Agent Handler installation includes only the Apache Server and Event Parser services. You can deploy Agent Handlers on separate hardware, or virtual machines, that coexist in one logical ePO - On-prem infrastructure.

Agent Handler functional diagram
Agent Handler functional diagram


This diagram shows two different network configurations and their Agent Handlers.

  • Simple network — The primary Agent Handler is installed as a part of the ePO - On-prem server. This is sufficient for many small ePO - On-prem installations; typically additional Agent Handlers are not required.

  • Complex network — Multiple remote Agent Handlers are installed on separate servers connected to the ePO - On-prem server. Once installed, the additional Agent Handlers are automatically configured to work with the ePO - On-prem server to distribute the incoming agent requests. The ePO - On-prem console is also used to configure Agent Handler Assignment rules to support more complex scenarios. For example, an Agent Handler behind the DMZ, firewall, or using network address translation (NAT).

Administrators can override the Agent Handler default behavior by creating rules specific to their environment.