ElvinE5

@muhammad.moin I'm sorry, but I don't have any ideas yet ... I can suggest one more update option for the problematic server, try to download updates with this utility ... https://support.kaspersky.com/kuu4-for-windows/howto/15691 in any case collect data about the server and tasks and open a request to tech support as I wrote above ... https://companyaccount.kaspersky.com/account/login start there ... the results of this utility will be requested first ... https://support.kaspersky.com/us/common/diagnostics/3632

@Niden84 - тут - https://support.kaspersky.com/KSCLinux/15/ru-RU/230088.htm Сейчас будет работать с KSCL 14.2

Попробуйте добавить ваше приложение в группу доверенных https://support.kaspersky.com/Cloud/1.0/ru-RU/134579.htm с вот такими параметрами в решениях Cloud такой возможности нет ... PS: я предельно понимаю что у вас решение Kaspersky Endpoint Security Cloud ? - https://cloud.kaspersky.com

Block the launch of the file? If you only use the basic functionality, you must have the application control component enabled. However, you will need to get SHA256 since MD5 was used by older versions. 0. Get SHA256 1. create a category to control such files. I skipped some of the steps, it's mostly just Next, Next, Ok. 2. Create a rule to prohibit application startup in the policy for KES, select the group we created 3. Test PS: in principle it is not necessary to use external tools ...if there is a sample file all data can be obtained directly from it when creating a category and use the parameters that suit you best.

Ну соответственно только компонент Защиты от файловых угроз и контроль устройств. В политике для клиента KES Linux.

Вы получаете обновление не для KSC а для продуктов которыми он управляет ...

у тех поддержки или у вашего поставщика ... запросите

//сообщение было написано до последних ответов, подробно поясняет то же решение. @Demiad предположу что у человека либо все устройства (имена) кодируют очень одинаково ... либо не имеют какой либо логики в наименовании ... что осложняет поиск, поэтому он вывел в отображения столбец "Описание" и указывает там имена пользователей, с которыми ему проще работать. @NordeN могу предложит один из вариантов ... в принципе то что вам советовали - создать задачу, и то как вы хотите ее запускать - через правую кнопку мыши по устройству. 1. Создаем задачу - через меню задачи, выбираем интересующий нас пакет, и не включаем установку агента (например) Далее проходим шаги мастера и настраиваем установку как вам нужно, от имени агента ли, и требуется ли перезагрузка ...до вот этого момента ...где выберем вот этот пункт после чего выбираем любую управляемую машину ... не важно ставит мы на нее пока не будем ... ее нужно выбрать что бы задача создалась и завершаем остальные шаги мастера ... запуск задачи оставляем в "ручном" режиме. Даем задаче понятное имя например я назвал - Установка KES без Агента - (вручную). После создания задачи заходим в ее свойства, и на закладке устройства удаляем выбранную нами ранее машину. все готово ... 2. Установка ... ну теперь все как вы привыкли ... но есть нюансы (с) находим устройство на которое хотим установить подготовленый нами пакет, и через правую кнопку мыши выбираем вот это ... и видим вот такую картину профит (с) ВАЖНО ... если вы выберите несколько устройств ...меню будет немного по другому выглядеть, не надо будет так глубоко проваливать. В остальном все тоже Так будет удобнее ? PS: Работает только на задачах созданных на основе выборки устройств, НЕ работает с задачами для групп администрирования.

отчего же ... все зависит от потребностей заказчика и его структуры нет, все прекрасно работает ... была всего пара случаев когда с KSCL опрос не работал ... быстрее всего запросы людьми уже были в СА направлены ... я думаю они поделятся информацией о решении.

чуть вмешаюсь - https://support.kaspersky.com/KSCLinux/15/ru-RU/98876.htm в моем случаи работало и напрямую с сервера, но было тут на форуме пару случаев что опрос проходил только через точку ... если простым языком ... 1. Установите агента администрирования на машину с Windows (наверно лучше на той что входит в домен) 2. на сервере администрирования создайте из нее точку распространения выбрать вашу машину с Windows и указать ей область действия ... ну пока не разобрались с точками и если они у вас все в одной сети назначите на группу Управляемые устройства 3. В политике для агента администрирования, разрешаете опрос домена точками распространения параметры опроса , домен, имя и пароль, задаются как обычно на закладке обнаружение - опросы сервера Попробуйте такой вариант.

on the problematic KSC 3 and 4 servers, try deleting and recreating the task "Download updates to server storage" as advised by @Joerg Lechea

Try starting with my post in this topic ... on the problematic device, check that the admin agent has received the correct settings to connect to the server, there are no connection errors ... if possible show the output of the utility

интересно, похоже придется собирать логи и трассировку для отправки в тех поддержку банально не пробовали перезагрузить устройство ? хотя вроде этого не требуется ...

