Overview

Description Starting from KES Windows version 12.6, it can parse third-party mail base files, but still can't re-assemble them. Malware scan tasks runs in folders where mail base files for Thunderbird or TheBat! are located and finds threats in old mail items. Diagnostics After choosing Resolve or setting "Disinfect, delete if disinfection fails" in the KSC task, nothing changes, and another malware scan task anyway finds the same threats. Workaround and solution Since KES cannot re-assemble third-party mail base files, it also cannot delete the mail items in them. It's required to perform manual deletion of infected mail items in mail base file, after that, compact folders in it. Open mail base file in mail program (Thunderbird or TheBat!) Find and delete the infected email (reported by KES) Compact folders in the mail program guide for Thunderbird: https://support.mozilla.org/en-US/kb/compacting-folders guide for TheBat!: https://www.ritlabs.com/en/support/help/63/ Why it's necessary to perform compacting folders: A deleted message is only logically marked for deletion, but physically, it still remains in the mail base file. Compacting folders will remove these items completely.

Scenario Enable Network Threat Protection Connect another Mac via a thunderbolt cable Try to send any data from one computer to another Connection times out Workaround & Solution Connect computers by other means or disable NTP when using Thunderbolt bridge. RCA This issue is caused by a bug in macOS' built-in packet filter and was reported to apple.

Problem Description, Symptoms & Impact Local installation from a standalone package fails Diagnostics Check installation logs of the product. We are looking for the following string: 09.02.2022 17:06:19.453 00000374.000028B4 L1 KLSTD: #1, Error was caught in KLERR_throwError, c:\a\b\a_6vlf7p9h\s\csadminkit\development2\klri\pkginst\klpkinst.cpp@1061. Error params: (1187/0x0 ("Bad parameter "VerifyCertDate""), "KLSTD", c:\a\b\a_6vlf7p9h\s\csadminkit\development2\klri\pkginst\klpkinst.cpp@1061) Error loc: ''. This string means that a certificate in the package is out of date Workaround & Solution In order to fix the problem you should: Log in to your KESCloud console Change a language \ proxy settings of the existing installation package Save changes Return needed language \ proxy settings Save changes Download a new standalone package and install products

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) Problem When KES installation fails with error message "Failed to access local group policy. Error 0x80004005", installation log should be checked. If it contains something similar, follow the steps below. MSI (s) (F4:94) [11:27:28:103]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI9735.tmp, Entrypoint: DisableWindowsDefender DisableWindowsDefender: Entering DisableWindowsDefender in C:\Windows\syswow64\MsiExec.exe, version 5.0.15063.0 DisableWindowsDefender: Failed to access local group policy. Error 0x80004005. DisableWindowsDefender: DisableWindowsDefender: finished. Return value 1603. CustomAction DisableWindowsDefender returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 11:27:28: InstallExecute. Return value 3. According to the log, something is preventing KES from disabling Windows Defender. The KES installer calls the MS API function OpenLocalMachineGPO(GPO_OPEN_LOAD_REGISTRY) https://msdn.microsoft.com/en-us/library/aa374275(v=vs.85).aspx, which returns an error. This problem is not related to KES, therefore only workarounds can be suggested. Most likely, the problem is related to Group Policy and is on the Microsoft Windows side. Solution Move the affected computer under default AD policy, then try to install KES once again. In case it will not help Here are some additional ways to solve the problem. No guarantee that they will work, and no responsibility for the effect, as they are not related to KL products. registry.pol related issues Delete C:\Windows\System32\GroupPolicy\Machine\registry.pol Restart the SMS Agent Host service to force ConfigMgr to reload the policies. Sometimes it is also necessary to reinstall the ConfigMgr client. gpt.ini related issues Replace C:\Windows\System32\GroupPolicy\gpt.ini with a copy from an unaffected computer.

