ElvinE5

First, update the KSC server ... then you can update applications on client devices
start here - https://support.kaspersky.com/help/KSC/14.2/en-US/235425.htm

Is this what you wanted to find ?
scroll down for release notes for previous versions
https://support.kaspersky.com/KESWin/12.4/en-US/127969.htm
 
and also look at the changes in hardware and software compatibility for the latest version 12.4 ... and for 12.2
12.4 - https://support.kaspersky.com/KESWin/12.4/en-US/127972.htm
12.2 - https://support.kaspersky.com/help/KESWin/12.2/en-US/127972.htm
 
you can change the help description to suit the version you are interested in
 
I'm afraid there is no ready-made quick comparison table...

to send “commands” to the user’s devices, the KSC server generates a UDP packet on port 15000. Sending is one-way from KSC to the client (something like “hey, connect to me, I have news”). The agent listens to this port; if it “hears,” it establishes a connection with the server according to the standard scheme (from agent to server on TCP 13000), after which information is exchanged. In your case, the server seems unable to “speak out” to the clients, they don’t hear it... it looks like TCP 13000 works on your network, since clients still receive information and policies, judging by your words, clients themselves connect to the server (even if they don’t hear commands) once every 15 minutes (by default) 
Check that you have the ability to send similar packets between the KSC server and clients from a neighboring domain.
I also want to clarify that there is no way to control the start/stop of the agent from the KSC server through the device properties... this is something like a “foolproof” mechanism

в принципе если есть данные о исполняемом файле на сервере KSC, то можно с помощью Предотвращения вторжения запретить этому приложению "общаться" с "Публичными сетями"
 
PS: данные о программе можно собрать задачей "Инвентаризация"

I can assume that SQL 2019 is selected as the database... in this case you need to fulfill some additional conditions
https://support.kaspersky.com/KSC/14.2/en-US/92403_1.htm
 
If you are using SQL Server 2019 as a DBMS and you do not have cumulative patch CU12 or later, you have to perform the following after installing Kaspersky Security Center:
Connect to SQL Server using SQL Management Studio. Run the following commands (if you chose a different name for the database, use that name instead of KAV): USE KAV
GO
ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF
GO
Restart the SQL Server 2019 service. Otherwise, using SQL Server 2019 may result in errors, such as "There is insufficient system memory in resource pool 'internal' to run this query."

this is a little different from what you think... This item allows you to change these device settings in your child groups.
let's go in order...
1. The managed group is the main parent group, all others in relation to it will be children
2. By default, all policies are created for the Managed Devices group, and are also the parent of all other policies - WHICH YOU MUST CREATE in your child groups.
on your slide, I will assume that you went to your child group and opened the POLICIES section .. you saw the policies there - BUT these are the policies of the Parent group, which is why you cannot edit it here...
at the top you should see a “switch” to show or not parent policies applied to the group, select hide and you will see that it is empty, there are no child policies...
if you need a separate policy for a group, open this section and click the create button... after going through all the steps of the wizard... you will have your own policy EXACTLY FOR THIS group...
All of them can be viewed in the main console tree, the Policies section, and there is a column showing which group it belongs to.
after that, opening the policy, you can disable inheritance here... after which you can configure the policy for this group as you need... without receiving settings from the parent...
and make sure that forced application of settings is not enabled in the parental policy... this item will forcefully change all settings to parental ones
 
PS
https://support.kaspersky.com/KSC/14.2/en-US/3313.htm
 

Создайте несколько "сырых" пакетов в консоли KSC с разными настройками под ваши нужды ... и уже после создавайте автономный пакет.
Вам потребуется вот это ...
https://www.kaspersky.ru/small-to-medium-business-security/downloads/endpoint?utm_content=downloads
ищите в разделе "дополнительные дистрибутивы"
внутри архива все необходимое ...
вам только нужно будет распаковать его, положить внутрь только те пакеты что вам нужно (например только dеb) и настроить autoinstall.ini если это необходимо.
После чего средствами KSC собрать новый "сырой" пакет ... и уже из него подготовить автономный.
 
в принципе можно скопировать содержимое уже загруженного вами ранее "сырого пакета" для KESL из папки KLSHARE куда нибудь на рабочий стол ... и проделать тоже самое ... удалить ненужные пакеты (rpm и gui) ... и собрать "сырой"

