Добавить контроль обновления ПО на рабочих местах.

Периодически возникают ситуации, когда пользователи сами устанавливают рабочие места ЛЭРС Учета и при этом забывают настроить источник обновления. Т.е. в качестве источника обновления остается "сервера “ХЦЭС”.
В дальнейшем, это приводит к неработающему рабочему месту ЛЭРС Учет, т.к. часто клиент пользователи обновляют по своему усмотрению, без привязки к обновлениям сервера.

Прошу для рабочих мест (там где, не установлена служба опроса или сам сервер) запретить обновления, если адрес сервера, отличается от адреса сервера для обновления. Для сложных случаев оставить возможность обновления с помощью пакетов обновления из локальных папок.

Для понимания, как лучше решить проблему нужна дополнительная информация:

  1. Как в таких случаях пользователи запускают обновление: после подключения к более новому серверу, когда система им говорит, что необходимо обновиться, или сами периодически запускают “Обновление ЛЭРС УЧЕТ” из меню Пуск?

  2. При установке ЛЭРС УЧЕТ без компонента “Сервер ЛЭРС УЧЕТ”, по умолчанию источником обновлений является сервер, к которому будет подключаться клиент (задается при установке перед выбором источника обновления). Как получается, что у них источником является “Серверы ООО ХЦЭС”?

Чаще всего предлагает система. Но в общем случае нужно защитить все варианты. Это случается регулярно у разных клиентов.

А вот на этот вопрос я не отвечу. Но регулярно у вижу результат. Рабочее место обновлено до текущей версии, хотя сервер никто не обновлял. И я предположил, что стоит настройка “Серверы ООО ХЦЭС”.

Лично я не вижу проблемы в данной ситуации. Программу должен устанавливать администратор (он знает что делает и что и как нужно настраивать). Если программу устанавливает сам пользователь (получается, по факту он и является администратором своей системы), то он должен либо прочитать руководство пользователя ЛЭРС УЧЕТ (раздел “Установка”, он очень небольшой), либо получить инструкции от того, кто знает что и как нужно делать.

Что-либо запретить не получится: если пользователь смог установить программу, значит он сможет и включить/удалить компоненты или вообще переустановить операционную систему.

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

Вам решать. Но я пишу о “защите от дурака” вашего ПО. Ситуация когда на компьютере установлена только рабочее место и при этом адрес сервера, отличается от адреса сервера для обновления - минимум странная.

Нет возможности запретить, есть другие пути:

  1. выдать предупреждающее сообщение при попытке обновить;
  2. проверять каждый раз при загрузке рабочего места и утилиты обновления адрес сервера и адреса сервера для обновления и выдавать сообщение при их отличии. Для экзотических случаев, дать возможность отключить эту проверку

Если у “дурака” есть полный доступ, то это уже “господин Администратор”. Если админских прав нет, то пользователь не сможет изменить настройки обновления ЛЭРС УЧЕТ, а установка обновлений контролируется администратором: в настройках можно запретить установку обновлений пользователями.

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

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

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

Предлагаю добавить следующий алгоритм проверки версии клиента при обновлении:
Проверить настройки обновления, если адрес сервера к которому подключается клиент соответствует адресу сервера источника обновления - сравниваем версию сервера и клиента, при необходимости обновляем клиент.
Если указан другой источник обновления (локальная папка, сервер ХЦЭС, либо сторонний сервер) - сравниваем версию клиента с версией в источнике и подключаемого сервера:

  • если клиентская версия устарела, сравниваем версию клиента с версией сервера, если они равны но версия сервера < источника, выводим сообщение клиенту " Программа не требует обновления. Есть новые обновления для сервера.",
  • версия сервера > источника и версия сервера > клиента , выводим сообщение клиенту “Произведите обновление с сервера (ИМЯ). Либо установите обновление вручную (версия) или обратитесь к администратору.”
  • версия сервера < клиента < или > источника - “Для работы с данным сервером необходима следующая версия … . Обратитесь к администратору.”
  • сервер = клиент = источник - обновляемся из источника.
    и т.п…

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

Предлагаю запускать клиенты через отдельный лаунчер, который будет отвечать за привязку клиентских приложений к подключаемым серверам, проверку, запуск и обновление клиентских приложений (в принципе он уже существует, как отдельное окно перед входом в основное приложение).
Необходимые клиентские приложения и другие файлы необходимые для их запуска хранить в поддиректориях Program FilesLERS, с указанием версии в имени папки, не привязанные версии клиентских приложений удалять автоматически.

Таким образом можно будет решить 2 вопроса:

  1. Подключение клиента к серверам с разными версиями.
  2. Проблему несовместимости версии клиента и сервера, при обновлении через различные источники.

Информация к размышлению. Понимаю что работы необходимы не “маленькие”.

Тут опечатался

  • (сервер = источник) >клиент - обновляемся из источника.

Глобально. Предложение про лончер следует вынести в отдельную тему, к данной теме оно не относится.

nikolab подошел глобально :co_ol: То что касается, обновления - полностью поддерживаю. Это решит первоначальную проблему.

Про “Подключение клиента к серверам с разными версиями” - желательно, но т.к. у меня под рукой более 10 систем, и я давно обошел это ограничение с помощью RDP (и т.п.) напрямую на сервер, а у клиентов такой проблемы еще не возникало, то я бы не считал это высокоприоритетным изменением.