Description and cautions The original scenario located on the page https://support.kaspersky.com/kes11mac/diagnostics/15299, requires a lot of efforts and manual manipulations. I am offering a bit easier and time-saving approach doing the same. Details All the commands from the original document are saved here, but placed together and being run one after another consequently; the old product logs are also wiped up in order to avoid mess: Login under root: sudo -i Enable KESMac KLnagent tracing: rm -rf /Library/Logs/Kaspersky\ Lab/* /Library/Logs/klnagent_trace.log && launchctl unload /Library/LaunchDaemons/com.kaspersky.klnagent.plist && cat /Library/LaunchDaemons/com.kaspersky.klnagent.plist > /Library/LaunchDaemons/com.kaspersky.klnagent.plist.backup && chmod ugo+w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && curl -o klnagent_enabled_traces.zip -J -L https://media.kaspersky.com/utilities/CorporateUtilities/klnagent_enabled_traces.zip && unzip klnagent_enabled_traces.zip && cat klnagent_enabled_traces.plist > /Library/LaunchDaemons/com.kaspersky.klnagent.plist && chmod ugo-w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && launchctl load /Library/LaunchDaemons/com.kaspersky.klnagent.plist Now you can check the log is being written: ls -lh /Library/Logs/klnagent_trace.log In case you need to enable KESMac tracing, refer to the specially dedicated article https://support.kaspersky.com/kes11mac/diagnostics/15041; It is time to reproduce the issue; When it is done, disable KESMac KLnagent tracing the same manner (ensure, you are still under root: sudo -i): launchctl unload /Library/LaunchDaemons/com.kaspersky.klnagent.plist && chmod ugo+w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && cat /Library/LaunchDaemons/com.kaspersky.klnagent.plist.backup > /Library/LaunchDaemons/com.kaspersky.klnagent.plist && chmod ugo-w /Library/LaunchDaemons/com.kaspersky.klnagent.plist && launchctl load /Library/LaunchDaemons/com.kaspersky.klnagent.plist Upon finish, gather the collect package (https://support.kaspersky.com/collect) curl -o collect.tar.gz -L "https://box.kaspersky.com/f/00a1a6d8beb24554a72d/?dl=1" && tar -zxvf collect.tar.gz && chmod +x collect.sh && sudo ./collect.sh

