Overview

This error may be caused by non-Latin characters in the policy name. 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.

Problem 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 Start SVM deploying wizard and don’t forget to enable option Allow remote access via SSH for root account. Wait for the error and then, make sure that deployment wizard skipped rollback step. Disable all traces returning to the previous values. Connect to SVM directly, using hypervisor. 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. Use command ifconfig to check if the SVM received network adapter settings, specified at the beginning of installation. 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 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

Problem Description, Symptoms & Impact 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: KexAlgorithms diffie-hellman-group-exchange-sha256

Description and cautions 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

Problem: Create Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.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: Delete created Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 Delete all created Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 Policies Add registry key on Kaspersky Administration Server 5_2_ksc_win_x86_fix.reg if Kaspersky Administration Server is installed on x86 operation system 5_2_ksc_win_x64_fix.reg if Kaspersky Administration Server is installed on x64 operation system Create Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 Policies anew. Create Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2 Launch Group On Demand Scan Task of Windows Kaspersky Light Agent 5.2/Linux Kaspersky Light Agent 5.2

Prerequisetes: 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

Problem Description 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.

To achieve this goal for Kaspersky Agentless 6.1 solution you should: Shutdown Kaspersky Agentless Appliance Disable the option "Сonfigure/vApp Options/edit/OVF Details/OVF environment transport/ISO image" for Kaspersky Agentless Appliance Launch Kaspersky Agentless Appliance

Problem: 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.

Officially exclusions from protection against external encryption are written on this page https://support.kaspersky.com/KSVLA/5.2/en-US/175626.htm 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:

SNMP daemon on SVM should have the following default settings: 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: # Description Name Identifier 4.1 CPU Statistics UCD-SNMP-MIB::systemStats 4.2 Memory Statistics UCD-SNMP-MIB::memory 4.3 Load average statistics UCD-SNMP-MIB::laTable 4.4 Disk statisitcs HOST-RESOURCES-MIB::hrStorageTable 4.5 Network statistics IF-MIB::ifTable 4.7 Amount of desktop VMs connected KSVLA-MIB::ksvlaProtectedDesktopCount 1.3.6.1.4.1.23668.1491.1539.1.1 4.8 Amount of server VMs connected KSVLA-MIB::ksvlaProtectedServerCount 1.3.6.1.4.1.23668.1491.1539.1.0 4.9 ODS running status: - in progress (if all ODS Tasks are running) - waiting (if at least one ODS task is waiting for processing) - none (if no ODS tasks are running/waiting at all) KSVLA-MIB::ksvlaODSStatus 1.3.6.1.4.1.23668.1491.1539.0.0 4.10 ODS queue lenght: amount of VMs awaiting ODS processing KSVLA-MIB::ksvlaODSQueueLenght 1.3.6.1.4.1.23668.1491.1539.0.1 4.11 Amount of simualtaneously running ODS tasks KSVLA-MIB::ksvlaODSTaskCount 1.3.6.1.4.1.23668.1491.1539.0.2 4.12 Current percent of an allowed physical memory consumption - In case of watchdog is on use WDSERVER_MAX_MEM const from ScanServerLaunch.sh as maximum - In case of watchdog is off use 100% as maximum KSVLA-MIB::ksvlaMemoryConsumption 1.3.6.1.4.1.23668.1491.1539.3.0 4.13 Current percent of an allowed swap consumption - In case of watchdog is on use WDSERVER_MAX_SWAP const from ScanServerLaunch.sh as maximum - In case of watchdog is off use 100% as maximum KSVLA-MIB::ksvlaSwapConsumption 1.3.6.1.4.1.23668.1491.1539.3.1 4.14 Main processes state (running/stopped): -- scan server daemon KSVLA-MIB::ksvlaScanServerStatus 1.3.6.1.4.1.23668.1491.1539.2.0 -- klnagent daemon KSVLA-MIB::ksvlaKlnagentStatus 1.3.6.1.4.1.23668.1491.1539.2.1 -- nginx daemon KSVLA-MIB::ksvlaNginxStatus 1.3.6.1.4.1.23668.1491.1539.2.2 -- watchdog KSVLA-MIB::ksvlaWatchdogStatus 1.3.6.1.4.1.23668.1491.1539.2.3 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" "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. "authpass" and "privpass" we can say passwords, which should be generated by you own "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

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

ATTENTION! All mechanisms described below will be applicable to all further released Cumulative Patches for Kaspersky Linux Light Agent 5.2. 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). Example: There is a directory “/path/to/folder” which is not a mount point. The folder “/path/to/folder” has the following subfolders: “notmountsubfolder”, which is not a mount point "mountsubfolder", which is a mount point The folder “/path/to/folder” is added to exclusions with the enabled option "Include subfolders". Exclusion of the two subfolders will be processed in the following way: Exclusion of subfolder “notmountsubfolder” will be processed by Kaspersky Linux Light Agent 5.2 after its interception and resolving. Exclusion of subfolder “mountsubfolder” will be processed without Kaspersky Linux Light Agent 5.2 interception and resolving this subfolder directory, i.e. 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: Copy the *.sh file on the Linux VM with Kaspersky Light Agent 5.2 installed. Grant execution access: chmod +x <path_to_file/*.sh file> Run the command /path_to_file/*.sh --install Remote Installation through Kaspersky Security Center: Create installation package based on the kud file. 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: Installation/upgrade of KSV LA 5.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: The best option is to uninstall NSX File Introspection and NSX Network Introspection by modifying VMware Tools on a virtual machine. Try to upgrade VMware Tools up to the latest supported by vSphere version.

Please note that Kaspersky Light Agent 5.2 has been passed basic test scenarios on Windows Server 2022 and Windows 11. Currently KSV LA 5.2 supports installation on Windows Server 2022 and Windows 11.

Problem 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 Start SVM deploying wizard and don’t forget to enable option Allow remote access via SSH for root account. Wait for the error and then, make sure that deployment wizard skipped rollback step. Disable all traces returning to the previous values. Connect to SVM directly, using hypervisor. 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. Use command ifconfig to check if the SVM received network adapter settings, specified at the beginning of installation. 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 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