Make sure that the vShield Endpoint Thin Agent driver is installed on the virtual machine. To check if it is running:

1. Open the run dialog box in the virtual machine.
2. Type the "msinfo32" command.
3. Go to Software Environment > System Drivers.
4. Make sure that the VM drivers, vmci, and vsepflt, are running.

   

To verify vsepflt.sys filter driver installation using the command c:\Windows\system32\fltmc, follow these steps:

1. Open the Command prompt with administrator permission on Windows Guest VM.
2. Enter the command 'fltmc' to verify the vsepflt filter driver is present or not.

   

By default, VMware tools installation do not install vShield drivers. Perform installation using the Complete or Custom option and manually select the Guest Introspection drivers.

Depending on the VMware tools version, the Guest Introspection Drivers may be listed as vShield Drivers or NSX File Introspection Drivers.

Verify that the Deep Security Manager is syncing properly with the vCenter Server and NSX Manager.

1. On the DSM console, go to Computers.
2. Right-click the vCenter Server and choose Properties.
3. On the General tab, click Synchronize Now.

   

4. If the sync fails, check if the vCenter Server and NSX Manager credentials are correct. The vCenter/NSX Manager certificate may also need to be updated.
5. If the vCenter Synchronization is unusually slow or taking a significant amount of time (with no actual errors shown in DSM console), this could indicate a problem with synchronization. More likely, both the status of DSVA and Protected Agentless machines are not synchronized with DSM, thus the machines are shows as "Anti-Malware Engine Offline". In this case, check the server0.log of DSM, or try restart DSM Service and check if this helps solving the vCenter Synchronization issue. After a successful vCenter Synchronization, perform both a Clear Warnings/Errors and a Check Status on the affected agentless machines. This scenario has been observed to happen after DSM has been upgraded. The solution is to restart DSM Service or reboot the DSM Server.

• For NSX-V

  Check if the vCenter Server is properly registered and connected to the NSX Management Service.

  

• For NSX-T

  Check the connection status. From the NSX-T manager web console go to System > Configuration > Fabric > Computer Managers.

  

For the complete procedure, refer to this VMware article: Register vCenter Server with NSX Manager.

• For NSX-V

  Verify that the Guest Introspection and Deep Security service deployments has no errors under Networking and Security > Installation > Service Deployments tab.

  

  Before Deep Security Manager 11.0, when deploying DSVA from NSX manager with NSX for vShield Endpoint license, the "VMware Network Fabric" missing dependency alert will pop up. It is suggested to ignore the alert and force the DSVA deployment by clicking Failed and then click Resolve. The DSVA deployment will be successful, but the status of Trend Micro Deep Security still shows "Failed". You can ignore it as no Deep Security function actually fails.

• For NSX-T

  Check Deep Security service deployments. From the NSX-T manager web console go to System > Configuration > Service Deployments.

  

• For NSX-V

  Make sure that NSX Security Groups and NSX Policy for Deep Security exist and the affected VM exist on the Security Group's VM list.

  1. In vSphere Web Client, go to Home > Networking & Security > Service Composer > Security Groups and make sure that Deep Security group exist.

     

  2. Go to Home > Networking & Security > Service Composer > Security Policies and make sure that Deep Security policy exist.

     

      

     If either of Security Group or Security Policy for Deep Security does not exist, create these by following the instructions in an article from the Deep Security Help Center: Create NSX security groups and policies.

      

  3. Go to Home > Networking & Security > Service Composer > Security Groups and make sure that the affected VM exists in list of VMs on the Deep Security Group.

     

     If the affected VM doesn't exist on this list, edit the Deep Security Group and modify the "Select objects to include" so that it includes the cluster where the agentless protected VM resides. Refer to the Deep Security Help Center article: Create NSX security group and policies.

  On the Deep Security Manager console, make sure that the Trend Micro Deep Security Appliance version is displayed as higher than 9.5.2-2202. The appliance's initial version is 9.5.2-2202 which will be automatically upgraded to higher version provided that the Deep Security Manager has the latest Agent-RedHat_EL6 package available in it's software list.

  

• For NSX-T

  Create a security group from NSX-T manager web console under Inventory > Groups. Add Group with specific Group name including the Computer Members Criteria, to ensure the target VMs are listed as members.

  

  

  To add Endpoint Protection rules and Service Profiles for Anti-Malware protection, from NSX-T manager web console go to Security > Endpoint Protection Rules > Add Policy and Add rule with Security Group and Service Profile.

  

  Under Add Service Profile section, input specific name and select Vendor Template to sync from Trend Micro DSM server.

  

  This ensures that the target Guest VM is listed on membership of Security Group and Service Profile assigned.