Symptoms OS hang, sometimes with open file errors in journals Customer application degrades with errors "unable to open file", "too many open files" Hangs and third-party (compatibility) issues often require advanced data collection and are sophisticated to investigate. However, a quick check is possible: On a system where KESL has worked for some time (not immediately after reboot/restart), validate the output of the following command, ran as root, for numerous records of /usr/bin or /usr/sbin folders lsof | grep -E 'kesl.+DIR.+\/usr\/s?bin' Root Cause Under heavy load, KESL may display linear increase in file descriptors usage (sysctl - fs.file-nr) up to system-wide limit (sysctl - fs.file-max) and eventually degradation. Workaround Schedule restart of KESL service every week/day, depending on intensity of descriptors growth. NB: KESL restart will also reset progress of certain tasks like "malware scan" and "database update". Schedule KESL restart outside of tasks timeframes. Solution This issue was fixed in KESL 12.1.0.1274, so an update to that or newer version should fix it.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. You need a Mac device with macOS 14+ to supervise iOS device log via Apple Configurator Your iOS device will be reset to factory settings during supervising Download Apple configurator via App Store. Run Apple Configurator. Connect your iOS device. Unlock the device and tap Trust. Select your device and click on the Prepare button Select 'Manual Configuration'. Check 'Supervise devices' and 'Allow devices to pair with other computers' (if you want to allow it). Click on the Next button. Leave it on "Do not enroll in MDM" and click on the Next button Click on the Skip button Enter information about your organization (only 'Name' filed is mandatory'). Click on the Next button. Select 'Generate a new supervision identity'. Click on the Next button. In the next window you should choose which steps will be presented to the user in Setup Assistant. You can choose 'Show all steps', 'Do not show any of these steps' and 'Show only some' steps - in this options you must select the steps. Click on Prepare button. Enter password for your macOS account Click on Erase button. Your device will be reset to factory settings. Wait while your device will be prepared When your device will be turned on, you should see that your device is supervised and managed by your organization in device settings Now you can install iOS MDM profile to this device and apply iOS MDM policy with options for supervised devices.

The KESMac 12 and the KESMac 11.3 patch C allows adding particular processes into the trusted section named Trusted Applications. The both filesystem and network activity of which can be ignored by the product increasing performance. Please, however, note that this could be potentially risky. https://support.kaspersky.com/KESMac/11.3_adminguide/en-US/194142.htm Problem This article will describe a few ways to configure KES for Mac to exclude some of the software from the scope of the product. Solution Trusted applications In order to have an ability to exсlude an application from scanning with KES, a function of Trusted Applications available in Kaspersky Endpoint Security for Mac can be used: The Trusted applications section as seen in the policy creation wizard. Naturally, it can be configured later by modifying the policy. Update the plugin to at least version 11.3.0.33 to get the new functionality. In some specific cases it might be required to put several binaries to Trusted Applications simultaneously in order to take effect. So, a final solution might include several path-based exclusions accompanied by a few BundleID-based ones. Trusted Applications are only available for configuration via KSC policy; i.e. it is currently impossible to add application to exclusions having no KSC installed. Additionally, an appropriate application control plug-in for KESMac must be downloaded and installed on the KSC prior to using Trusted Application functionality. It can be found on the corresponding download page. Common exclusions for developers It's suggested excluding the following paths: "/Library/Developer/CommandLineTools" and "/Library/Toolchains" for the standard developers' utilities, as well as the "/Applications/Xcode.app/*" for the XCode. At the same time, in case you use alternative tools, contact Kaspersky Support to get the exact paths for further exclusions. Excluding TCP 443 from port monitoring Additionally, in case of HTTPS-connectivity issues, unchecking port 443 in Monitored ports may also help:

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. Problem Description, Symptoms & Impact KES File Threat Protection sometimes can't check Microsoft office documents from mounted Google Drive shares, therefore generating Processing error events. This issue is caused by an incompatibility between Google Drive VFS driver and KES. There are no plans on making KES compatible with Google Drive. Workaround & Solution As a workaround, add files with Office extensions stored on the share to exclusions, this shouldn't lower protection, because Office creates a temporary copy of a document when it is opened, which will not be in the exclusion scope and will still be checked. Example for .xlsx files: Path\to\google\drive\folder\*.xlsx, where Path\to\google\drive\folder is replaced with an actual path.

Step-by-step guide You need a Mac device to collect iOS device log via Apple Configurator. Download Apple configurator via App Store. Run Apple Configurator. Connect your iOS device. Unlock the device and tap Trust. Open the iOS device → Console. Reproduce the issue. Save the log in Apple configurator. Try to save the log as soon as possible after you reproduce the issue, because the log is constantly being overwritten. Send the collected log file to Kaspersky support for further analysis.

Problem While WTP/NTP is enabled, nft utility produces errors (stderr) like # nft list ruleset XT target TPROXY not found XT target TPROXY not found XT target TPROXY not found XT target TPROXY not found These errors are caused by a bug in nft utility and xt_TPROXY dynamic library. This effect does not indicate functionality issues. This bug may be reported to netfilter.org developers. Explanation Whenever nft utility lists traffic rules, it dynamically loads extension libraries (for example, from /usr/lib/x86_64-linux-gnu/xtables in Debian OS) including TPROXY and CONNMARK. When nft encounters first ipv4 rule, it sets global "family=ipv4" state via xtables_set_nfproto function, then loads libxt_TPROXY.so which has both ipv4 and ipv6 targets, but ipv6 are ignored due to the flag. After that, nft processes ipv6 rules but there are no ipv6 targets for them. As a result, nft utility produces errors "XT target TPROXY not found".

Problem Description, Symptoms & Impact In KES 12.0, the way Device Control component works has been changed. See changelog: https://support.kaspersky.com/help/KESWin/12.0/en-US/127969.htm Due to these changes, you may notice that printing order becomes slow after you have upgraded KES to version 12.0 or higher. This delay may be around 30-60s or even 10-15 minutes. When you disable KES, it becomes instant. In some exceptional cases, the delay may be so big that it's impossible to print anything and the system hangs. The issue affects both local printers and network printers. Diagnostics First of all, test if the issue persists with Device Control component disabled. If it does, move any device to a separate group for testing, create a new default KES policy there and check if the issue persists on default policy or not. If everything is fine under default policy, this is a clear sign that something is wrong with your configuration. Additionally, try latest PF for KES and check if the issue persists on it. There are some optimizations there that fix some Device Control issues and it can improve the performance, but if the issue is in the policy configuration, it won't help much. Workaround & Solution Troubleshooting steps: Select a host for troubleshooting and move it to a test group Install latest pf on it and reboot check the situation Check if the issue is caused by Device Control component and if the issue persists if this component is disabled Check if the issue persists under main policy and under default policy Check policy configuration and check how many devices have been added to Trusted Devices list. If there are several hundred entries or more, try to find a way to reduce their amount. Please see this public article for more details: https://support.kaspersky.com/KESWin/12.1/en-US/38595.htm It states "it is not recommended to add more than 1000 trusted devices, as this can cause system instability." To reduce the list of trusted devices, you can use wildcard * for the same type of printer.

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) The complete encryption procedure is as follows: 1. During authentication, a private key is generated based on the username and password 2. The private key is used to decrypt the user’s storage and extract the primary key 3. The primary key is checked against the identifier specified in the file header. If it matches, the file encryption key is extracted from the header. 4. The file contents are decrypted using the key obtained in the previous step. The operating system generates private key for file decryption based on the authentication credentials. Until you log in to the system, only the encrypted versions of files can be accessed, so their contents are unreadable. KES uses several types of keys to handle encrypted files: — Administration Server's public key is stored in the Network Agent distribution package and gets on the client computer when protection is deployed. — User’s private key is generated by the operating system based on the username and password. Private keys are not saved to the hard drive. The key stays the same if the account credentials remain the same. However, a new key is generated if the user or password changes. — Primary key is created on the client computer when FLE is enabled. This key is used to encrypt all files. A copy of the primary key is saved in the computer's key storage, which in turn is encrypted using the KSC's public key. It is also saved in all active users' key storages, which are encrypted using their private keys. Thus, after authentication, any user can decrypt his or her storage and access the primary key. — File encryption keys: a separate key is generated to encrypt each file When a file is encrypted, its name and other external attributes are not changed.

