To fix this issue, check existing policy and place it with a new one, if it has non-Latin characters in its name:

1. In the NSX web console: Navigate to Security → Endpoint Protection Policies.

2. Delete the existing policy with Non-Latin characters in its name.

3. Create a new policy using English-only naming conventions.

Error Failed to get IP addresses for connecting to SVM appears during SVM deployment.

Solution

To troubleshoot this problem, you need to follow our step-by-step guide:

I. Disable SVM rollback

• Go to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIIS Console\ for KSV LA 5.1 or to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIISLA Console for KSV LA 5.2
• Edit the Kaspersky.VIISConsole.UI.exe.config file
• Uncomment <!--<add key="disableRollback" value="1" />--> (delete <!-- and-->)
• Save changes

II. Enable VIIS traces

• Go to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIIS\ for KSV LA 5.1 or to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIISLA for KSV LA 5.2
• Open NLog.config file in a text editor
• Find the line <logger name="*" minlevel="Info" writeTo="file"/> and change minlevel value from Info to Trace
• Save changes

III. Enable extended logging of deployment wizard

• Go to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIIS Console\ for KSV LA 5.1 or to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIISLA Console for KSV LA 5.2
• Open NLog.config file in a text editor 
• Find the line <logger name="Kaspersky.Virtualization*" minlevel="Info" writeTo="DeployWizardLog" final="true"/> and change minlevel value from Info to Trace for KSV LA 5.1 and <logger name="DeployWizardFileLogger" minlevel="trace" writeTo="DeployWizardLog" final="true"/> and change minlevel value from off to Trace for KSV LA 5.2
• Save changes

IV. Start troubleshooting

1. Start SVM deploying wizard and don’t forget to enable option Allow remote access via SSH for root account.
2. Wait for the error and then, make sure that deployment wizard skipped rollback step.
3. Disable all traces returning to the previous values.
4. Connect to SVM directly, using hypervisor.

5. Login to SVM OS under the root account, using default password 7czWtTKhCgrvEYBHb3rE

   This password can be applied only during troubleshooting process with disabling SVM rollback and it wouldn't work with normally deployed SVMs.
6. Use command ifconfig to check if the SVM received network adapter settings, specified at the beginning of installation.
7. Try to establish connection by SSH from KSC (where VIIS installed) to the SVM. If SSH connection fails, then there are no issues with Kaspersky product. You should configure the environment according to our system requirements. Especially, at the side of ports accessibility. Configuring ports used by the application

8. If the SSH connection established successfully, please collect the following data and send it to Kaspersky Support: 

   Data to be collected

   • Screenshot of network settings that has been applied to the SVM
   • VIIS log from - C:\ProgramData\Kaspersky Lab\VIIS\logs for LA 5.1 and C:\ProgramData\Kaspersky Lab\VIISLA\logs\ for LA 5.2
   • Deployment wizard detailed log from - C:\Users\<Account>\AppData\Local\Kaspersky_Lab\ViisConsole for LA 5.1 and  C:\Users\<Account>\AppData\Local\Kaspersky Lab\Kaspersky VIISLA Console\logs\ for LA 5.2
   • /var/log/ – from SVM
   • /var/opt/– from SVM

Network security assessment tools detect multiple vulnerabilities in the SVMs.

Workaround & Solution

Below is a list of detected vulnerabilities and solutions or reasons why it can't be fixed.

Open ports

SVMs have ports 22 and 80 open for communication with the Deployment Wizard and providing updates to Light Agents respectively. They are hardcoded, and therefore can't be changed or closed without at least partially breaking functionality of the product.

Browsable Web Directories

SVMs use them to share updates with Light Agents, and Light Agents need to be able to check for updates. This is not a problem as there are only read-only Light Agent updates available there.

Weak SSH encryption

By default SVMs use weak ssh key exchange algorithms. To fix that without losing ability to configure the SVM via Deployment Wizard, add the following in /etc/ssh/sshd_config on SVMs:

This article describes how to install a patch on multiple SVMs at once via Kaspersky Security Center.