Check the Deep Security Virtual Appliance (DSVA).

1. Log on to DSVA via console or SSH. Follow the procedure in this article: Enabling SSH access on Deep Security Virtual Appliance (DSVA).
2. Execute the "ifconfig –a" command. The following should appear:

   

3. Check if the AM process listens to 48651.

   ~$netstat -ant | grep 48651

   

Check the vShield driver on ESXi.

• For NSX-V
  1. Log on to ESX via SSH.
  2. Execute the "ps | grep vShield-Endpoint-Mux" command. The following appears:

     

  3. Verify if the vShield Endpoint Service on ESX/ESXi is running using the following command:

     ~ # /etc/init.d/vShield-Endpoint-Mux status

     If you need to restart, run the following:

     ~ # /etc/init.d/vShield-Endpoint-Mux restart

     

  4. Verify that the DSVA is registered with the vShield Endpoint, run the following command:

     ~ # esxcfg-advcfg --get /UserVars/RmqIpAddress

     ~ # esxcfg-advcfg --get /UserVars/RmqPort

     

     Based on the sample above, RmpIpAddress is the NSX Manager.

  5. Verify that the TCP connection between the vShield-Endpoint-Mux and DSVA is established:

     ~# esxcli network ip connection list | grep vShield

     

• For NSX-T
  1. Log on to ESX via SSH.
  2. Execute the "ps | grep nsx-context-mux" command. The following appears:

     

  3. Verify if the vShield Endpoint Service on ESX/ESXi is running using the following command:

     ~ # /etc/init.d/nsx-context-mux status

     

     If you need to restart, run the following:

     ~ # /etc/init.d/nsx-context-mux restart

     

  4. Get the NSX-T manager IP address that ESXI host registered via nsxcli command:

     ~# nsxcli -c get managers

     

  5. Verify that the TCP connection between the vShield-Endpoint-Mux and DSVA is established:

     ~# esxcli network ip connection list | grep mux

     

  6. Verify that the Guest VMs are DSVA protected on the ESXI host, then check the file /var/run/muxconfig.xml file that includes all Guest VMs vCenter UUID, Solution ID and tag ID (vendor template ID).

     

If it fails to connect to 169.254.1.1.24:48655, the following is visible on the ESXi syslog.log:

014-07-18T08:05:35Z EPSecMux[35465]: [INFO] (EPSEC) [0x8a89]  SolutionHandler[0x1f0026a0] connected to solution[100] at [169.254.1.24:48655]  2014-07-18T08:05:35Z EPSecMux[35465]: [WARNING] (EPSEC) [0x8a89] Unknown attribute: 0x19

As a workaround:

1. Open the Security Group on the NSX setting.
2. Exclude the offline guest VM.
3. Re-apply the policy to the Security Group.
4. Add the offline guest VM.
5. Re-apply the policy to the Security Group.

Transferring virtual machines through vMotion in NSX environment causes Anti-Malware Engine to show offline status. This happens because Deep Security Manager (DSM) has already checked the status of the VMs during heartbeat before the actual completion of vMotion process.

Waiting for the next heartbeat, which is 10 minutes by default, will fix the offline status.

As a workaround:

1. Right-click the affected virtual machine.
2. Select Actions and click Clear Warnings/Errors.
3. Click Actions again and click Check Status.

A virtual machine (VM) may also report an "Anti-Malware Engine Offline" status in Deep Security Manager (DSM) after executing a Storage vMotion in an activated state. Storage vMotion provides a new UUID to the virtual machine, as explained in this VMware article: Changing or keeping a UUID for a moved virtual machine.

The new UUID would be unknown to the vShield Manager/NSX, Deep Security Virtual Appliance, or DSM, but would be recognized as protected via vCenter connection. Therefore, DSM reports "Anti-Malware Engine Offline".

To prevent this situation, do the following:

1. Deactivate the VM before performing a Storage vMotion.
2. Perform the Storage vMotion.
3. Activate the VM again after the process.

You see the message "Anti-Malware Engine Offline" for the vApp VMs after they are deployed from a catalog/template from vCloud Director and integrated with Deep Security. The issue occurs because all instances and virtual machines deployed from a given catalog/vApp template from vCloud Director are given the same BIOS UUID.

Because Deep Security distinguishes different VMs by their BIOS UUID, a duplicate value in the vCenter causes an "Anti-Malware Engine Offline" error to the VMs in vCloud, when integrated with Deep Security.

To resolve the issue, create a new unique uuid.bios entry. For the procedure, refer to this VMware KB article: BIOS UUIDs in vCloud Director are not unique when virtual machines are deployed from catalog templates.