Description VMWare guest using Kaspersky products hanging or crashing due to driver conflicts between drivers used by VMWare NSX (vnetWFP.sys, previously vnetflt.sys) and Network Threat Protection component. This problem is known to happen with following versions of KES and VMware Tools: KES 11.6 with VMWare Tools 10.0.9 KES 11.6 and 11.7 with VMWare Tools 11.3.5 KES 12 with VMWare Tools 10.1.7 Troubleshooting steps Update VMWare Tools Sometimes there may be a bug in the driver built into VMWare Tools, and ESXi updates its images only through manually installed patches, and it compares installed version only to the version in it's storage, so even if ESXi says that the VM has current version of VMWare Tools, it may actually be outdated. Because of that, a new VM may run with outdated drivers. ESXi and VMWare Tools compatibility matrix: https://interopmatrix.vmware.com/Interoperability?col=1,&row=39,&isHidePatch=true&isHideGenSupported=false&isHideTechSupported=false&isHideCompatible=false&isHideNTCompatible=false&isHideIncompatible=false&isHideNotSupported=true&isCollection=false Latest supported VMWare Tools version for ESXi 6.5 and 6.7: https://packages.vmware.com/tools/releases/12.1.5/windows/ VMWare Tools for ESXi 7.0 and newer: https://packages.vmware.com/tools/releases/latest/windows/ If that did not help, uninstall NSX Network Introspection drivers of VMWare Tools: https://kb.vmware.com/s/article/2149764 This is the driver that is causing the conflict on VMWare's side, therefore removing it will resolve the conflict and should resolve the issue. Next solution is temporary and should not be used in production for extended periods of time. Disable Network Threat Protection in KES settings or in the policy, if it's controlled by KSC. Network Threat Protection is using klwfp.sys driver, and that driver is causing the conflict with vnetWFP.sys. With that component turned off, the driver loads on startup, but doesn't do anything, avoiding conflict with vnetWFP in most cases. Open KES Window -> Settings -> Network Threat Protection -> switch Network Threat Protection off Open KES policy properties -> Essential Threat Protection -> Network Threat Protection -> Uncheck Network Threat Protection checkbox If nothing helps, submit the case to the Kaspersky support with traces, GSI report including Windows event logs and a full memory dump. Related Information How to collect KES traces: https://support.kaspersky.com/kes11/diagnostics/14364 How to collect a full memory dump: https://support.kaspersky.com/common/diagnostics/10659 Link to GSI: https://media.kaspersky.com/utilities/ConsumerUtilities/GSI-6.2.2.43.exe