In short... yes
In short... yes If you have configured a hierarchy of servers, in the task of downloading updates to the storage on a slave server (without Internet access), specify the main server as the source of updates.
Please note - in order for all products on the slave server to be updated (if they differ from the set of products of the main server), at least all plugins for the products of the slave server must be installed on the master server (and installation packages must also be created... just in case )
 
For example
main server - KES, KSWS
slave server - KES, KES for Linux (KESL)
 
Accordingly, on the main page there should be an additional plugin for KESL

Подскажите что вы хотите получить в итоге ?
Как правильно заметил @tyazhelnikov политиками управляют плагины, как и сказано выше указанный плагин 12.4 при помощи которого создана эта политика подойдет для управлениями и предыдущими версиями KES, однако нужно помнить что в новых версиях KES 12 есть настройки которых ранее не было в 11 версии например, соответственно настройка этого пункт политики ни как не повлияет на работу 11 версии у которой простонет этих инструментов.
вы мотыжите создать несколько одинаковых политик для разных групп устройств - и настроить каждую в соответствии со спецификой группы ...
если вы хотите управлять политикой для других продуктов - например для KES for Linux - вам просто нужно установить плагин для этого продукта в вашем KSC
 

on the main screen, section "Monitoring" --> "Backup storage"
 

Тут пусто потому что сервер KSC не знает об исполняемых файлах на устройствах в сети ...пока что
Сбором сведений (в основном) о исполняемых файлах на устройствах занимается компонент "Контроль приложений"
По умолчанию при создании политики этот компонент отключен, включите его - установите "галочку" чекбокса и не забудьте закрыть замочек, даже если пока НЕ планируете пока  писать правила контроля приложений.
через время система соберет данные об запускаемых приложениях на всех устройствах в сети с установленным клиентом и передаст их на сервер, после чего они будут доступны в данном списке .
в принципе "правильной дорогой идете товарищ" .... однако тут все зависит от постановки задачи ...
что именно хотите получить в итоге ?
 
я уже отвечал на нечто подобное ...на другом ресурсе ...
возможно это подойдет ?

По сути для KSC код активации и файл ключа это разные сущности, со своими атрибутами, а том числе и количество ...
он будет активировать ими обоими, не складывая эти лицензии - то есть вы как бы поучаете двойное количество, технически это не проблема ... но вот юридически так делать не стоит...
на вашем месте я бы выбрал один из этих двух способов - или ключ или код, и придерживался бы количества, если у вас уже превышения вам стоит почистить KSC от несуществующих устройств и при необходимости расширить свою лицензию до необходимого количества.
При этом нужно учитывать  - для проверки кода активации, целевое устройство должно иметь выход в интернет к серверам лаборатории для проверки ... так как сам код информации в себе ни несет, в отличии от файла ключа, который содержит всю информацию для активации внутри себя, и может активировать устройства в "закрытом" контуре без доступа в интернет и серверам KSC.
Компьютер активированный дома - ни как посчитать нельзя ... он ни где не отображается. KSC считает только те что подключены к нему непосредственно.
Поэтому крайне важно администратору следить за тем как используются эти данные. Вы ни как не узнаете что например ваш код был украден, и им кто то активировал свой сервер и все свои станции в "корыстных" целях.
однако у лаборатории есть свои мехонизмы регулирования, и в один прекрасный день вы множите получить уведомление что ваш ключ в черном списке и больше не валиден.
 

unpleasant situation... make sure that there are no plans to change the address in the future...
You can use the same klmover command to change the server...
create a bat file with the following content (in two lines)
 
cd "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent"
klmover.exe -address <new server IP>
 
create an installation package from it, and send it to all your devices using the “Remote Installation” task, be sure to specify an administrator account (possibly a domain account) with rights to local installation.
After executing the commands on the target devices, they will have to switch to the new server... this will be equivalent to running this command manually on each device.

Check...some conditions may not be met...
https://support.kaspersky.com/KES4Linux/12.0.0/en-US/198336.htm
 
To use the task, you must have a license that includes this feature.
https://support.kaspersky.com/KES4Linux/12.0.0/en-US/256558.htm
 

Yes, you can install KES on a server
however, to use web-control on servers (Windows Server operating system), you will need a license of at least Advanced

In your case this is not possible...
you are using a Plus license... while the application management functionality is only available in the Pro version
https://b2b-compare.kaspersky.ru/endpoint-security-cloud
 