Details

• Create an installation package from a .kud file included with the patch
  • Advanced → Remote installation → Installation packages → Create installation package
    
  • Choose Create an installation package for a Kaspersky application
  • Choose a name for the package
  • Select the .kud file in the file picker
• Create a remote installation task for that package
  • Select the installation package → Install application
    
  • If there is a separate group for SVMs, choose Install on a group of managed devices, otherwise choose Select devices for installation
  • Select the administration group/devices to install the patch on
  • Use default installation settings
  • Choose Do not place license key in installation package
  • Choose No account required
  • Start patch installation

1. Create Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2
2. Launch Group On Demand Scan Task

Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 might detect infected object, but might not delete it.

Solution: 

1. Delete created Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2
2. Delete all created Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 Policies
3. Add registry key on Kaspersky Administration Server
   1. 5_2_ksc_win_x86_fix.reg if Kaspersky Administration Server is installed on x86 operation system
   2. 5_2_ksc_win_x64_fix.reg if Kaspersky Administration Server is installed on x64 operation system
4. Create Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 Policies anew.
5. Create Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2
6. Launch Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2

Supported vSphere by Kaspersky Agentless solution
Usage of NSX version 3.2+
Deployed Kaspersky Agentless 6.1 Antivirus or/and Network Attack Blocker Appliance

Problem

Anew registration and Kaspersky Agentless 6.1 Antivirus or/and Network Attack Blocker Appliance deployment completes successfully.
By attempt to create Service Profile for Kaspersky Agentless 6.1 Antivirus or/and Network Attack Blocker fails with error
AntiVirus and Network Attack service registration might fail with the error "Service Definition id <ID> <Kaspersky Component> not found in MP

Root cause

NSX-T does not delete service references of Kaspersky Agentless 6.1 Antivirus or/and Network Attack Blocker Appliance

Solution

• Through terminal like putty you need access to NSX-T appliacnce and launch the command 

           curl  -kG https://admin:<PASSWORD>@<nsx-t address>/policy/api/v1/infra/service-references

The path value should be remembered for Kaspersky File Antimalware Protection and for Kaspersky Network Protection

• Delete service reference by path value by launching the command

          curl -kX DELETE https://admin:<PASSWORD>@<nsx-t address>/policy/api/v1/<value of path>

• After it delete previously created profile service for Kaspersky Agentless 6.1 Antivirus or/and Network Attack Blocker and create it anew

Unexpectedly it can be observed that KSV AL 6.1 starts to be unavailable in Kaspersky Security Center as shown on the screenshot.

Root cause

The most probable cause of this issue is expired Kaspersky Security Certificate and new generated one is not transferred to KSV AL 6.1. 

KSV AL 6.1 does not have functionality to automatically update certificate from Kaspersky Security Center.

Workaround

The script klmover should be launched on KSV AL 6.1 to reconnect to the Kaspersky Security Center. This script performs some steps, including a certificate update. 

The script resides in /opt/kaspersky/klnagent64/bin.

1. Shutdown Kaspersky Agentless Appliance
2. Disable the option "Сonfigure/vApp Options/edit/OVF Details/OVF environment transport/ISO image" for Kaspersky Agentless Appliance
3. Launch Kaspersky Agentless Appliance

When deploy the SVM of KSV LA on the vSphere 6.5, the following error may occur:

Reason：

This issue occurs because vCenter Server cannot detect any vSAN storage provider. There is no way to detect vSAN storage provider if no hosts are available when vCenter Server starts.

Note: vSAN storage provider cannot be recognized automatically even after host start working properly.

Workaround:

This is a known issue affecting vCenter Server.

To workaround this issue, you have the following options:

1. Initiate synchronizing vSAN storage provider by clicking icon for synchronization in the page:

vCenter Server -> Configure -> Storage Providers

2. Make sure at least one host is working when starting vCenter Server.

Starting from 07/06/2022 it is possible to add exclusions from protection against external encryption using "Exclusions" tab under "Exclusions and trusted applications" settings. 

Steps: 