Problem Description While installing KES for Windows via KSC installation package the following error appears and interferes with installation. Possible causes: KES components installed already before installation. Required driver files were not found. Workaround & Solution Use kavremover and reinstall KES with the latest patch. In case kavremover will not help, please collect procmon and KES installation logs, actual GSI with event logs and submit the case to the Kaspersky support.

Intro This instruction describes how to create an installation package (.pkg) for the MacOS operating system from the standalone installation package of Kaspersky Endpoint Security for Mac. You may need to create such a package to automate the installation of Kaspersky Endpoint Security software via third-party systems (e.g. AirWatch). Details Files Munki tool (with predefined files) Prerequisites Kaspersky Security Center MacOS machine Python must be installed Usage Create a standalone installation package for Kaspersky Endpoint Security for Mac (https://support.kaspersky.com/KSC/14/en-US/182663.htm) On a MacOS machine: Unzip the file munki-munki-pkg-e018bf1.zip to Desktop. Open Terminal and navigate to the directory munki-munki-pkg-e018bf1 cd /Users/John/Desktop/munki-munki-pkg-e018bf1 Copy the built standalone installation package (kesmac11.2.1.145.sh) to the postinstall file in the kesmac/scripts/ directory: cp kesmac11.2.1.145.sh kesmac/scripts/postinstall Modify the code of the standalone installation package with the vim editor vi kesmac/scripts/postinstall Replace the section in the file to the modified section (note that the line "#!/bin/sh" must be the first line in the file, there must be no empty lines before it): nagent/scripts/postinstall (new) #!/bin/sh logfile="/tmp/kesmac11.2.1.1450.log" wstrUnpackTempPath="${TMPDIR:-/tmp}"/"$(date '+%d.%m_%H.%M.%S.%N')" if [ -f "$logfile" ]; then rm -f "$logfile" fi ExitWithError() { echo "Clean temporary directory '$wstrUnpackTempPath'" >> $logfile rm -rf "$wstrUnpackTempPath" echo "$2" >> $logfile exit $1 } rm -rf "$wstrUnpackTempPath" mkdir "$wstrUnpackTempPath" || ExitWithError 1 "Failed to create temporary directory '$wstrUnpackTempPath': error = $?" echo "Unpack archive to '$wstrUnpackTempPath'..." >> $logfile archive_marker_line=$(grep -an '^CCFAFCA1-F619-4618-B8C1-107EF7694A0C-ARCHIVE:$' "$0" | cut -d : -f 1 | tail -1) tail -n +$((archive_marker_line + 1)) "$0" | tar -xzf - -C "$wstrUnpackTempPath" > /dev/null || ExitWithError 1 "Failed to unpack archive: error = $?" echo "Found installer..." >> $logfile wstrExecName=$(grep -o -r "--include=*.kud" "--include=*.kpd" '^Executable=.*\.sh' $wstrUnpackTempPath | sed 's/.*=//' | sed 's/.*[\\/]//') [ ! -z "$wstrExecName" ] || ExitWithError 1 "Installer not found" echo "Found parameters..." >> $logfile wstrParams=$(grep -o -r "--include=*.kud" "--include=*.kpd" '^Params=.*' $wstrUnpackTempPath | sed 's/.*=//' | sed 's/\r//') echo "Run package installer '$wstrExecName $wstrParams' ..." >> $logfile sh "$wstrUnpackTempPath/$wstrExecName" $wstrParams >> $logfile || ExitWithError $? "Installation failed: error = $?" echo "Product successfully installed!" >> $logfile ExitWithError 0 "" Add the execution bit: chmod +x kesmac/scripts/postinstall You can also change the metadata (if needed) in the nagent/build-info.plist file Change meta <key>version</key> <string>11.2.1.145</string> // version of package <key>name</key> <string>Kaspersky Endpoint Security.pkg</string> // name of package <key>identifier</key> <string>com.kaspersky.kesmac</string> // identifier of package Perform the assembly: ./munkipkg kesmac The built package will be available in the kesmac/build directory with the name <name of package from build-info.plist>.pkg Important Before installing, a configuration profile must be installed: https://support.kaspersky.com/kes11mac/settings/15647 The configuration profile contains settings that are only allowed through User Approved Mobile Device Management (UAMDM), so when you apply the configuration profile locally on the device, the error "Profile installation failure. System profile required. User profiles are not supported". To avoid the error, use the remote administration utility. When installing a .pkg built this way, MacOS may give an error that the package has been signed by an unauthorized developer. It is necessary to allow it to run in OS. The installation log will be saved to the file /tmp/kesmac11.2.1.1450.log

Problem KSC and KS4Android are implemented but KSC is offline and could not access Internet. KUU can be used for updating KS for Android and distribute the update databases. But after running KUU (Kaspersky Update Utility), you cannot find actual KES for Android versions. Solution AV bases for new KESM versions will appear in KUU UI after running KUU with empty application list. The KUU settings should look like the following (in order to update the list of supported applications, you need first to press 'Start' with a blank application list as follows):

Sometimes you may need to add a particular site\domain to an exclusions list of Traffic Security. Unfortunately, at current moment KSWS console allows us to make exclusions ONLY for Ports, IP-addresses, and Processes: But we have ability to make site and domain exclusions for Traffic Security via registry workaround. To implement workaround, we need to create and fill following REG_MULTI_SZ key: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\WSEE\11.0\Environment\ICAP\IgnoreDomains] To make changes in this hive, you can add necessary permissions to your account OR you can run regedit in SYSTEM context (psexec -s -i regedit.exe). Important Besides required domain names, we recommend to add the following default list of names to avoid breaking of Windows Updates and KSWS activation functionality: *.data.microsoft.com *.update.microsoft.com *.kaspersky.com *.rds.amazonaws.com *.s3.amazonaws.com *.blob.core.windows.net *.database.windows.net