Mm-hmm. right. I completely forgot about that, sometimes it helps.

тихо ... не спугни 🙂 ... человек решительно настроен ... но он к нам еще вернется ... ни кто так просто еще не уходил от Разарио Агро (с)

прямого способа нет. Вы можете использовать bat файл - содержащий код на основе команд copy или xcopy который будет выполнять копирование из сетевой папки на локальный диск (например), собрать из него инсталяционный пакет в KSC и запускать его на клиентах с помощью задачи удаленной установки. но как верно заметил @durtuno задача должна запускаться от имени пользователя что будит иметь право на доступ в сетевую папку и на копирование объектов в нужное вам место. по моему игра не стоит свеч (с) PS: как пример - https://stackoverflow.com/questions/46636/copying-from-network-share-using-bat

пробуйте локально установить - ручками... возможно даст больше информации, например появление как-то ошибки.

Обновление клиента не отменяет настройки агента с которыми он работал, а там у него правило постоянно говорило что он в автономном режиме.

понятно ...в вашем случаи на агента продолжает действовать ваше правило с DHCP и пока оно не будет нарушено, агент похоже не вернется в "лоно церкви" 1. вам можно подключить проблемное устройство к сети там где он сможет получить DHCP 2. есть один вариант ... со сменой сервера администрирования я настроил профиль перехода и он прекрасно отрабатывает ... в этом состоянии я использовал смену сервера администрирования ... C:\Program Files (x86)\Kaspersky Lab\NetworkAgent>klmover -address 10.111.10.12 заставив его принудительно сменить сервер на мой же ... и вот что получилось ... как видите сервер есть в настройках и самое главное ... "СНЕСЛО" все настройки профилей сетевого расположения. после чего клиент вновь подключился ... и снова все настройки обновил (также скачав описание профилей) если проблемное устройство пигнует сервер KSC ... попробуйте такой вариант на ошибку подключения не обращать внимание - потому как у меня кабель не подключен что бы имитировать нахождение вне офиса. Полностью имитировать вашу ситуацию не стал 🙂 при этом команда смены сервера отработала нормально.

Device discovery does not always give 100% results .... This may be due to network settings in your organization or the end user devices themselves. You can see how it works and what is used in the detection ...here https://support.kaspersky.com/help/KSC/14.2/en-US/3884_1.htm about devices that are not on the network appearing - this is probably the work of the Active Directory survey in your domain. The system reads out all accounts with the "computer" flag and adds them to the KSC server, regardless of whether the device actually exists. One option is to delete or disable accounts for such devices in the AD ... If you are using KSC, you can quickly upgrade, or deploy solutions using remote installation tasks...start here. https://support.kaspersky.com/help/KSC/14.2/en-US/92444.htm

This is governed by setting the management rights of the KES client ... password policy ... in your case, it's not set. Enable the parameter, set the password ... but now the user will have to enter a login and password to disable the protection.

попробуйте выполнить установку через msi если вы выбрали setup в корне каталога (а не в папке client) - то это мастера установки из которого можно установить разные инструменты, включая консоль. что бы создать инсталяционный пакет именно для консоли используйте дистрибутивы в папке client, в зависимости от разрядности системы. файл MSI - не включайте опцию добавить все содержимое папки к пакету - в качестве строки параметров укажите ... для включение возможности удаленного подключения. вы же понимаете что ставить консоль на ВСЕ сервера нет смысла. к ним можно подключатся удаленно с одной консоли установленной например на сервере KSC проверти системные требования для установки консоли - https://support.kaspersky.com/KSWS/11.0.1/ru-RU/155512.htm для сборки пакета для установки решения KSWS (без консоли) проще использовать kud файл вот от сюда ...