• Go to "Exclusions and trusted applications" settings and move to "Exclusions" tab
• Add folder/filename (masks are supported) specifying SystemWatcher application component.
• Apply the policy 

The tested exclusions: 

<Drive>:\<Folder>\

<Drive>:\<Folder>\*.enc

<Drive>:\<Folder>\*\*.enc

Example:

• protocol version: v2c
• rocommunity name: public
• listening address and port: 0.0.0.0:161
• access type: read only
• transport: UDP
• logging: syslog

The following statistics can be received from SVM:

Change SNMP community name

• Edit file /etc/snmnp/snmpd.conf
• Change public into the string recommunity on your own
• Save changes
• Restart SNMP daemon - systemctl restart snmpd

Move on SNMPv3

• Stop SNMP daemon - systemctl stop snmpd
• Launch the command - net-snmp-config --create-snmpv3-user -ro -a "authpass" -x "privpass" -X AES -A SHA "user"

1.            "authpass" is the private key/password for generating HMAC when connecting to snmpd, "privpass" is the private key/password for encrypting snmp traffic, "user" is the username for                snmpd. 
2.            "authpass" and "privpass" we can say passwords, which should be generated by you own
3.            "user" - user name for snmpd

           This command will make mpdifications into two files - /etc/snmp/snmpd.conf and /var/lib/net-snmp/snmpd.conf

• Restart SVM

Environment:

• Citrix Virtual Apps and Desktops (Citrix XenApp and XenDesktop) with enabled option Citrix UPL (User Personalization Layer)
• Citrix App Layer 
• Non-English Operation System localization. 

After installation of KSV LA 5.2, you can face the error "The specified path does not exist" which appears by launching any executable file.

Possible root cause

Both Citrix technologies use separate vhd files for creating VMs by using Citrix App Layer and for roaming profiles used by Citrix UPL. As the result, the merge of vhd files processes and Citrix driver returns incorrect path of where the executable files are. 

Workaround

1. Install Kaspersky Light Agent 5.2 and ensure it does not connect to SVM.
2. Disable Self Defense and exit LA.
3. Add registry file from this archive.
4. Launch installation of the latest cumulative patch from the archive (all further released Cumulative PFs will contain the fix as well).
5. As soon as LA informs the restart is needed, restart VMs.
6. Connect LA to SVM.
7. Problem should be solved.

On-Demand Scan exclusion mechanism has not been changed. The following mechanism of exclusions with installed Cumulative Patch for Kaspersky Linux Light Agent 5.2 is applicable to On Access Scanning only.

1. File Scanning Exclusion (an exclusion does not end with ‘/’)

If the option "Include subfolders" is enabled for exclusions from file scan, the label "IGNORE fanotify" will be set for this file. In this case, processing of an object with the excluded file will not be intercepted by Kaspersky Linux Light Agent 5.2 at all.

2. Folder exclusion (an exclusion ends with "/") without the enabled option "Include subfolders"

This exclusion will be processed by Kaspersky Linux Light Agent 5.2 after the excluded folder is intercepted and file operation resolved.

3. Folder exclusion (exclusion ends with "/") with the enabled option "Include subfolders"

This type of exclusion can be split into two processing mechanisms:

• Excluded folder is not a mount point.

This exclusion will be processed by Kaspersky Linux Light Agent 5.2 after the excluded folder is intercepted and file operation resolved.

If one of the subfolders in the excluded folder is a mount point, this subfolder will be ignored and not scanned, without processing this exclusion by Kaspersky Linux Light Agent 5.2. It means that this subfolder is excluded on the low level (fa-notify).

•  Excluded folder is a mount point.

In this case this folder and all its subfolders (including the subfolders which might be mount points) will be excluded without Kaspersky Linux Light Agent 5.2 interception and resolving all subfolders, i.e. exclusions are set on the low level (fa-notify).

Local installation: 

