DLP Agent status not reporting as expected on Enforce
search cancel

DLP Agent status not reporting as expected on Enforce

book

Article ID: 170468

calendar_today

Updated On:

Products

Data Loss Prevention Endpoint Prevent Data Loss Prevention

Issue/Introduction

Agents that are expected to be reporting(green) are in a non-reporting state(red), or vice versa within the agent overview.

Environment

DLP 15.8+
 

Resolution

Basic network connectivity

Verify the Agent machine can ping the Endpoint server by name or IP address.

Check both Agent and Aggregator logs for errors.

Within the agent logs, look for the lines following CurlTransportLayer and ServerCommunicatorService. You may notice certificate errors such as handshake failures.

Within the aggregator logs, any communication errors should result in a severe error that describes the problem.

Performance Tuning

There are many settings that relate to performance and convenience within various properties files and the advanced agent settings.

Advanced Agent settings:

ServerCommunicator.CONNECT_POLLING_INTERVAL_SECONDS.int

This setting controls how often an agent checks in with the Endpoint Server. This should generally be left at the default of 15 minutes (900 seconds). If this has been decreased, it should not be decreased below 1 minute per every 1000 agents.

CommLayer.NO_TRAFFIC_TIMEOUT_SECONDS.int

This setting controls when the agent will close the connection if no traffic or heartbeat has been received from the server.  Under normal circumstances, this setting should not come into play. Agents should transfer all data and be disconnected by the server well before this time is reached. This should be left at the default of 300 seconds.

EndpointCommunications.HEARTBEAT_INTERVAL_IN_SECONDS.int

This setting controls when the server will send a heartbeat to the agent to detect if it is still connected. This setting is only used if the agent idle timeout is disabled. The normal, expected behaviour is for traffic to cease for 30 seconds, thus causing the server to disconnect the agent after CommLayer.NO_TRAFFIC_TIMEOUT_SECONDS This should be left at the default of 270 seconds.

EndpointCommunications.IDLE_TIMEOUT_IN_SECONDS.int

This setting controls when the server will disconnect the agent. When an agent checks in during its normal polling interval, after it has transferred all data, and then remains idle. After 30 seconds of this idle connection, the server will initiate a disconnect on the agent. This is considered normal and default behaviour. This should be left at the default of 30 seconds.

Enforce General Settings

Not reporting time

When navigating to System -> Settings -> General within Enforce, there is a setting labelled ‘Show Agent as "Not Reporting" after’.  This setting controls how long Endpoint Server will wait before it reports to Enforce that the agent has stopped reporting. The default is 18 hours. This setting can be raised or lowered depending on preferences, however, it cannot be made lower than ServerCommunicator.CONNECT_POLLING_INTERVAL_SECONDS.int. Best practice for the "Agents not reporting after" interval is 18 - 72 hr. See Article 161961 for more details.

Server Properties files

MaxQueueSize

Both MonitorController.properties and Aggregator.properties on the endpoint server have a setting of MaxQueueSize. This setting controls how many tasks can be queued on each of the respective servers. The default value is 5000. It is recommended that this value be increased. On Aggregator.properties we should use a value of 2x the number of agents that regularly connect to that server. On MonitorController.properties this should be increased to 10,000.

Communication.properties (config file on the Detection Server)

acceptTimeout

  By default the acceptTimeout value is set to 60000, which in many cases is not enough time. Most people will find an improvement in their environment by doubling this value and increasing the acceptTimeout value from 60000 to  120000 allowing more time for commands to be accepted before they timeout.

Triggering an update

Often times, it is assumed that ‘Last Update Time’ refers to the last time the agent checked in. This is false. The ‘Last Update Time’ is only updated when agents' attributes or statuses receive a new update in the oracle database. 

In order to force an update of ‘last update time’, we can modify the description of the agent configuration applied to that agent. This will force an update that will update the agent’s last update time. See Article 162207 for more details.

Load Balancers.

When agents are connected to their endpoint servers. A couple of considerations are needed.

      • SSL Session Persistence. This refers to whether or not an agent will reuse the same session ID on consecutive handshakes with the server. This should not directly impact agent reporting status
      • Server Affinity. This refers to what server a load balancer will decide to connect an agent to when they check in. In general an agent should check into the same server as it did previously whenever possible. This is because of the strong relationship between ‘Connect_Polling_Interval’ in the advanced agent settings and ‘Not Reporting Time’ in the Enforce General Settings.

Since the entity responsible for signalling to Enforce that an agent is not reporting is an Endpoint server, this occurs as soon as its ‘Not Reporting Time’(18 hours by default) has been reached. If an agent checks in with different servers on each polling interval, then the chance that it will not connect to a server for 18 straight hours is highly likely. At this point, the endpoint server will report the agent as ‘Not Reporting’ despite the agent being successfully connected to another endpoint server.

Cache Deletion

In some scenarios, the agent may be communicating with a different Endpoint Server than expected, causing the status of the agent to remain unchanged in Enforce. Deleting the Endpoint Server cached information may resolve this issue.

  1. Ensure that the endpoint agent is communicating directly to an endpoint server. If it's load balanced we want to force traffic to a specific endpoint server.
  2. On the Detection server shut down Symantec DLP Detection Server service.
  3. On that same Detection server navigate to the following directory and delete all files except agentconnectionstatus.ser

C:\ProgramData\Symantec\Data Loss Prevention\DetectionServer\<version>\agentattributes

    • Linux:

/var/Symantec/DataLossPrevention/DetectionServer/<version>/agentattributes

  1. Restart Symantec DLP Detection Server Controller Service on the Enforce Server.
  2. Start Symantec DLP Detection Server Service on the Endpoint Detection Server.

Additional Information

See also: Key DLP agent and Endpoint Server communications settings

See also: Agents send duplicate incidents

See also: DLP Agent status not reporting as expected on Enforce

See also: Configuring Agent Connection Status "Not Reporting" after

See also: About using load balancers in an endpoint deployment