Так, стало понятнее ... интересный подход ... но все же по моему не до конца разобрались с вопросом. по порядку пароль задается в политике агента, попробуйте сменить, если агент на связи с сервером получит новые значения и сможете его удалить (если понадобится) Прошу прощения вот сюда - https://companyaccount.kaspersky.com/account/login теперь по восстановлению ... если я правильно понимаю вы все же выбрали предустановленный профиль Out-of-office, а не настраивали его в ручную значить проблем в с подключением агента быть не должно. Но из за того что для части машин ваше правила нахождения в сетевом местоположении срабатывает постоянно к ним применяется постоянно профиль политики OutOfMF и перевод устройство режим Out-of-office Агент проверяет сове местоположение каждые 60 секунд, и при каждом изменении подключения (банально отключить и подключить кабель) что за режим То есть находясь в этом режиме система будет применять специальную политику (созданную заранее) - "Политика для автономных пользователей" если такой политики НЕТ то свою основную политику. вы же сделали активацию "Профиля политики" на основании сетевого местоположения, где внесли нужные вам изменения. 1. Проверьте имеет ли агент на проблемной машине возможность соединится с сервером администрирования, воспользуйтесь утилитой klnagchek PS C:\Program Files (x86)\Kaspersky Lab\NetworkAgent>klnagchek.exe или графическая утилита по этому же пути klcsngtgui.exe проверьте что проблем нет 2. из политики KES удалите (или отключите) ваш профиль политики активируемый при условии что устройство в заданном вами сетевом местоположении OutOfMF. 3. в Политике для агента удалите или отключите описание сетевого местоположения после очередного периода синхронизации система должна перейти на использование основной политике KES. по настройке ... как бы сделал я не совсем понятно как у вас устройства отключаются от сети и подключаются назад ... предположу базовый вариант Условия при работе во внутренней сети клиентам запрещено подключатся к WiFi ( и прочие), но когда пользователь отправляется в командировку ему нужно открыть некоторые доступы. 1. Создание Автономной политики Не путаем с профилем для сетевого расположения (был слайд в начале) Создается и настраивается так же как и обычная политика за исключением того что выбираем что она бывает "Политикой для автономных пользователей" (настройки родительской Активной политика не наследуются) устройство должно получить эту политику до того как покинет приделы сети. По сути к одному устройству будут применяться 2е политики, но пока устройство не в режиме Out-of-office работать будет Активная 2. Настройка перехода в режим Out-of-office 2.1 включить переход при отсутствии сервера в настройках политики агента администрирования включаем переход ... это позволит Агенту переводить устройство в режим Out-of-office при недоступности сервера KSC. И произойдет это в случаи когда агент не сможет в трех подряд периодах синхронизации получить доступ к серверу (это важно). После чего клиент начинает использовать Автономную политику в качестве основной ... ДО МОМЕНТА возвращения в сеть и подключения в серверу KSC. В принципе на базовом уровне этого должно быть достаточно, однако не всегда удобно, так как переход выполниться после 3-х неудачных попыток подключения агента с серверу KSC (а это с среднем порядка 45+ минут) для более точного перехода нам поможет правила сетевого расположения. 2.2 правила сетевого расположения Базовые понятия из этого слайда нам важно понимать что - Правила дают агенту понять где он находится (по нашему определению) - Профили что с этим делать дальше вы правильно заметили что у системы есть два предустановленных профиля ... вот детали. Для нашей задачи превосходно подойдет готовый профиль "Offline mod" поэтому создавать собственный профиль нет нужды. теперь нам надо описать правилами при каких обстоятельствах агент должен переключить работу клиента в режим Out-of-offie вот рекомендации по выбору правил выбираем последние два, не забываем их "инвертировать" я выбрал разрешимость имени моего контролера домена и SSL подключение к серверу KSC сертификат сервера можно найти по этому пути - C:\ProgramData\KasperskyLab\adminkit\1093\cert агент переключится в режим Out-of-office в случаи когда не сможет разрешить имя сервера и подключится к KSC по SSL Использовать профиль политики вместо политики для Автономных пользователей, тоже вариант, но я бы настроил активацию так ... в вашем случаи устройства будут применять профиль политики и когда устройство само перешло в режим Out-fo-offise (3-и неудачные попытки подключения) или по правилам сетевого месторасположения (а там у нас как раз активируется этот режим) ... и это может нам быть не всегда нужно ... неважно какой подход вы выберите важно понимать Правило сетевого местоположения должны как можно точнее описывать момент когда агент должен перейти на работу от заданного вами профиля подключения (не путать с профилем политики) Надеюсь не запутал вас еще сильнее

I guess you need to gather all the necessary data and contact tech support directly. - https://companyaccount.kaspersky.com/account/login start there ... the results of this utility will be requested first ... https://support.kaspersky.com/us/common/diagnostics/3632 collect data from all three KSC servers as well as uploading update error events, and possibly exporting update tasks

не самый удачный вариант ... во первых используйте сразу несколько значений, в рекомендациях - использовать возможность подключения по SSL к какому нибудь серверу (например к самому же KSC), и резолв DNS имена внутреннего сервера (например DC)... самый простой способ это все же прописать условия при которых агент подключится в KSC на котором вы ДОЛЖНЫ отключите все свои автономные политики и профили, и правила перехода. В политике Агента можно будет сменить пароль (если это еще будет актуально). ранее была утилита на удаление следов установки агента - но сейчас и она проси пароль. - https://support.kaspersky.ru/ksc13/tools/13088 поэтому если ситуация совсем плохая ... пищите а CA Расскажите что вы хотели сделать и как это реализовывали (со скриншотами), и для чего вам это было нужно посмотрим как это можно сделать.