День добрый ...
я делаю все через KSC.
Чаще всего установку обновления выполняю "поверх", сначала агента потом клиента ... бывают ошибки но нечасто однако я чаще выполняю переход на порядок выше (например с 12.1 на 12.2) ... в вашем же случаи это достаточно большой скачек вперед ...
Обновление выполняю при помощи задач Автоматической установки (на группах) что позволяет экономит время и частично автоматизировать процесс
Наверняка вам еще и KSC обновить надо ?
 
обычно у меня такой план
0. Проверить соответствия оборудования новым требованиям продукта
1. Подготовить все необходимые дистрибутивы, настроить пакеты
2. создать группы, назначить группам пакеты для установки, донастроить автоматически созданные задачи.
предпочитаю убирать пункт установки без перезагрузка (это в политике  более старших версиях) и принудительно перезагружать устройства в задаче после установки KES
3. Протестировать на небольшой группе, выявить проблемы ... устранить ...
4. повторить пункт 3 до полного обновления всего парка ...
 
 
"Камни"
от ошибок ни кто не застрахован, поэтому как резервный план всегда держу пару задачь на удаление клиента KES (а иногда и агента) с перезагрузкой и установкой "начисто"
я как и все очень ленив и не люблю ходить куда-то по пользователям, поэтому делаю все удаленно ...
На самый крайний случай всегда держу под рукой утилиты удаления KES и Агента, и автономные пакеты установки ... если все же идти придется ... (ну или послать кого-то)
https://support.kaspersky.ru/common/uninstall/1464
https://support.kaspersky.ru/ksc13/tools/13088
 

нет ... воспользуйтесь отчетом об угрозах ...

I guess that's not what you're really thinking...
here's the thing about this setting  - https://support.kaspersky.com/Cloud/1.0/en-US/138008.htm
is in simple words ...if your office (on the ground) uses a proxy to access the internet .... you can specify it in the package settings so that clients can connect to the server using these proxy settings ...
if you have for example several branches and each branch has its own proxy server to access the internet ... it will be necessary to create several different security profiles and apply them to the respective devices ...
if you mix them up ...then after installation the client will not be able to connect to the server ...because the proxy settings will not match ...
if you don't use a proxy on the ground to access the Internet ... you don't have to set this option.
 
answering your questions
1. probably not, if clients have access to the internet to connect to the server ....
2. not really ... a client can act as a distribution point, to organize the branch office and reduce requests to the server ...
 https://support.kaspersky.com/KSC/14.2/en-US/98876.htm
but this feature is not available in the Cloud edition
 
 

I think that, no ...
If you used IP as a connection address, and you plan to continue using IP (but a new one), you will have to use klmover, of course this can be done remotely, by remote installation task (requires local administrator rights on the target devices), but still.
 
you can do a tricky thing ...
by first switching the agents to use the DNS name of the server (if your network uses internal DNS and AD) using the appropriate task.
make sure that all devices continue to work ... and then change the IP of your current server.
This is basically the same as using klmover :))))

Yes, Windows 7 SP1 is still supported ... but you need current system updates ...
I apologize for redirecting you to another topic ...but I think the solution may be the same ...
You should probably try uninstalling the problematic admin agent and perform a manual installation from the "raw" package ..... this may give more information ...

вот тут нужно уточнение ...
вы их просто как устройство видите ? (например в группе не распределенные)
или они прям переключились назад ? агент подключился  старому серверу как после выполнения команды klmover ?
 
если первое то это нормально так как из сети устройства ни куда не делись ...и он их обнаруживает, но не подключает к себе.
второе само по себе происходить не может ...либо где-то есть задача либо кто то руками их переводит ...
 
PS: забавный кейс ...

Ну для начала, если это новая установка, обносите базы данных на сервер - задача "загрузка обновлений в хранилище сервера администрирования". С ними сервер понимает что вышили "новые версии" и позволяет их установить ...
потом попробуйте найти нужный вам плагин ...тут ...
 
Либо скачать ...но уже последний 12.3 (предыдущие можно попросить в Company Account - https://companyaccount.kaspersky.com/account/login)
 
из официальных источников и установить вручную ...
в архиве будет два файла их нужно будет указать по очереди при прохождении мастера ...
 

Try creating exceptions for your scanning host ...
 

Unfortunately, there's not enough information to say anything.
show the full text of the error with index c1900200
here is what is in the help - https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/windows-10-upgrade-error-codes
it would also be nice to understand how you have organized the update process for Windows with KSC ... how you have configured it, and if you have not forgotten something important.