1. Copy the *.sh file on the Linux VM with Kaspersky Light Agent 5.2 installed.
2. Grant execution access: chmod +x <path_to_file/*.sh file>
3. Run the command /path_to_file/*.sh --install 

Remote Installation through Kaspersky Security Center: 

1. Create installation package based on the kud file.
2. Create remote installation task and assign it to the Linux VMs with Kaspersky Linux Light Agent 5.2 installed.

The version of Kaspersky Linux Light Agent will be changed to the version specified in the name of the cumulative patch for Kaspersky Linux Light Agent 5.2.

The symptoms of the issue are:

1. Installation/upgrade of KSV LA 5.2
2. vSphere Virtual Machine is unresponsive after KSV LA 5.2 installation

Based on the investigation results the problem related to NSX Introspection Drivers coming with VMware Tools. There is the article about it: https://kb.vmware.com/s/article/78016

Solution: 

1. The best option is to uninstall NSX File Introspection and NSX Network Introspection by modifying VMware Tools on a virtual machine.
2. Try to upgrade VMware Tools up to the latest supported by vSphere version.

Currently KSV LA 5.2 supports installation on Windows Server 2022 and Windows 11.

Error Failed to get IP addresses for connecting to SVM appears during SVM deployment.

Solution

To troubleshoot this problem, you need to follow our step-by-step guide:

I. Disable SVM rollback

• Go to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIIS Console\ for KSV LA 5.1 or to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIISLA Console for KSV LA 5.2
• Edit the Kaspersky.VIISConsole.UI.exe.config file
• Uncomment <!--<add key="disableRollback" value="1" />--> (delete <!-- and-->)
• Save changes

II. Enable VIIS traces

• Go to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIIS\ for KSV LA 5.1 or to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIISLA for KSV LA 5.2
• Open NLog.config file in a text editor
• Find the line <logger name="*" minlevel="Info" writeTo="file"/> and change minlevel value from Info to Trace
• Save changes

III. Enable extended logging of deployment wizard

• Go to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIIS Console\ for KSV LA 5.1 or to C:\Program Files (x86)\Kaspersky Lab\Kaspersky VIISLA Console for KSV LA 5.2
• Open NLog.config file in a text editor 
• Find the line <logger name="Kaspersky.Virtualization*" minlevel="Info" writeTo="DeployWizardLog" final="true"/> and change minlevel value from Info to Trace for KSV LA 5.1 and <logger name="DeployWizardFileLogger" minlevel="trace" writeTo="DeployWizardLog" final="true"/> and change minlevel value from off to Trace for KSV LA 5.2
• Save changes

IV. Start troubleshooting

1. Start SVM deploying wizard and don’t forget to enable option Allow remote access via SSH for root account.
2. Wait for the error and then, make sure that deployment wizard skipped rollback step.
3. Disable all traces returning to the previous values.
4. Connect to SVM directly, using hypervisor.

5. Login to SVM OS under the root account, using default password 7czWtTKhCgrvEYBHb3rE

   This password can be applied only during troubleshooting process with disabling SVM rollback and it wouldn't work with normally deployed SVMs.
6. Use command ifconfig to check if the SVM received network adapter settings, specified at the beginning of installation.
7. Try to establish connection by SSH from KSC (where VIIS installed) to the SVM. If SSH connection fails, then there are no issues with Kaspersky product. You should configure the environment according to our system requirements. Especially, at the side of ports accessibility. Configuring ports used by the application

8. If the SSH connection established successfully, please collect the following data and send it to Kaspersky Support: 

   Data to be collected

   • Screenshot of network settings that has been applied to the SVM
   • VIIS log from - C:\ProgramData\Kaspersky Lab\VIIS\logs for LA 5.1 and C:\ProgramData\Kaspersky Lab\VIISLA\logs\ for LA 5.2
   • Deployment wizard detailed log from - C:\Users\<Account>\AppData\Local\Kaspersky_Lab\ViisConsole for LA 5.1 and  C:\Users\<Account>\AppData\Local\Kaspersky Lab\Kaspersky VIISLA Console\logs\ for LA 5.2
   • /var/log/ – from SVM
   • /var/opt/– from SVM