ak01

I switched it to 60min (randomize time) at 9:50, the next scheduled start was at 11:30 and so far, all the 13 servers started the task around 11/12 o’clock. I will check tomorrow, if it is reliable. However, I have about 160 KSWS 10.1.x servers, I need a bigger randomize time.

Unfortunately, the last change (randomize time to 175 min) did not help. The group task (every 3 hours) was executed the last time yesterday. On the other hand side, the “TEST” task (every 1 hour) gets executed every hour reliably. This happens on every server, which has Core Patch 4 installed (currently 13).

The group task get started but not every 3 hours (some starts were missed). It takes a while to see if it does it correctly when it is set to three hours (that is why it looked like KSWS never does it). I now changed the randomize time span to 175 minutes (maybe it misses it when the random delay is bigger than the interval). What have you changed within the Core patches concerning the group task handling? The update TEST Task below is scheduled hourly (randomize 40min) and also runs hourly:

I did some testing. When I configure “every 3 hours”, KSWS 10.1.2.996 and Core Patch 3 or 4 does not periodically start the Update group task. When I switch to “every 1 hour”, it does it periodically. On all the KSWS 10.1.2.996 servers without the Core Patches, it works (with “every 3 hours”). I think this is a bug in Core Patch 3 and 4!

Thank you for Core Patch 4. However, the mentioned error messages appear as well. Especially, two integrity (corrupted) error messages are thrown every day on every server (where the Patch is installed). However, I have not experienced any application problems (concerning other applications that are installed on the server). On the other hand side I experienced a performance improvement. Despite the error messages, KSWS10 does not execute my database update group task periodically any more. I think that it does not do it when I configure every three hours (I have to do some tests). When I start it manually, the task does its job. Uhrzeit: 20.01.2020 20:00:03 Application module integrity corrupted. Reason: invalid module signature. Object name: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Windows Server\drivers\x64\win10\klfltdev\klfltdev.sys Application module integrity corrupted. Reason: invalid module signature. Object name: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Windows Server\drivers\x64\win10\klam\klam.sys

Could you please tell me when Core Patch 4 is available? Every day, I get the message about Application module integrity corrupted (on the servers, where Core Patch 3 is installed). However, I have not noticed any problems concerning applications so far (just these error messages) when Core Patch 3 is installed.

ok. Are you sure that this policy applies to that computer (computer is correctly moved to “managed computer” or a subfolder, computer is listed as alive, agent is running and synchronized with KSC, ...)?

The support article https://support.kaspersky.com/kse9#requirements.block0 only lists SQL Server 2012/2014/2016/2017 as supported database servers. Is ms sql server 2019 (especially always on cluster) also supported?

When I install Core Patch 3, I get the following error message 2 times (is this normal?): Internal task error occurred. Error code: 0x000B. Subsystem code: 0x6 (WP). For more details go to the Kaspersky Lab Technical Support site: https://click.kaspersky.com/?hl=en-US&link=error&pid=wsee&version=10.1.0.0&error=B6X11X14X4X I installed Core Patch 3 on a few (not so important) servers, on one of them I got the following error messages (but only one time): Application module integrity corrupted. Reason: invalid module signature. Object name: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Windows Server\drivers\x64\win10\klfltdev\klfltdev.sys Application module integrity corrupted. Reason: invalid module signature. Object name: C:\Program Files (x86)\Kaspersky Lab\Kaspersky Security for Windows Server\drivers\x64\win10\klam\klam.sys However, these are just error messages. I have not encountered any functional problems of these servers (so everything works as expected so far). When do you plan to release Core Patch 4?

Hallo Oleg thank you very much for that information. I turned off this type of error message (so that it does not get sent to KSC). As far as I understood it, KSWS 10.1.2 generally uses the Distribution Point KSN proxy but in some cases, it throws that error message (but generally, it works). I will wait for KSWS11, that is no problem and I will get the Core3/4 Patches.

You can have a KSWS trace but I only find the following entries (concerning KSN) : 07:14:34.933 1734 560 warning [wp] KsnService: make async request declined with error = 0x80250002, for file 'C:\Users\Administrator\AppData\Local\Temp\2\wireshark_Ethernet0_20200110081434_a02160.pcapng', file has been filtered A network trace only shows communictation to the distribution point (however, I would expect more data sent when I start a manual scan task like in that case):

Maybe you can consider to also apply the “administration server” option for Distribution Points in one of the upcoming KSC versions? This feature would improve KSC administration so that it is more intuitive (an administrator does not need to play around with shares and files/place updates into a folder first and collect it from this location etc.).

