GlooM

Гениально!!! Официальная техподдержка меня заставляла создавать группу с отдельной политикой без инвентаризации ПО, перекладывать туда компы, ждать сутки и запускать инвентаризацию повторно. А после того, когда ничего не получилось, они посоветовали обновить KSC до последней версии и повторить манипуляции -)))))))))

Здравствуйте! А как быть в ситуации, когда сведения о неиспользуемом ПО оказались в реестре от машин, которые на данный момент вообще удалены из KSC (т.е. физически вышли из строя, была переустановлена ОС и т.д.)? Из около 13000 элементов в реестре ПО у меня сейчас около 6000 установлены на 0 машин. Может есть какой-то SQL запрос, который вычищает нулевые вхождения?

На здоровье! -)

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

Могу примерно объяснить ситуацию. Дело все в том, что речь идет не о требовании при установке антивируса какого-то "специального режима перезагрузки". Речь идет об обычной, абсолютно нормальной перезагрузке. Однако, нюанс в том, что по умолчанию, когда вы производите включение\выключение ПК, винда не делает полную перезагрузку ядра каждый раз по новой... Она использует режим фаст-бут, который предусматривает перед выключением сброс на диск загруженного и проинициализированного ядра, которое при включении просто подгружается без повторной инициализации. Это сделано для сокращения времени загрузки, так как просто открыть кусок операционки с диска - это быстрее, чем инициализировать модули. Антивирус же, в процессе установки либо обновления, допихивает в ядро свои модули, которые надо именно проинициализировать, т.е. сделать полноценный ребут, а не фаст-бут. В принципе, если у вас домен - это не проблема. Выключите фаст бут групповыми политиками, и у вас обычное перевключение компа будет идентично полной перезагрузке, что и требуется установщику.

Бэкап сервера администрирования, который создается в рамках задачи самого KSC не содержит копии БД в том формате, с которым работает конкретная СУБД - он содержит структуру данных, поэтому не привязан к типу СУБД с которым работает и вручную конвертировать данные в разные форматы не нужно. Все что вам нужно - это снять резервную копию на сервере который настроен на работу с MSSQL, затем развернуть новый KSC на сервере с MySQL, после чего выполнить восстановление резервной копии базы. Сервер сам наполнит новую базу данными в нужном формате.

Спасибо за ответ. Уже почти год обещают реализовать в заявке на добавление функционала...

Подскажите кто уже обновился - новая версия сервера администрирования в итоге научилась удаленно включать приостановленную на клиенте защиту? Или по прежнему воз и ныне там?

С проблемой удалось разобраться самому, правда, в некоторой степени получилось костыльно. Может кому пригодится - выкладываю рецепт. 1) В свойствах сервера администрирования -> "Безопасность" добавляем нужного нам "ограниченного" пользователя. 2) Снимаем у него все права, кроме "Общий функционал" -> "Базовая функциональность" -> Чтение. 3) Создаем требуемую группу, кладем в нее нужные компы, до которых надо обеспечить доступ "ограниченному пользователю". 4) У !ВСЕХ! групп в свойствах безопасности отключаем наследование! 5) У всех групп, кроме нужной, из свойств безопасности удаляем "ограниченного пользователя". 6) У "нужной" группы для "ограниченного пользователя" ставим права "Общий функционал" -> "Базовая функциональность" -> Чтение и "Управление системой" -> "Подключения" -> Запуск RDP-сессий + Подключение к существующей сессии. В итоге, "ограниченный пользователь" подключается к консоли администрирования и в иерархии групп видит только ту, что ему предоставили. Остальное дерево групп с начинкой полностью скрыто. Минусы - отключено наследование у всех групп. Соответственно, при добавлении дополнительных прав доступа, которые нужно будет распространить на все группы, придется эти права задавать вручную каждой группе. Если "базовую функциональность" не дать в свойствах сервера администрирования, то пользователь просто не сможет подключиться консолью администрирования к серверу. Если же эти права "пронаследовать" на все группы - то пользователь увидит все дерево иерархии групп.

Здравствуйте! Есть сервер администрирования KSC-13 в котором на данный момент настроены полные права для доменной группы "Администраторы домена". Пользователи, находящиеся в данной группе успешно подключаются и работают с полным функционалом KSC при помощи консолей администрирования. Появилась следующая задача: одному из доменных пользователей необходимо дать так же возможность использовать оснастку администрирования, но со строго ограниченными правами - единственное, что ему должно позволяться - подключаться к RDP-сеансу определенных машин, которые перемещены в соответствующую группу. Подскажите, каким образом правильно расставить права безопасности на данную группу (у нее предварительно отключили наследование безопасности), и, если это требуется - в глобальных свойствах сервера администрирования. В идеале, если так можно - чтобы он вообще не видел иерархию групп и компы, которые лежат в других ("неразрешенных" для него группах). На данный момент, если я даю только права "разрешение на RDP-сеанс" для соответствующей группы, а глобально в сервере администрирования не даю юзеру никаких прав, то не удается даже подключиться консолью к KSC.

