Demiad

Ошибка "FAILED COMMAND: ['opt/kaspersky/ksmg/bin/setup.py', '--auto-install', '/tmp/setup_answers_...']
RETURN CODE: 255" означает, что недоступны DNS-серверы.

Дополнительно стоит убедиться: 5. В свойства политики Сетевого агента "Хранилище"\ "Информация об обновления Центра обновлений Windows" установлена галка и замок на "Редактирование запрещено". 6. Непосредственно на группе управления в которой находится хост точно включено "Наследовать" на разделе "Статус устройства" для соответствующих статусов. Это тот вариант на который я напарывался в своей практике, каким-то чудом в одной из групп снята галка была и статус "Давно не выполнялся поиск обновлений Windows" приходил по своей логике.

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

@Pavel Orlov, должно работать как и раньше. Проверьте наследование в нижестоящих группах или включите форсирование параметров в родительской:

Задачу удаляете через свойства группы где она находится? 

Добрый день.
Отвечу на часть вопросов. Я из своей практики администрирования KSC в схожей инфраструктуре уверенно скажу, что правильно будет разделить технологические АРМы + сервера (доменные и нет) и офисные ПК. То есть сделать две KSC'шки. На офисной будете в более спокойном режиме раскатывать обновления до новых версий KES, смотреть как работает, менять политики. Завязывать условия применения профилей политик* лучше на группы Active Directory. А на другом уже аккуратно точечно обновлять и настраивать защиту. Например, после тестовой обкатки обновления автопатча для KES (обновления до новой версии), его можно будет спокойно одобрить на все офисные ПК, на технологических АРМах я бы не стал так поступать и контролировал процесс на каждой группе хостов до которой дошёл с задачей перехода на новую версию.
*Если пока не сталкивались с настройкой KES/KSC, то строго рекомендую изучить применение Профилей политик для KES. Не надо делать отдельные политики в каждой из групп администрирования KSC!
Про схему получения обновлений не очень понял. Если задача обновлять внешние устройства (корпоративные ноутбуки дома, в командировках), то следует организовать шлюз соединений в виде установленного Агента администрирования на устройстве в DMZ, тут есть описание этого варианта и менее безопасного, когда сам KSC в DMZ.
Использовать на практике Виртуальные серверы мне не приходилось, не нашёл этому применение.
Второй сервер можно сделать подчинённым первому. Но тогда надёжнее расположить корневую политику KES на Головном сервере не в корне структуры "Управляемые устройства", а в подпапке и от неё уже строить структуру. Тогда никогда не случится, чтобы политика с Головного сервера пришла на Подчиненный и затёрла имеющуюся политику KES. Галки про наследование хотя и присутствуют, но всегда можно проглядеть.
Если защита на серверах ещё не развёрнута, то сразу устанавливайте KES (не ниже версии 11.8 для более полной поддержки работы на серверных ОС), новых релизов KSWS на текущий момент больше не ожидается.

Ответил в ЛС. Вероятно, обращение приложения с ПК. 

https://support.kaspersky.com/help/KSC/13.2/ru-RU/73098.htm

Добрый день
Вероятно, в момент нагрузки с Точек распространения данные распространяются на прочие хосты.
Уточнить происходящее можно через поддержку, где попросят собрать трассировку в момент проблемы.
Обратите внимание на аппаратные требования к Точкам распространения (несколько статей раздела справки):
https://support.kaspersky.com/KSC/13.2/ru-RU/158510.htm
 

@Sergey Ch, добрый день.
Если есть возможность подключить KSWS к KSC, установить Агент администрирования на этот сервер. То пароль можно будет сменить политикой WSEE на KSC. 
В случае с KSWS/WSEE есть рекомендация не использовать KAV Remover. KSC не требуется отдельной лицензии, вы можете его установить, выполнить предложенный мной сценарий и удалить обратно, установить можно даже на стационарный ПК.
Касательно удаления WSEE продолжайте общение в CompanyAccount, если уже завели кейс.

Причина возникновения таких событий - достижение лимита по находящимся в БД событиям. В хорошем варианте события должны удаляться по достижении времени хранения, а не Сервер администрирования принудительно очищать БД из-за достижения лимита количества хранимых событий, что сейчас происходит судя по записанному событию.
Первым шагом рекомендую узнать каким типом событий занята большая часть места. Понять требуется ли хранить их. Очень часто БД оказывается занята малополезными событиями. Например, можно в задачах переключить только на запись результата выполнения, уменьшить срок хранения событий в задачах и политиках продуктов. Очистить БД от выявленных событий получится через выборку по целевым событиям и через правую кнопку мыши удалить по ним.
Можно пошагово увеличить размер хранимых событий и найти баланс, когда срок хранения завершается раньше чем БД переполнится. Страница справки по настройке лимита событий в БД: https://support.kaspersky.com/help/KSC/13.2/ru-RU/30023.htm?cid=KSC_13.2
Дополнительно ознакомьтесь с функцией блокировки частых событий: https://support.kaspersky.com/help/KSC/13.2/ru-RU/213112.htm
Если требуются дополнительные рекомендации, то лучше завести обращение в техническую поддержку для детального анализа причин в вашем конкретном случае: https://support.kaspersky.com/b2b Перед обращением имеет смысл провести и собрать ту же диагностику, что предлагается при превышении лимита БД в 10 Гб для SQL Express в статье https://support.kaspersky.ru/15731
 

Добрый день.
С учётом, что MMC-консоль уходит, а активно развивается WEB-консоль, то привычки в любом случае поменяются. 
Запрос на доработку для MMC смысла заводить нет.

@switch, на первый пост ответ - да.
Далее, "прилёт" ключа происходит при синхронизации Агента администрирования (АА) с Сервером администрирования (СА). Интервал синхронизации задаётся в  политике АА, стандартное значение 15 минут. Не рекомендуется сильно уменьшать его, когда кол-во управляемых хостов измеряется десятками тысяч. 
Пока KES не установился ключу "прилетать" некуда. А после установки это происходит в ближайшую синхронизацию АА с СА.
Касательно установки АА в шаблоны важно соблюдать правило установки АА без запуска, см. https://support.kaspersky.ru/9334