Known issues in
Cloud Workload Protection

The following table lists the issues present in this release of
Symantec Cloud Workload Protection
:
Known issues related to SEP agent upgrade
Number
Issue
1
Sometimes, after you upgrade to the Symantec Endpoint Protection (SEP) agent, you will still find the SEP Cloud agent icon in the Windows
Start
menu.You can delete the shortcut manually from the
Start
menu.
2
After the enrollment of the agent and the policy is applied, several Policy Enforcement jobs might be created on the instance that do not complete successfully, but aborts after several hours. Only the last job that completes successfully. You can ignore the aborted jobs as the policy is already applied.
3
Certain properties of the events generated by the SEP agent can be different from that of similar events that were sent by the SEP Cloud agent. For example,
  1. Event severity can differ
  2. Event description can be different or can be empty
  3. Threat remediation events are not generated by the SEP agent
4
Upgrade to the SEP agent might fail if the prevention policies are enabled during the upgrade.
Workaround
: Do either of the following:
  • Make sure that the Windows Global Policy (Windows Global Policy -> Policy State -> Disable Prevention - Log but do not prevent policy violations) is in
    ON
    state.
  • Make sure that the Policy Group's (Symantec Default Policy Group) prevention capability is in
    OFF
    state.
5
After the SEP agent is installed, there is up to a twenty minutes delay for the Anti-malware policies to apply on the instances. Till then the Policy Enforcement job will remain in the pending state.
6
Sometimes, after the deployment of the agent on the Windows instances, the displayed device policy status can be "Not applied". However, in reality, the policy is applied and the device is protected.
Workaround:
Do the following:
Reapply the policy on the Windows instances to display the correct status.
Other known issues of
Symantec Cloud Workload Protection
Number
Issue
1
For
Azure
connections, reassigning of active subscriptions to another application is not supported. If you remove a subscription from an existing application and assign it to another application, system shows inconsistent details of the corresponding virtual machines.
If you want to modify an active subscription, delete the associated connection and create a new connection in
Cloud Workload Protection
.
2
The yellow colored ring on the
Security Posture by Region
widget of dashboard denotes the count of instances that do not have any policy applied. This count includes instances where agent is installed and instances where agent is not installed.
3
In some scenarios, if you do not have access to a
Cloud Workload Protection
account, the console displays an “Access Denied” message only in English.
Log on through landing using a valid
Cloud Workload Protection
account.
4
If you have installed
Cloud Workload Protection
and Symantec Endpoint Protection Cloud (SEP Cloud) agents on the same instance and if you uninstall the SEP Cloud agent, the
Cloud Workload Protection
agent behaves unexpectedly. This issue is observed only if you have
Prevention
(IPS) enabled policy group applied on the instance.
Workaround: In such a scenario, disable IPS in the applied policy group before you uninstall the SEP Cloud agent.
5
If you install the
Cloud Workload Protection
agent on an instance that does not have Internet connection, the agent fails to download the virus and malware definitions when the Internet connection is restored.
Workaround: Restart the AMD service of the agent. Open command prompt with root privilege and run the following command:
For the supported RHEL 7.X and CentOS 7.X instances, type:
systemctl restart sisamddaemon
For the supported RHEL 6.X and Amazon Linux instances, type:
service sisamdagent restart
6
In some specific scenario, the agent fails to initialize the Anti-Malware scan. If you see the error
Unable to initialize scan
in the AMD logs, restart the AMD service. Open command prompt with root privilege and run the following command:
For the supported RHEL 7.X and CentOS 7.X instances, type:
systemctl restart sisamddaemon
For the supported RHEL 6.X and Amazon Linux instances, type:
service sisamdagent restart
7
Because of the default
requiretty
setting on certain RHEL systems, cloning of the Cloud Workload Protection agent is not executed as expected and the cloned instance is not displayed on the Cloud Workload Protection console.
Workaround: Prior to cloning the Cloud Workload Protection agent, navigate to the
/etc/sudoers
file and change the
requiretty
setting to
Defaults:dcscaf !requiretty
. Reboot the system and then clone the system.
8
Installation of the
sdcss-agent
package on the Linux-based Cloud Workload Protection agent by using a package manager (such as APT, Yum, Zypper) may result in a communication breakdown between the CAF service of the agent and the Cloud Workload Protection server. In such a situation, the CAF log (located at
/var/log/sdcss-caflog/cafagent.log
) displays an error message:
CSPAdapter failed to fetch technology status from the agent
.
Workaround: Restart the CAF service by running the command
service cafagent restart
.
9
If you manually upgrade the agent from an earlier version to the newer version on a Red Hat Enterprise Linux 7 system, the upgrade is successful. However, the following error message is displayed:
/usr/bin/systemd-tty-ask-password-agent: error while loading shared libraries: libgcc_s.so.1: failed to map segment from shared object: Permission denied
You can ignore this error message. This error message does not have any functional impact.