Перейти к содержанию

gurlov

Новички
  • Публикаций

    16
  • Зарегистрирован

  • Посещение

Репутация

0

Информация о gurlov

  • Статус
    Новичок
  1. В общем, проблема решилась обновлением агентов на точках распространения (они же шлюзы соединений) до более свежих. И "управление" вернулось само собой.
  2. прошу прощения. Что-то намудрил я с nmap-ом. Открыт на самом деле порт udp15000 на клиенте для точки распространения: PORT STATE SERVICE 15000/udp open|filtered hydap Ни того, ни того не делал. Агенты устанавливались без указания адреса шлюза соединений. Профили так же не применяются. Но в свойствах политики Агента всегда стоит галочка (см. скрин)
  3. Порт udp15000 точки распространения недоступен для KSC, но для точки стоит "не разрывать соединение". Так что тут всё должно работать и работает. Точками я могу "управлять" Порт udp15000 клиента действительно недоступен для точки распространения (проверил nmap-ом). Но почему так могло произойти от выполнения задачи "смена сервера администрирования"?? Политики для клиентов не изменялись. В сетевом экране что клиентские сети (сети, где находятся клиенты и их точки), что сеть самого KSC указаны как "локальная сеть". На всякий случай поместил сделал сеть KSC доверенной, но это тоже не по
  4. Понял, спасибо. А мне уже погрезилось, что появилась где-то волшебная кнопочка переключения режимов "максимальна защита"\"максимальная производительность"
  5. Я вынужден переезжать на новы сервер с новым именем и новым ip. Все клиенты соединяются по ip Вот тут у меня зародилось сомнение. Поясню ещё раз. После запуска нового сервера я мигрировал на него все точки распространения (они же шлюзы доступа). После этого из консоли управления новым KSC мне стали доступны к управлению все клиенты, которые находились под действием этих точек. Т.е. по хорошему, дело сделано, всё работает. Я даже как обычно мог оперативно запускать и останавливать задачи и программы в свойствах конкретного клиента (см. скрин) Но далее я, как мне кажется, рассу
  6. А нужно ли создавать такую задачу, если есть точки распространения (они же шлюзы соединения)? Я перевёл эти точки под управление новым сервером и KSC всех клиентов, на которых влияли эти точки, спокойно увидел у себя и мог управлять. При этом, выполнение задачи по смене сервера администрирования привело к тому, что все эти клиенты хоть и остались под управлением сервера, но явно перестали взаимодействовать через точки распространения (шлюз соединения)
  7. Здравствуйте. Подскажите, что за статус такой для управляемого устройства "Выполняется (максимальная скорость)" (см. вложение)? Какие устройства и как его получают?
  8. @andrew75 И имена и IP разные. Клиенты конектятся по ip. Про задачу миграции знаю. Но вот переживаю, а как себя поведут точки распространения, при одновременной работе 2х серверов KSC. Как будут работать клиентские ПК с точками распространения. Нужно ли на новом KSC на время миграции клиентов назначить другие точки распространения (отличные от тех, что назначены на старом). Да и вообще чувствую, что я ещё много факторов не учёл и встречу при миграции не один подводный камешек.
  9. Да, забыл указать, что вариант с копированием БД на новый сервер вряд ли поможет. Так как сервер в другой сети. ... или поможет? ...
  10. Да это равносильно тому, что я выделю все нужные и руками перенесу в нужную группу. Что, в принципе, я и сделал.
  11. Уважаемые форумчане, здравствуйте. Имеется одни сервер KSC11 на старом железе. Требуется мигрировать на новое железо. Подскажите стратегию наиболее корректного и удобного перехода. Можно для этого использовать такую функцию, как иерархия серверов? Попробовал просто создать параллельно второй KSC, импортировать политики со старого, и переводить постепенно клиентов со старого на новый. Но не понравилось, что при переводе клиента не сохраняются его теги. Да и в принципе все его статистические данные.
  12. Мне нужно перемещать не все нераспределённые ПК с ОС linux. Хотя бы только те, что с конкретной ОС Linux (а в рассматриваемых правилах только один вариант: просто "ОС Linux".) По этому и посмотрел в сторону автоматического перемещения при установке агента.
  13. Здравствуйте, уважаемые! Ни кто не задавался вопросом: имеется ли возможность автоматически при установке Network Agent for Linux перемещать новоиспечённое клиентское устройство в конкретную группу в KSC? Уверен, что в GUI сервера управления KSC это не реализовано. Но предполагаю, что это можно сделать путём правки, например, конфига ss_install.ini (задав нужный параметр) или скрипта установки akinstall.sh (добавив нужную команду)
  14. Если разрешить запуск только разрешённых программ, то это, по всей видимости, будет намного эффективнее, чем всё остальное. Грубо говоря: можно запускать системные исполняемые файлы, офисные программы и браузер. и всё. Зловред не запуститься. Или я не прав?
×
×
  • Создать...