Создавал запрос INC000013321935 еще в октябре 2021 года. Ответили: "Пожелание заведено. Текущее обращение я закрываю. Спасибо, что помогаете делать наш продукт лучше!" Прошло уже две новых версии с того момента - 11.8 и 11.9, а реакции пока нет.

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

Именно так. После действия “приостановить” защита остается выключенной. При этом с самого сервера администрирования ее невозможно включить. Т.е. после полной выгрузки KES, он запускается с сервера, а приостановленную защиту сервер не может заводить заново. Единственный способ ее вернуть - подключаться удаленно к пользователю и с его рабочего стола щелкать по значку, вручную выбирая “возобновить защиту”. Я создавал запрос на добавление функционала, заключающийся в том, чтобы с сервера можно было возобновлять приостановленную защиту, точно так же, как можно просто выгрузить\загрузить KES целиком.

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

Из примерно тысячи рабочих станций глюк менее чем на 50.

да… на 300 ПК… вручную) Это сколько тысяч у вас всего парк ПК, если доля глюкнувших составила 300 машин? О_о

Подтверждаю. Некоторая доля компов хочет постоянно перезагрузку для продолжения инсталляции, при этом перезагрузка (причем и перезагрузка, и выключение\включение не помогают). Самое смешное, что в списке проблемных оказался КЕС, установленный на сам сервер администрирования -)))). Проблема решается следующим образом - ВРУЧНУЮ устанавливаем пакет КЕС-11.7 из дистрибутива. При этом, инсталлятор так же выводит сообщение об ошибке, где есть два варианта - перезагрузка (не помогает, она будет требоваться опять) и второй вариант - продолжить установку согласившись на возможное некорректное обновление. Вот в таком случае установка завершается и все нормально в итоге работает.

Здравствуйте! Обнаружил, что после добавления доменного пользователя в группу “Protected Users” ( Группа безопасности "Защищенные пользователи" | Microsoft Docs ) он перестает авторизовываться в консоль KSC - появляется ошибка не хватает прав доступа. После удаления пользователя из данной группы, авторизация и полноценная работа с консолью возвращаются. Сервер администрирования (KSC 13.2) к которому происходит подключение консолью, задан именно по его FQDN, а не по айпи-адресу (т.е. по идее блокируемый группой NTLM задействоваться не должен). Не понятно, почему данное членство в группе ломает авторизацию на КСЦ.

Ответ на заведенный тикет от техподдержки: “Пожелание заведено. Текущее обращение я закрываю. Спасибо, что помогаете делать наш продукт лучше! “ Так что будем ждать в будущих версиях продукта возможность удаленного управления приостановкой\возобновлением защиты непосредственно командами с KSC.

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

Здравствуйте! После обновления сервера администрирования KSC-12 до версии 13.2 увидел, что в списке нераспределенных устройств всплыло огромное количество сетевых МФУ. Подскажите, как вернуть список к старому представлению, когда в нераспределенных отображаются только те системы, на которые потенциально возможна установка агента и антивируса.

Увы.. Я им это не объясню. Другая служба. Будут тыкать как привыкли и дальше. Им это быстрее, удобнее итд. Очень много организационных проблем и телодвижений необходимо предпринять. Я не очень понимаю в чем принципиальная невозможность в КСЦ при управлении установленными агентом и антивирусом, добавить к кнопочкам “Остановить” и “Запустить”, еще две - “Приостановить” и “Возобновить”.

А можно подробнее? Вот сейчас у меня есть тестовый ПК с выключенной защитой, но загруженным КЕС. Что и как мне надо сделать в профиле политики, чтобы защита удаленно включилась? Поддержка будет продолжать тыкаться паролем и отключать из интерфейса. Они работают с консолью администрирования только со своих мест, а когда уходят к юзеру решать проблему на месте, естественно, там на ПК консоли нет.

Самое смешное в том, что техподдержка КЕС даже не в курсе этого. Когда я поднимал эту проблему еще на версии 11.6 летом, мы разбирались 2 месяца. Собирали логи, трассировки, мне прислали какой-то девелопмент билд КЕСа. А потом они отдали всю эту коллекцию переписки с логами программистам и узнали, что оказывается, эта функция отсутствует, а к программистам даже обратиться нельзя без полного собрания всех возможных логов и трассировок… 2 месяца был в работе этот тикет!!!! 2!!!!

Да, это поведение, получается, абсолютно равноценно командам с KSC “остановить КЕС”, “запустить КЕС”. Приложение перезапускается, но оказывается в том же состоянии, в котором было на момент выгрузки. Ничего кроме “ручного” клика по иконке КЕС в трее и возобновления защиты оттуда не помогает. Без возюканья мышью по рабочему столу пользователя не обойтись -(