Перейти к содержимому


Фото
- - - - -

Кратчайший путь переустановка Агента


  • Please log in to reply
12 ответов в этой теме

#1 Александр Б.

Александр Б.

    Member

  • Posters
  • 207 Сообщений:

Отправлено 08 Май 2019 - 10:53

Добрый день.

В организации случаются ситуации, когда по каким-то причинам часть станций _внезапно_ перестает обновляться, т.е. установленные Агенты могут быть устаревших версий (11.0, 11.0.2, и т.д.) и не обновляться с сервера управления. Часть из них на сервере управления еще зарегистрированы, часть уже удалены.

 

Изначально эти агенты устанавливались через групповые политики.

 

Какие есть варианты по максимально быстрому и не сильно ручной переустановке или переактивации подобных агентов? Эти рабочие станции очень географически разронены, посему желательно всё максимально удаленно сделать. Все они члены домена, на всех них установлена программа для удаленного управления (типа российского аналога Teamviewer), что позволяет в известных пределах выполнять команды и запускать приложения.

 

Утилита удаления, кстати, не удаляет из реестра ветку установки Агента - HKLM/Software/Microsoft/Windows/CurrentVersion/GroupPolicy/AppMgmt, что делает невозможным плановую переустановку Агента из групповых политик после применения этой утилиты.

 

Честно говоря думал, может есть какая-нибудь консольная утилита восстановления установленных компонентов Агента, в которой можно указать адрес сервера управления (и публичный ключ) и она сверит соответствие установленных компонентов с репозиторием сервера управления.


Сообщение было изменено Александр Б.: 08 Май 2019 - 10:54

Dr.Web ESS 13.00.1 (21-09-2023 03:00:00) / Ubuntu 20.04.6 / Linux 5.4.0-169-generic x86_64; Debian GNU/Linux bullseye/sid; glibc 2.31 / PostgreSQL 10.18

 


#2 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 5 835 Сообщений:

Отправлено 08 Май 2019 - 11:12

Консольная утилита такая есть – esservice.exe. По крайней мере установить новый сертификат и адрес сервера она позволяет.


Семь раз отрежь – один раз проверь

#3 Александр Б.

Александр Б.

    Member

  • Posters
  • 207 Сообщений:

Отправлено 08 Май 2019 - 11:29

Консольная утилита такая есть – esservice.exe. По крайней мере установить новый сертификат и адрес сервера она позволяет.

 

В моем случае она никак не поможет. На рабочих станциях нет проблем с используемым сертификатом, да и адрес сервера управления не менялся - Агенты его знают.

 

Но вот случилось какое-то событие у рабочей станции, Агент перестал обновляться и путей восстановления, кроме как перебивания всей сказки вручную и нет. Сие грустно.


Dr.Web ESS 13.00.1 (21-09-2023 03:00:00) / Ubuntu 20.04.6 / Linux 5.4.0-169-generic x86_64; Debian GNU/Linux bullseye/sid; glibc 2.31 / PostgreSQL 10.18

 


#4 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 5 835 Сообщений:

Отправлено 08 Май 2019 - 11:37

Да, теперь понял, про что речь.

Такого инструмента нет, появится или нет нечто близкое – неизвестно. Но если и появится, то это будет какой-то оффлайн-обновлятор, и там вопрос, с чем он будет справляться.

Ну и с проблемами обновления таки надо разбираться, если они появляются. С фидбеком по этому вопросу туговато.


Семь раз отрежь – один раз проверь

#5 Kirill Polubelov

Kirill Polubelov

    Hr. Schreibikus

  • Dr.Web Staff
  • 4 351 Сообщений:

Отправлено 08 Май 2019 - 11:37

Хорошо бы взглянуть на лог сервиса и апдейтера, как минимум: dwservice.log, es-service.log, dwupdater.log. Чтобы понять отчего и почему вдруг перестаёт обновляться. Возможно, это поможет найти пути решения.


(exit 0)

#6 smerch15

smerch15

    Newbie

  • Posters
  • 59 Сообщений:

Отправлено 08 Май 2019 - 11:40

Есть путь тп его подсказывает. У меня была беда. Клиенты были подключены к серверу, но считали что у них агенты свежее чем на сервере.. был ап с 10 на 11... тп подсказала, как обмануть агента и все агенты апнулись в корректную ревизию.

#7 Александр Б.

Александр Б.

    Member

  • Posters
  • 207 Сообщений:

Отправлено 08 Май 2019 - 11:48

Хорошо бы взглянуть на лог сервиса и апдейтера, как минимум: dwservice.log, es-service.log, dwupdater.log. Чтобы понять отчего и почему вдруг перестаёт обновляться. Возможно, это поможет найти пути решения.

 

