GlooM

Бэкап сервера администрирования, который создается в рамках задачи самого 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, когда сканирование выполнялось, но в выборку нераспределенных помещались только те объекты, на которые потенциально возможна установка софта.