Katbert

Не, логика другая. Если выключить защиту локально, то потом нельзя включить удаленно. Давно напрягает. Чтобы включить обратно - приходится заходить на машинку по rdp и включать через значок в трее

Винда себя считает 21H2/19044, а KSC считает эту же Винду 2009/19044. 2009 != 21H2

Правду-истину

Не верно, ведь команда winver правильно кажет

На всех без исключениях машинах с агентами 13.2 - консоль KSC не различает сборки Win10 20H2, 21H1 и 21H2. Кажет у всех один и тот же идентификатор выпуска операционной системы 2009. Вижу три комбинации - 2009/19042, 2009/19043 и 2009/19044. Если сделать выборку машин по идентификатору выпуска ОС 2009 - будут найдены компы всех трех сборок. Чтобы получить правильные результаты выборок - делаю выборки конкретно по 19042. Наблюдается ли к кого-то подобное?

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

Разбираю процесс обновления с KES 11.9 до 11.10 через задачу установки KSC. Там, где установка отработала успешно и комп выжил - в процессе установки зафиксировались артефакты: Однако по логу Windows Installer - установка завершилась успешно и потребовала перезагрузку. Но если до перезагрузки зайти в список установленных программ - то там присутствует и KES 11.9, и KES 11.10 Перезагрузил этот комп, он выжил. Выходит, все эти артефакты не являются прямым признаком проблемы. Однако уже после перезагрузки в журнале увидел довольно дикую вещь: пошло удаление KES 11.9, которое в тихом режиме захотело перезагрузки. Похоже, именно тут порылась собака с окирпичиванием На очередном пострадавшем компе с отвалившейся клавой и мышкой - выключили нажатием на кнопкой power (корректное выключение), а когда включили - все заработало И на этом компе, которого воскресил выкл-вкл, задача удаления KES 11.9 отработала именно со второго раза. Что наводит на мысли, что корень проблем - именно в этом отложенном удалении предыдущей версии KES после перезагрузки И похоже, это так работает новая фича: https://support.kaspersky.com/KESWin/11.10.0/ru-RU/201943.htm Остается последний вопрос - как отключить новомодный режим, и ставить старым проверенным способом?

Это же галка про проверку съемных дисков, отдельной галки про вкл/выкл контроля устройств там нет. Нужно проверить, применилась ли политика к нужным компам - ссылка Подробнее под круговой диаграммой политики. И проверить, запущена ли задача Контроль устройств - в свойствах компа \ вкладка Задачи

У себя наблюдаю подобное в KSC 13.2 - только на машинках с WinXP/Win2003. Их версия RDP-сервера не позволяет делать совместный доступ к рабочему столу. На машинках с более новой версией ОС - пункт активен, но без добавленного в свойствах KSC второго ключа - выдает ошибку, что без лицензии функционал не доступен

И учтён ли момент, что KES для Windows и KES для Linux - используют разные политики?

Проверил на KSC14 - отключенные компьютеры в нераспределенных не болтаются, все работает как и раньше. Могло ли быть, что KSC обнаружил эти компы раньше, еще до отключения их учетных записей в AD? Тогда достаточно однократно их удалить, при последующих опросах уже не должно обнаруживаться

В явном виде - нет. Есть уведомления по email, sms и запуском исполняемого файла. Последний вариант можно использовать косвенно - если есть exe-файл или скрипт, который умеет слать в telegram - то только так.

Нет. Если пользователь через контекстное меню значка KES сделает "приостановить" - то со стороны KSC можно остановить и запустить защиту. После запуска значок так и остается серым. Ничего не изменилось

Наблюдаю тайм-аут задачи установки агента - 2 ч. По факту установка отработала за пару минут, но исталлятор запросил перезагрузку, и служба агента не была запущена

Обновление поверх с KSC 13.2 прошло без проблем. Затем стал обновлять агенты - из первой партии из 12 машин на двух - задача установки слишком долго висит в стадии "Запущена установка". Стал смотреть логи - на обоих машинах нашлось событие от MsiInstaller: "Продукт: Агент администрирования Kaspersky Security Center. Требуется перезагрузка. После установки или обновления продукта требуется перезагрузка, чтобы все изменения вступили в силу. Перезагрузка будет выполнена позже." Абыдна, одна из машин, возжелавших перезагрузки после установки агента - это сервер. Придется перезагружать к ночи

Да, вижу что в системных требованиях KSC14 для агента официально заявлена только WinXP. Про Win2003 скромно умалчивают, хотя серверный антивирус KSWS11 официально поддерживает Win2003. Было бы логично, чтобы и агенты официально поддерживали его. Про родственные ОС - имел в виду, что обе основаны на ядре версии 5.

Предыдущий агент 13.2 тоже работал на WinXP. А на Win2003, который принципиально от WinXP не отличается - были проблемы. В одной из сетей все машины с WinXP работают с агентом 13.2, а сервера Win2003 пришлось откатить до 13.0. Интересно, полечили или нет в 14.0 работу агента на Win2003?

Вопрос решили организационно - админ главного сервера временно отключил свою политику, я импортировал старые политики и сделал их неактивными. После этого политику главного сервера снова включили, но на неактивные политики она уже не влияет

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

Жил-был сервер KSC 13.0, и стал он подчиненным сервером. Вышестоящая политика затоптала местные настройки, но перед созданием иерархии был сделан экспорт политик в файлы *.klp Если создать новую пустую политику и сразу сделать ее неактивной - то параметры с главного сервера не затаптывают настройки, все замочки открыты. Но если импортировать старую политики из файла - то она принудительно становится активной, и настройки меняются. Есть ли способ импортировать политику, без автоматического назначения ее активной?

После обновления плагина с 11.9 до 11.10 потребовалось перепринять соглашение об использовании KSN

Возможно, этот пакет по умолчанию ставится в профиль запустившего пользователя, а агент работаете от localsystem. Нужно проверить, куда будет ставиться пакет, если ручками запустить. Иногда есть ключи командной строки, чтобы пакет установился не в профиль текущего пользователя, а для всех (в program files)

Вариант с подключением по имени kcs.domain.ru годный, только нужно перенести сертификат со старого сервера на новый, раз уж планируется ставить новый сервер с нуля. Для переноса сертификата нужно воспользоваться утилитой klbackup, у нее есть режим "бекапить только сертификат"

И ещё бяку вижу - диагностика правил веб-контроля в локальном интерфейсе kes не проверяет категорию сайта. Например, создано единственное правило для запрета соцсетей по категории. Если в диагностику правил вбить vk.com - то она покажет, что доступ будет предоставлен по правилу по умолчанию. Если же в диагностике в явном виде указать категорию соцсети - то она покажет, что созданное блокирующее правило сработает. Насколько помню, раньше диагностика могла проверить категорию по доменному имени (что логично и ожидаемо)

по доступности сайта cloud.mail.ru, который должен блокироваться категорией файлообменники. И блокируется, когда в правиле оставил только 2 категории