Problem kesl-control --app-info outputs the following error: en File Threat Protection: Unavailable due to file interceptor driver error One of the most common root causes is Fanotify is disabled (or KESL could not access it) and kernel module compilation also failed. A special utility can be used for this directly on the affected machine with KESL installed: sudo /opt/kaspersky/kesl/bin/fanotify-checker && echo fanotify: supported || echo fanotify: unsupported In case, an operating system does not support Fanotify technology, it is required to install some additional packages and build a kernel module for KESL. A part of required packages may be found on the Hardware and software requirements section of the product documentation, for example for KESL 11.3; In addition to this, new packages kernel-headers-XXX and kernel-devel-XXX must be installed, where XXX - an operating system kernel version. Use the following scenario to install those packages and build a kernel module for KESL: for RHEL based OS: yum install kernel-headers-`uname -r` kernel-devel-`uname -r` for Debian based OS: apt install linux-headers-`uname -r` Reboot the system; Run the post-install script: /opt/kaspersky/kesl/bin/kesl-setup.pl --build | tee /tmp/buildLog And reboot the service: systemctl restart kesl-supervisor.service In case of any further issues, please contact Kaspersky Support.

Download KES distributive Unpack to the folder Copy patch .msp file (i.e. pf1794.msp) to the same folder In KSC create Installation package using the files from this folder Install

Advice and Solutions (Forum Knowledgebase) Disclaimer. Read before using materials. This article is about Kaspersky Endpoint Security for Windows (KES for Windows) This informational message does not mean that Self-Defense accuses any process of being under malware attack, it proactively blocks certain operations that could pose a potential threat to processes. The number of events depends on the activity of applications that inhabit the system, especially from their periodic activities, polls on a timer, on emerging events, and so on. The event in the reports is informational - it can be simply disabled it in the settings. It's not expected to react to these events. More specifically, it's usually the update programs and VMWare services try to access application processes. The update programs want to restart all processes when the update is finished so that they don't have to reboot the system. But KES doesn't allow them to restart our processes. The applications causing these events: Microsoft Edge Update Google Installer Windows installer VMware Authorization Service Host Process for Windows Services Client Server Runtime Process It is normal for such a request to fail, and this should not be a concern. These events can be turned off in active KES policy: General settings→Interface→Notifications: informational messages→Self-Defense restricted access to the protected resource.