Подобные вещи обнаруживаются совершенно случайно. Запускается программа инвентаризации членов домена, а там из 2000 единиц у штук 5 проблема подобного характера.

fudpMIh.png

 

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

 

Наличие консольной утилиты-фиксера на такие случаи было бы оптимально.


Dr.Web ESS 13.00.1 (21-09-2023 03:00:00) / Ubuntu 20.04.6 / Linux 5.4.0-169-generic x86_64; Debian GNU/Linux bullseye/sid; glibc 2.31 / PostgreSQL 10.18

 


#8 Kirill Polubelov

Kirill Polubelov

    Hr. Schreibikus

  • Dr.Web Staff
  • 4 351 Сообщений:

Отправлено 08 Май 2019 - 12:00

Если приведенные на скрине примеры носят не разовый, а систематический (постоянный) характер, то есть, например, устаревание баз, незапущенный АВ, имеют обыкновение возвращаться, то нет никаких оснований полагать, что любая "утилита-фиксер", даже если бы она существовала, сможет решить эти проблемы. И в этом случае, надо как раз разобраться с причинами.

 

Предположу, что у вас просто имел место переход от 10х версии ЕС к 11х, в результате чего и образовались эти проблемы.


(exit 0)

#9 Александр Б.

Александр Б.

    Member

  • Posters
  • 207 Сообщений:

Отправлено 08 Май 2019 - 12:06

Предположу, что у вас просто имел место переход от 10х версии ЕС к 11х, в результате чего и образовались эти проблемы.

 

Это, конечно, тоже. Но большая часть проблем именно с агентами актуальной линейки 11.5

 

Про один из них я в приват отослал ссылку.


Dr.Web ESS 13.00.1 (21-09-2023 03:00:00) / Ubuntu 20.04.6 / Linux 5.4.0-169-generic x86_64; Debian GNU/Linux bullseye/sid; glibc 2.31 / PostgreSQL 10.18

 


#10 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 5 835 Сообщений:

Отправлено 08 Май 2019 - 12:20

Есть путь тп его подсказывает. У меня была беда. Клиенты были подключены к серверу, но считали что у них агенты свежее чем на сервере.. был ап с 10 на 11... тп подсказала, как обмануть агента и все агенты апнулись в корректную ревизию.

Это совсем другой частный случай, и действительно проблемой это не является, только глаз мозолит.


Семь раз отрежь – один раз проверь

#11 smerch15

smerch15

    Newbie

  • Posters
  • 59 Сообщений:

Отправлено 08 Май 2019 - 12:36

Есть путь тп его подсказывает. У меня была беда. Клиенты были подключены к серверу, но считали что у них агенты свежее чем на сервере.. был ап с 10 на 11... тп подсказала, как обмануть агента и все агенты апнулись в корректную ревизию.

Это совсем другой частный случай, и действительно проблемой это не является, только глаз мозолит.
Агент остался версии 11, при актуалтной 11.5 на сервере .
Этим же путём может можно и у него поправить обновление агентов.

#12 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 5 835 Сообщений:

Отправлено 08 Май 2019 - 13:51

Агент остался версии 11, при актуалтной 11.5 на сервере .
Этим же путём может можно и у него поправить обновление агентов.

Точно, такой эффект тоже есть. Но агент при этом в силах обновиться.


Семь раз отрежь – один раз проверь

#13 Александр Б.

Александр Б.

    Member

  • Posters
  • 207 Сообщений:

Отправлено 10 Май 2019 - 13:53

Такого инструмента нет, появится или нет нечто близкое – неизвестно. Но если и появится, то это будет какой-то оффлайн-обновлятор, и там вопрос, с чем он будет справляться.

 

Подумалось, было бы сподручней, если бы нынешняя утилита удаления имела какие-то настройки для работы через групповые политики.

 

В теории:

 

Указать ей сервер управления, чтобы она проверяла наличие доступных версий компонентов в репозитории и в случае несовпадения - запускалась бы штатно на выбранном компьютере.

 

Именно для тех рабочих станций в домене, на которые Агент изначально ставился через групповые политики, и о чем есть соответствующая ветка в реестре HKLM/Software/Microsoft/Windows/CurrentVersion/GroupPolicy/AppMgmt (которую утилите хорошо бы тоже удалять).


Dr.Web ESS 13.00.1 (21-09-2023 03:00:00) / Ubuntu 20.04.6 / Linux 5.4.0-169-generic x86_64; Debian GNU/Linux bullseye/sid; glibc 2.31 / PostgreSQL 10.18

 



Читают тему: 1

0 пользователей, 1 гостей, 0 скрытых