Are you sure you edit the right Policy (which applies to that computer)? I would check the local KES settings if it correctly applies your changes in the policy.

I would uninstall the Plugin (see https://support.kaspersky.com/9303), re- download the klcfginst.msi again and install it.

you should install the latest KES11.2 plugin on your computer (where KSC console is installed). see https://support.kaspersky.com/kes11#downloads → klcfginst.msi

The 2nd screenshot shows that „Scan encrypted connections” is not activated. KES should not touch encrypted traffic. However if it is activated now, I would try to put the domain of the requested site into “trusted domains”.

We have one KSC (11.0.0.1131 and Patch b) located at the headquarter and some branch offices, which use distribution points to lower the traffic on the WAN connection. All the computers (KES 11.1/11.2 and KSWS 10.1.2.996) at headquarter get updates from KSC and also use KSC as KSN proxy, that works fine. The computers (same versions) at branch offices use their onsite distribution point for updates (that works fine as well) and KSN proxy. The KES11.1 and 11.2 computers use the distribution point as KSN Proxy without any problems, but KSWS10.1.2.996 servers at branch office permanently log the following messages (using different file namens -> the KSN functionality does not work): Do you have an idea why this does not work? Is this a bug of 10.1.2.996 (I have no patches installed for this version since there are no Core Fixes released publically). The statistics state that KSWS uses the distribution point on TCP port 13111 (win10_1809_ksp is the distribution point, SRVAPWDS01 is the KSC server): A network trace (wireshark) shows that KSWS opens a connection to the distribution point on TCP port 13111 and send some traffic, so it should work?! The agent policy looks like this:

I read that a distribution point also needs updates and therefore I have to create a task of type “Download updates to the repositories of distribution points”. I did that but in the source configuration, the option for administration server is greyed out. However, I used the following setting as a workaround (it works, the clients get updates): Why is the option “Administrationserver” greyed out? It would be nice if you would consider changing that in the next KSC versions (as a feature update).

The clients on a specific site/branch office should get its updates from the distribution point located on that site/branch office (this is the reason to configure a distribution point), but the distribution point itself get its updates normally from the internet (Kaspersky Lab Update server), this is the default setting. When there is only one internet connection (for the whole organization and all sites), the KSC and all distribution points get there updates all from this one internet connection (and download the same updates several times). It would be nice to be able to download the updates only one time (on main KSC) and copy them one time (on each WAN connection) to each distribution point, which then offers them to their clients. This would minimize the needed bandwidth on each wan/internet connection (-> best setup). It is also interesting that when the administrator uses (KSC) slave servers, each slave server can be configured to get its updates from the master server (the mentioned option is not greyed out, however this is another task type but it also offers these settings).

When a distribution point is used, the administrator has to create a task to copy/download updates to the distribution point on KSC. Why is it not possible (greyed out) to use the administration server to get the updates from (at KSC 11, 11.0.0.1131)? Sometimes it is better to use the local internet connection (at site/branch office) but sometimes the WAN connection is faster (or there is only one internet connection at main site). I found a workaround: Configure the KLSHARE Update folder (\\ksc_main_servername\KLSHARE\Updates) as a network folder (task source option → see third option above), but it would be better to use the “Administrationsserver” option.

Hi you should request the private fix pf6008 using the mentioned Company Account Portal.

WoL with magic packet works fine. I am using it a lot. Nevertheless, some organizations do not support that (especially with lots of different subnets/VLANs). Therefore, when KSC wants to wake up a computer, it could also search for a turned on computer whithin the same subnet and tell it to send a magic packet using that running computer (use the agent connection/tell the agent on that computer to send a magic packet). I heard that SCCM is now capable of doing that and this feature would not require any network configuration (it would work independently from any customer setup and would lower questions and tickets concerning WoL not working). This could/should be implemented as an additional WoL feature to sending a magic packet from KSC directly in order to support all different WoL mechanism (when KSC wants to wake up a computer, it could send a magic packet directly, send a directed broadcast packet and use a turned on computer within the same subnet simultaneously). It would be nice if you would consider implementing this feature in one of the next KSC versions.

Could you please add a warning message before someone approves an update (in some of the next versions of KSC)? A warning like “This update will affect all the computers, which have the same major version of this update installed (this might affect all of your computers at the same time!). We recommend to test this update on a small amount of computers beforehand. Are you sure you want to proceed?” Maybe you can add some sort of test- mode (aside “approve” and “decline” options) for each seamless update in order to be able to test a new seamless update only on a small amount of computers (e.g. to computers which have the flag “test-mode” set)?

pf6008 solves our issues as well (see also other topic).

pf6008 solves our issues (see also other topic).