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.
This setting controls when the server will close the connection on an endpoint agent if it has not received any traffic from the agent. Under normal circumstances, this setting should not come into play. Agents should transfer all data and disconnect well before this time is reached. This should be left at the default of 300 seconds.
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 behavior for agents is to disconnect. This should be left at the default of 270 seconds.
When an agent checks in during its normal polling interval, after it has transferred all data, it will wait this duration before disconnecting. This is considered normal and default behavior. 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 labeled ‘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.
Server Properties files
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.
‘Forcing’ 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. This is often not the case.
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 TECH231963 for more details.
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 signaling 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.
If the settings on the Load Balancer may be problematic, alter the agent’s settings to connect directly to an endpoint server (TECH221327). You may also need to force an update of the agent(See section 4 above)
If the above steps still result in an agent that appears to be online from a connectivity standpoint. The aggregator logs indicate that the agent is checking in as expected, and no errors are shown in the aggregator logs. It may be possible that an agent update has gotten ‘stuck’ somewhere.
Start by forcing an agent to directly connect to a single endpoint server. (TECH221327)
Shut down VontuMonitor on that Endpoint Server
Delete any files found in SymantecDLP/Protect/agentupdates and SymantecDLP/Protect/agentatttributes.
Restart Monitor controller on Enforce.
Start VontuMonitor on the Endpoint Server.
Update the agent’s configuration to force an update.
Subscribing will provide email updates when this Article is updated. Login is required.