search cancel

Troubleshooting 12.5+ agents showing as not reporting within Agent Overview.

book

Article ID: 162721

calendar_today

Updated On:

Products

Data Loss Prevention Endpoint Prevent Data Loss Prevention Endpoint Discover

Issue/Introduction

12.5 or later agents are not reporting to the DLP Enforce console.

Resolution

Troubleshooting

Before attempting the following steps, agents not reporting to the console issues are often caused by changes made to the advanced agent settings, often in an attempt to “speed up” how often they report to their Endpoint Server. It is best to set any communication layer settings to their default values. The default values for these settings are listed in the online help section for advanced agent settings:<enforce server IP>/ProtectManager/help/complete/en_US/wwhelp/wwhimpl/js/html/wwhelp.htm?context=DLP&topic=Add_Agent_Configuration  The settings you will want to be concerned with are the following:

CommLayer.NO_TRAFFIC_TIMEOUT_SECONDS.int -- Default 300

EndpointCommunications.HEARTBEAT_INTERVAL_IN_SECONDS.int -- Default 270

EndpointCommunications.IDLE_TIMEOUT_IN_SECONDS.int -- Default 30

ServerCommunicator.CONNECT_POLLING_INTERVAL_SECONDS.int -- Default 900

 

If you have ensured that communication settings are set to default, the next most common point of failure is network connectivity.  With the introduction of the 12.5+ communication model, the default port that agents communicate on is 10443.  Please ensure that connectivity between your endpoints and their respective endpoint servers over port 10443 is possible and no additional software or network device is interfering with this communication, or shutting down the connections prematurely.

Another issue encountered most often happens if there is a large number of agents communicating with an individual server. While the 12.5+ communication model allows for far greater scaling in the number of agents a single endpoint server can support, some tuning may be necessary.

Within \SymantecDLP\Protect\config\Aggregator.properties locate the following lines:

# Maximum number of operations that can be pushed out across all transport connections.
# Exceeding this maximum will cause the transport connection write to block until operations
# are processed and the queue size returns to normal.
maxQueueSize = 5000

This setting controls the maximum number of status updates that can be queued; as the newer communication model has expanded the number of agents that can reliably connect, this queue size may need to change.  In most environments it is safe to change this value dramatically such as increasing it tenfold to 50000.

If none of the above settings / steps has resulted in agents reporting into the endpoint server and displaying as reporting correctly in the agent overview, consider the following:

If the ‘Idle Timeout setting’ is HIGHER than ‘HeartBeat interval setting’, only then will the Heartbeat settings come into picture. So with default values of these settings, here is what happens:

After polling interval, agent initiates connection with server, exchanges all data.

After all data has been exchanged and nothing more is left to communicate, the connection becomes idle and after 30 seconds, the idle timeout is reached, the agent disconnects gracefully.

Here is what would happen, if the value of the ‘Idle Timeout’ was set to a higher value (w.r.t heartbeat interval), say 20 mins  (1200 seconds):

After polling interval, agent initiates connection with server, exchanges all data.

Connection remains active. Server sends a heartbeat after 270 seconds; agent gets informed that server is still up and running and this also helps work around the issues caused by devices like Firewall (that can break connections after some idle time). These heartbeats server as kind-of keep-alive packets. All this while, the Idle timer will keep running because Heartbeats packets do not reset the Idle timer.

After 20 mins (consider polling interval in this case is >20 mins, say 25 mins), only heartbeats are getting exchanged between server and agent. In this case, the Idle Timer times out and the connection is broken.

Consider a scenario where the Server shuts down for some reason or there is some other problem with the EPS. In this case, the heartbeats won’t reach the agent. In this case, the CommLayer.NO_TRAFFIC_TIMEOUT_SECONDS (300 seconds) will be reached and agent decides there is something wrong with the EPS and so it will consider the connection broken.

Once an agent has remained disconnected for(18hours by default) it will show up as not reporting within the agent overview screen.  The 18 hour window is configurable under System -> Settings -> General on the enforce server.