Откат обновлений хранилища KSC

[ГГеоргий 1]

Добрый день!
Подскажите пожалуйста есть ли возможность откатить обновления в самом хранилище обновлений KSC? То есть не для конечных точек KICS for nodes или KES с помощью их задач, а именно внутри хранилища? 
сценарий следующий:
Выходит новое обновление, мы его загружаем в хранилище сервера администрирования. Затем проливаем его например на тестовую группу из 10 пк (к примеру). Переводим защиту на пк полностью в режим информирование и наблюдаем. Если понимаем, что обновление как то негативно влияет на работу, то мы откатываем обновление на самих тестовых хостах и также внутри самого хранилища. Откат внутри хранилища необходим например в случае когда подключится новый ПК и ему нужно будет загрузить старое обновление, а не то которое негативно влияет. 
как вот сделать именно централизованный откат в самом хранилище чтобы дальше сервер снова смог старые "рабочие" обновы раздавать? 
и в дополнении вопрос - есть ли возможность в политиках на конечных устройствах их переводить в режим информирования лишь одним чекбоксом или переключателем каким то? или вот в нашем сценарии придется каждый раз руками пробегаться по каждому протектору и в "информирование" переводить?

[ctandrey13 4]

Добрый день, на сервере KSC в задаче Загрузка обновлений в хранилище Сервера администрирования. https://support.kaspersky.com/help/KSC/14.2/ru-RU/5251.htm

Проверка полученных обновлений

Перед установкой обновлений на управляемые устройства вы можете сначала проверить их на работоспособность и ошибки с помощью задачи Проверка обновлений. Задача Проверка обновлений выполняется автоматически в рамках задачи Загрузка обновлений в хранилище Сервера администрирования. Сервер администрирования загружает обновления с источника, сохраняет их во временном хранилище и запускает задачу Проверка обновлений. В случае успешного выполнения этой задачи обновления копируются из временного хранилища в папку общего доступа Сервера администрирования (<Папка установки Kaspersky Security Center>\Share\Updates). Обновления распространяются на клиентские устройства, для которых Сервер администрирования является источником обновления.

[ГГеоргий 1]

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

[mike 1 1 043]

8 часов назад, ГГеоргий сказал:

А мы хотим понаблюдать за тестовой группой пару дней чтобы быть наверняка уверенными что на сам рабочий процесс никак не влияет обновление

Пока вы будете наблюдать пару дней/недель антивирусные базы на хостах устареют и в случае разбора серьезного инцидента ИБ, вендор вам скажет, ну вы же сами виноваты, что антивирусные базы у вас старые были и не обновлялись.  

[ГГеоргий 1]

Благодарю вас за ответ.
А если это закрытый сегмент промышленной сети где обновления ставятся реже в связи с возможным влиянием на производственные процессы?
В таком случае, в теории, можно ли как то удалить из хранилища обновление?  

[mike 1 1 043]

18 минут назад, ГГеоргий сказал:

А если это закрытый сегмент промышленной сети где обновления ставятся реже в связи с возможным влиянием на производственные процессы?

Смотрите в сторону KUU https://support.kaspersky.ru/kuu4-for-windows . Копируете базы по нужному расписанию в сетевую папку, а оттуда уже забираете с помощью KSC. 

[ГГеоргий 1]

Большое спасибо!