If you want to store FDE encryption keys in Active Directory, this is possible if BitLocker encryption is used. In order to transfer and store the recovery passwords (keys) in Active Directory, it is necessary to: 1. Enable the “Choose how BitLocker-protected operating system drives can be recovered” group policy https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings#bkmk-rec1 for target computers and configure saving BitLocker recovery information to Active Directory Domain Services there. Here is the target policy in the gpedit.msc snap-in on the computer where encryption is planned to be enabled: 2. Install ‘BitLocker Recovery Password Viewer’ feature on the computer with the AD DS Domain Service running: This functionality does not apply to Kaspersky products by design, but in theory it can be used in parallel with MS BitLocker Drive Encryption technology deployed by means of KES BitLocker management (i.e. through Kaspersky product). In this case, after encryption starts the recovery data will be transferred and stored both in AD and on the KSC server. We highly do not recommend applying any settings via the BitLocker (GPO) policies (the recommended configuration is "Not configured" for all policies located in the [Computer configuration / Administrative Templates / Windows Components / BitLocker Drive Encryption] node and below), because they can prevent from deploying bitlocker related settings through Kaspersky product policy. It will lead to an error in applying BitLocker Drive Encryption ‘Encrypt all hard drives’ policy and the inability to encrypt the disk as a result.

To check Block action: Specify Block actions for all rules in the group Activity of script engines and frameworks. Extract files from the archive and start the scripts. All scripts should be blocked, popup about it should be shown. There will be new records about blockings in the local report, events and AAC report in KSC console. To check Smart action: Host where KES is installed is under the policy applied. Specify Smart mode for all rules in the group Activity of script engines and frameworks. Extract files from the archive and start any script. Open KSC → Advanced → Repositories → Triggering of rules in Smart Training State. Check that new record is shown there. There will be no info about this detection in local report, KSC reports or in the events. After two weeks, if there are no new detections for this rule, the rule will automatically change to Smart Blocking mode. If this rule is detected again, the learning period will be extended.

Issue Sometimes Device Control errors in KES may occur. For example, hard drives are wrongly blocked when USB device blocking is enabled, or flash drive blocking is not happening although the policies require to do so. In some cases, the reason for erroneous blocking is that the operating system (OS) is incorrectly identifying the device type. Solution As an example, if the policies prohibit access to flash drives, but this rule does not always work, you can check the following: Go to Device manager and check the Removal policy parameter. The parameter value must be 2 or 3 if the OS has correctly detected the flash drive. If the parameter value is any other value other than 2 or 3, then the OS considers the attached device to be non-removable. Based on this data, KES decides to allow access to the device and not block it, and then informs the user. Below we have added all the possible values and their descriptions which the Removal policy parameter can have: Removal policy 00000001 - ExpectNoRemoval (cannot be extracted at all) Removal policy 00000002 - ExpectOrderlyRemoval Removal policy 00000003 – ExpectSurpriseRemoval Conclusion If the flash drive is not blocked by KES and the removal policy parameter has a value other than 2 or 3, it means that the OS has detected the drive incorrectly. Thus, this is not a bug in the Kaspersky app.

How to check if KES is installed, its state (running or not) and bases version via registry: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\KasperskyLab\Components\34\1103\1.0.0.0\Statistics\AVState More information about these registry keys is available in Online Help: https://support.kaspersky.com/ksc14/3644. Obtaining information from the registry is for familiarization purposes only. KESCLI commands method supported by developers: Managing the application from the command line  >  KESCLI commands  >  GetRealTimeProtectionState. File Threat Protection status https://support.kaspersky.com/help/KESWin/12.2/en-US/213719.htm Managing the application from the command line  >  KESCLI commands  >  GetDefinitionState. Determining the update completion time https://support.kaspersky.com/help/KESWin/12.2/en-US/213724.htm Information in following registry is created by network agent (NA). Information will be deleted before OS shutdown and will be created after OS boot. There is a delay (120s) for NA service start. So if you need to get the state of KES immediately after OS boot, use KESCLI.