Views:
A computer status of "Offline" or "Managed (Offline)" means that Server & Workload Protection hasn't communicated with the agent's instance for some time and has exceeded the missed heartbeat threshold. The status change can also appear in alerts and events.

Causes Parent topic

Heartbeat connections can fail because:
  • The agent is installed on a workstation or other computer that has been shut down. When you power the computer back on, the error will resolve on the next heartbeat interval.
  • Firewall, IPS rules, or security groups block the heartbeat port number.
  • Outbound (ephemeral) ports were blocked accidentally. See Activation Failed - Blocked port for troubleshooting tips.
  • Bi-directional communication is enabled, but only one direction is allowed or reliable.
  • Computer is powered off.
  • Computer has left the context of the private network. This can occur if roaming endpoints (such as a laptop) cannot connect to Server & Workload Protection at their current location. Guest Wi-Fi, for example, often restricts open ports, and has NAT when traffic goes across the Internet.
  • Amazon WorkSpace computer is being powered off, and the heartbeat interval is fast, for example, one minute; in this case, wait until the WorkSpace is fully powered off, and at that point, the status should change from 'Offline' to 'VM Stopped'.
  • DNS was down, or could not resolve the Server & Workload Protection hostname.
  • Server & Workload Protection, the agent, or both are under very high system resource load.
  • The agent process might not be running.
  • The agent's system time is incorrect (required by SSL/TLS connections).
  • Rule update is not yet complete, temporarily interrupting connectivity.
  • On AWS EC2, ICMP traffic is required, but is blocked.
Tip
Tip
If you are using manager-initiated or bi-directional communication, and are having communication issues, we strongly recommend that you change to agent-initiated activation (see Activate and protect agents using agent-initiated activation and communication). To troubleshoot the error, verify that the agent is running, and then that it can communicate with Server & Workload Protection (the manager).

Verify that the agent is running Parent topic

On the computer with the agent, verify that the agent service is running. Method varies by operating system.
  • On Windows, open the Microsoft Windows Services Console (services.msc) or Task Manager. Look for the service named ds_agent.
  • On Linux, open a terminal and enter the command for a process listing. Look for the service named ds_agent or ds-agent, such as:
sudo ps -aux | grep ds_agent
sudo service ds_agent status
  • On Solaris, open a terminal and enter the command for a process listing. Look for the service named ds_agent, such as:
sudo ps -ef | grep ds_agent
sudo svcs -l svc:/application/ds_agent:default

Verify DNS Parent topic

If agents connect to Server & Workload Protection via its domain name or hostname, not its IP address, test the DNS resolution:
nslookup [manager domain name]
DNS service must be reliable.
If the test fails, verify that the agent is using the correct DNS proxy or server (internal domain names can't be resolved by a public DNS server such as Google or your ISP). If a name such as dsm.example.com cannot be resolved into its IP address, communication will fail, even though correct routes and firewall policies exist for the IP address.
If the computer uses DHCP, in the computer or policy settings, in the Advanced Network Engine area, you might need to enable Force Allow DHCP DNS (see Computer and policy editor settings).

Allow outbound ports (agent-initiated heartbeat) Parent topic

Telnet to required port numbers on the manager to verify that a route exists, and the port is open:
telnet agents.deepsecurity.trendmicro.com:443
If telnet fails, trace the route to discover which point on the network is interrupting connectivity.
Adjust firewall policies, routes, NAT port forwarding, or all three to correct the problem. Verify both network and host-based firewalls, such as Windows Firewall and Linux iptables. For an AWS EC2 instance, see Amazon's documentation on Amazon EC2 Security Groups for Linux Instances or Amazon EC2 Security Groups for Windows Instances. For an Azure VM instance, see Microsoft's Azure documentation on modifying a Network Security Group.

Allow ICMP on Amazon AWS EC2 instances Parent topic

In the AWS cloud, routers require ICMP type 3 code 4. If this traffic is blocked, connectivity between agents and the manager may be interrupted.
You can force allow this traffic in Server & Workload Protection. Either create a firewall policy with a force allow, or in the computer or policy settings, in the Advanced Network Engine area, enable Force Allow ICMP type3 code4 (see Computer and policy editor settings).

Fix the upgrade issue on Solaris 11 Parent topic

A problem may occur if you previously installed version 9.0 of the agent on Solaris 11, and then upgraded the agent software to 11.0 directly without first installing 9.0.0-5616 or a later 9.0 agent. In this scenario, the agent may fail to start up after the upgrade and may appear as offline in Server & Workload Protection. To fix this issue:

Procedure

  1. Uninstall the agent from the server. See Uninstall the Server & Workload Protection Agent.
  2. Install an 11.0 agent. See Install the agent manually.
  3. Re-activate the agent in Server & Workload Protection. See Activate the agent.

What to do next